In PSoC 4 how to get ARM-M0 register values during a WDT Reset ?

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

cross mob
shrac_2642471
Level 4
Level 4
5 likes given First like received First like given

Hi Guys,

I want to debug WDT Reset issues on Cypress PSoC 4200 BLE device I am using. I want to know that when there is a Watchdog time out reset which occurs, is there any way to know ARM M0 registers ?pastedImage_0.png
Basically I want to know the contents of SP, LR and PC is that possible ?

If it is not possible how do we debug Watch dog timeout reset issues ?

0 Likes
5 Replies
LiDo_2439176
Level 5
Level 5
First question asked 50 replies posted 50 sign-ins

Hi,

perhaps "CE210292 – WDT P4S Example" will give you some ideas.

0 Likes

Well i checked out the example. It only says how to use WDT or rather how to configure it. I want to know if there is a WDT happening in the system what is causing it. Is it possible to get the register values to debug this problem ?

0 Likes

Are you talking about WDT reset?  Or , to find out if the device reset is caused by WDT?

If yes, you can use the API CySysGetResetReason() which reports the reset caused by WDT, Software reset and Protection violation fault.

From your description, it is quite not clear what are you going to debug. It will be better if you can elaborate your query a bit more.

FYI---

You can check the register values by putting the device in debug mode. (Navigate PSoC Creator -> Debug tab/icon)

You can also read core's  CONTROL, SP, PSR , PRIMASK registers using CMSIS APIs in privileged mode. Refer cmsis_gcc.h file for available APIs after generating the application.

On reset , SP, PC ...will be initialized with their default values based on vector table. I don't know what will you get out of that.  It makes sense if you analyze these registers in context to an interrupt.

Please let me know if it clears your query or you are thinking in another way.

-Gyan

Hi Gyan,
Basically sometimes, in my application there is a WDT that occurs and device resets. Its really hard to know why the watchdog times out. I mean the Watch Dog times out if the system is stuck somewhere. So, I want to know where exactly the system was stuck. 

I have one way to debug this problem is by putting printfs and knowing after what point the device got stuck. I want to know if there are other ways to determine the cause of a Watch dog timeout.

Yes, I understand that after RESET all the values will be lost. Is there a way where we can know before the reset the status of these registers. I will have a look at cmsis_gcc.h if anything is useful. Thanks

0 Likes

Hi,

I would suggest you to break the problem into simple steps and check as follows:

1. Check the functionality of watchdog timer in debug mode by disabling the reset feature. Here check where the code is getting stuck.

Check whether the watchdog interrupt is calling its ISR. Check whether you are configuring WDT correctly and clearing the WDT interrupt correctly.

Debug and correct all these issues in this step.

2. In this step, introduce reset feature. Make a blinky application work with watchdog timer.

3. Now incorporate your code in to the blinky project. It would work.

If still you are facing issues, please attach the project here to analyze it.

Thanks

Ganesh

0 Likes