MCWDT interrupt work with debugger only

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
SuMa_296631
Level 5
Level 5
50 replies posted 25 replies posted 10 replies posted

I am using the PSOC Creator V4.4 with a CY8PROTO-063-BLE board. (The only 'odd' thing abut my configuration is that I am using a iMac M1 computer running Parallels with a Windows ARM VM that has the PSOC Creator software installed - the fact that this works with the debugger and not without makes me thing that this configuration is not part of the problem.)

Using a 'Debug' build and with the debugger active the MCWDT interrupt is being triggered and therefore everything else w working well. However when I program without the debugger (bug still with the 'Debug' build) then everything appears to work until I am supposed to get a periodic MVWDT interrupt that never comes.

What I'm doing is to have a I2C sensor that is is being checked at the start and then periodically as triggered by the MCWDT. When the sensor is read, I update the advertising data that the BLE component is 'broadcasting'.

The BLE component advertises for 2 seconds and so it has finished advertising before the MCWDT interrupt which is currently set to about 6 seconds for testing purposes. The chip is in deep sleep for most of the time and the MCWDT is supposed to trigger the wakeup. (I know the BLE also triggers the wakeup but the code simply loops back to a deep sleep in that state.)

As I say, it all works well when I use the debugger  (F5) but I don't get any MCWFT interrupt when I simply program the chip (Ctrl-F5).

I have tried adding GPIO/LED toggles and UART statements into the code and they all work happily but do show that the MCWDT ISR is not called and therefore I never wake up the chip nor do I set the (volatile) state variable used to take the next measurement.

I've checked the code for array index problems and pointers going 'wild' and I'm fairly sure that this is not a problem (but of course one can never be certain). Anyway, it would appear that the same code is being used both with and without the debugger attached.

What difference can simply running under the debugger make?

Susan

0 Likes
1 Solution
SuMa_296631
Level 5
Level 5
50 replies posted 25 replies posted 10 replies posted

I've worked it out - and it had nothing to do with MCWDT, BLE or anything (as far as I can tell).

The answer is in https://community.cypress.com/t5/Knowledge-Base-Articles/Updating-PDL-syspm-Driver-for-Hard-Fault-Pr...

Basically I 'attached to running target' and found that it was stuck coming out of deep sleep. This is a problem that I had a long time ago and the solution that was pointed to me then ended up with the above reference. It was long enough ago that I remembered something else had to be done but couldn't remember what until I got on the track of deep sleep being blocked by the IPC code.

Thanks all - now on to the other 'issues' with my code.

Susan

View solution in original post

0 Likes
3 Replies
RodolfoGL
Employee
Employee
250 solutions authored 250 sign-ins 5 comments on KBA

Running in debug mode don't let the CPU go to deep-sleep. At the moment the device goes to deep-sleep, it wakes up right away.

It seems the problem is in the way the MCWDT is configured. It is not triggering the interrupt, therefore the device doesn't wake-up from deep-sleep (if running without the debugger attached).

Refer to the MCWDT code example to properly configure the MCWDT.

0 Likes
SuMa_296631
Level 5
Level 5
50 replies posted 25 replies posted 10 replies posted

@RodolfoGL - thanks for your contribution but that is NOT what I am seeing.

With the debugger, the CPUs are going into deep sleep - at least that is what I am seeing in that I have 'printf' statements before and after (so that I can tell what is going on without the debugger and just a UART) and I am seeing the appropriate delay between the 'entering deep sleep' output and the 'waking from deep sleep' output.

Without the debugger I get the first statement and not the second.

I also have a LED being toggled in the MCWDT ISR and I see the toggle with the debugger but not without.

As for the problem with how the MCWDT is initialised, I have followed the example but as I write this I'm going to check with another project I have (that I copied in the first place) that seems to work.

Susan

0 Likes
SuMa_296631
Level 5
Level 5
50 replies posted 25 replies posted 10 replies posted

I've worked it out - and it had nothing to do with MCWDT, BLE or anything (as far as I can tell).

The answer is in https://community.cypress.com/t5/Knowledge-Base-Articles/Updating-PDL-syspm-Driver-for-Hard-Fault-Pr...

Basically I 'attached to running target' and found that it was stuck coming out of deep sleep. This is a problem that I had a long time ago and the solution that was pointed to me then ended up with the above reference. It was long enough ago that I remembered something else had to be done but couldn't remember what until I got on the track of deep sleep being blocked by the IPC code.

Thanks all - now on to the other 'issues' with my code.

Susan

0 Likes