TMS320F28035: WDT Operation and effects

Chris Yorkey

Part Number: TMS320F28035

C2K Team, family and friends;

Our customer has a very detailed request below, related to a better understanding of the C2000 WDT. Any comments surely welcomed!

SUMMARY AS FOLLOWS:

- In general, the training modules located here are helpful:

- we may be looking for more docs however

- may not feel completely comfortable with a simple RC on the XRS pin. Need to review and advise.

-Would appreciate any guidance from our team.

-----

From customer;

Watchdog behavior on the C2000:

The goal: I want to toggle from my bootloader to my application (and vice versa) while exchanging some status info using a RAM word.

The solution part 1:

- Define a ram word (call it "App_vs_Boot_Info");

- When running the Application, the Watchdog is enabled with 52ms duration;

- When running the Bootloader, the Watchdog is disabled;

- In both cases, the watchdog is configured to reset the device, and writing 0 to WDCR is used to resets the software;

- To go from Application to bootloader, write "App_vs_Boot_Info" then force a WatchDog reset (not a jump to bootloader beginning cause I want to default back the peripherals with to their reset state);

- To go from bootloader to application, write "App_vs_Boot_Info" then jump to application start;

- Up to this point, everything works as expected. We delivered a couple of units like this (approx 100K...);

- But got one potential occurrence where "App_vs_Boot_Info" was not as expected. (potential because we never reproduced, but identified how it could happend) As a result, the unit would be stuck in the bootloader, which is not that bad since we can reprogram it and it seems like a power On reset might recover normally;

The solution part #2:

- ... The thing is, on Power On Reset "App_vs_Boot_Info" may contain garbage since the RAM goes from unpowered to powered state, so I want to know if we got a power On or a watchdog Reset...;

- ...When bootloader starts, "App_vs_Boot_Info" is only a reliable information if WDFLAG == 1 (i.e. following a watchdog reset, else this is a power On Reset and "App_vs_Boot_Info" contains garbage);

- So I have added this check at power On;

- This seemed to work fine on a couple of units (equipped with both TMS320F28035 and 034). Then we built 40 units with "034" on which the units behaved like the WDFLAG was not set when I would expect it to be. As a result, the unit would be stuck in the application, which becomes bad if we want to re-flash it, which is something we do at the end of our prod line on each unit. And the unit is not designed to give an access to the JTAG (add to lessons learned ... again...);

The solution part #3:

- Remove solution part #2 until we sort this out. This means we may get into random problems in the field (units stuck in the boot), hope for not that many;

My understanding vs the problem...:

- I have a hard time making sure XRS vs watchdog vs WDFLAG are used correctly in our application: confusing documentation (or let's say personal inability to interpret it with confidence... ;-)) ;

- I let the watchdog clocked from the internal clock, so typically 10 MHz;

- When performing a Watchdog reset, if I look at the XRS pin, I should see a 51us low pulse (51.2us = 512/10MHz) -> this is the case;

- On the XRS pin we have an RC with 220us time constant (100nF with 2.2 KOhms), this is fast enough to see the XRS rise over 2.5V within 420us;

- From document SPRUGL8C pages 61-62, WDFLAG should be 0 when XRS goes low. WDFLAG should become 1 if XRS is 1 when WDRST goes high. Since XRS goes low for a duration equal to 512 clock cycles (because of WDRST duration) + the duration resulting from the RC, XRS should always be 0 when WDRST goes high, thus WDFLAG should never be seen as 1 following a watchdog reset.

- There is an "after synch and an 8192 SYSCLOCKOUT cycle delay" condition as well but I'm not sure how to apply this;

- To check this, at the very beginning of the bootloader I enable a GPIO as an output and toggle it until I see WDFLAG is 1 (or max 900 loops i.e. 13ms approx...), and report WDFLAG on the GPIO (JTAG is not used to do this). What I notice is my bootloader starts 975us after the XRS pin goes low (due to watchdog reset) and the WDFLAG reads as 1 the 4^th time I read it (i.e. 1ms after the XRS pin going low). Then, I am a bit confused. I can't find an explanation on what I see. It looks like the sampling of XRS pin to set the WDFLAG occured 1ms after reset;

- If I refer to " http://secure-web.cisco.com/1WpVOAxyatWQwACpr0wgTXTIiPqtsQi5l95nkg1N5afT2bAcfKT1MoVpx0DrhXOi5r0aj6gWi1MvVgYMAKQ9F9lpXv2gz6TCN5hduKwOzUx7hBiGq4wQedKB1kAeyZEUhlfAjIIoHz2ZPfgREbBY4fgFCDPFEpWxlzxQ6GFjQHSOKjUeaji0luyc2XAJFrJEWDLNubw72eEoa_nz_Fuj1jHQ8V1W5Zzy2Lhlaum_BNdoeymlU5wR8xHS6_wCwldoHAn7CGpdZc9xpCmILHaVedQ/http%3A%2F%2Fprocessors.wiki.ti.com%2Findex.php%2FWDFlag_on_Piccolo", on a watchdog reset the WDFLAG should become set 3.3ms after XRS goes low. Does not fit what I see. Looks like we should count the 8192+512 clock cycles from XRS going low, that would lead us not too far from what I see, but not exactly;

- Then, this wiki also tells me that a simple RC (as the one we use) is not a good idea if I want to use the WDFLAG (...Yeah, seems like we're busted now ... );

- Seems like we should have used a TLV803S or similar replacement because the CPU can't recognize a power ON reset since it will always see the XRS line set to 1 when sampling it;

- So let's try this... If I do power On reset... ;

- I see the XRS line rise from 0 to nearly 2V then go low at Time 0us, released at 630 us (which looks like either doc SPRS584K page 33 pulse duration for XRS or 600us typical, or page 27 Supervisor reset release delay in range 400 to 800us ), reach2V at 900us, bootloader starts at 1.55ms, WDFLAG still not 1 at 14.67ms;

- ... Hmmmm ... it seems to detect a power On reset and make the distinction with the watchdog reset ...;

- ...which is nice and would be fine as a solution but since it does match my understanding of the documentation, I'm quite uncomfortable in using this;

So my questions:

- What is missing or wrong in my understanding of this watchdog ?

- It there a clear/simple/official document that better describes this ? (I also looked at https://secure-web.cisco.com/1gMDhxAQph3uDs7BGidjMZXQIcCq_dGgK10qSKt3WST8rEzFraNKuyEuayPaY_MVnOQIY0m4N7E9zyJHmkL0WeI_F4CkJJxw9km6squFphzwejXaA4-O9Aol1NzmOcrqxqq65abo4rnJQXpegUBUWGLZt7cXDByRJYNHPv9kD7Iza9SUmFKcY36yG9BMascgxOAVG6YE-n-pBldFXL0oDYVv8Qt-ri7QVdK0gK9kPkRiUws6WjQ1xwQZo09UtX0pxw3sDzYv72ntniu42Ym38lw/https%3A%2F%2Fe2e.ti.com%2Fsupport%2Fmicrocontrollers%2Fc2000%2Ff%2F171%2Ft%2F419598, also saying it's not that clear...)

- Are we Ok with a simple RC on the XRS pin ?

- Any suggestion / tips / recommendations ?

-----

over 6 years ago

0 Vivek Singh over 6 years ago

TI__Guru** 109165 points

-Hi Chris,

- There is an "after synch and an 8192 SYSCLOCKOUT cycle delay" condition as well but I'm not sure how to apply this;

- To check this, at the very beginning of the bootloader I enable a GPIO as an output and toggle it until I see WDFLAG is 1 (or max 900 loops i.e. 13ms approx...), and report WDFLAG on the GPIO (JTAG is not used to do this). What I notice is my bootloader starts 975us after the XRS pin goes low (due to watchdog reset) and the WDFLAG reads as 1 the 4^th time I read it (i.e. 1ms after the XRS pin going low). Then, I am a bit confused. I can't find an explanation on what I see. It looks like the sampling of XRS pin to set the WDFLAG occured 1ms after reset;

The 8192 SYSCLKOUT cycle delay is the time after WDRST de-assetion to point when status of XRSn pin is checked in HW to make decision if reset was due to XRSn (external circuit) or due to WD and based on that WDFLAG bit will be set. Due to this 8192 cycle delay, when you read the WDFLG in code, it may not be read as '1' because you read it too early. In your code you may want to insert some delay (more than 3ms) before reading the WDFLG to make sure value is read correctly.

Are we Ok with a simple RC on the XRS pin ?

If you want to use WDFLAG bit to differentiate between external XRSn and WDRST then simple RC circuit may not work but in your solution #2 you are using power on reset and issue is only that you are not seeing the WDFLG bit getting set (not other way, WDFLG getting set on external XRSn) hence you may want to insert delay (as mentioned earlier) in SW before reading the WDFLG status and see if that helps.

Regards,

Vivek Singh

0 Chris Yorkey over 6 years ago in reply to Vivek Singh

TI__Genius 14755 points

Hi Vivek,

You're on to something, thank you!

Keep in mind, they are already reading the WDFLAG after a maximum of nearly 13ms; what they apparently see is the WDFLAG get set after 1ms and not even 3ms (this is part of the reason why there is confusion).

Also, it seems to distinguish between a Watchdog Reset and a Power On Reset, (so, it seems to work but our understanding is it should not work ...)? Therefore, to the best of your knowledge, will it work always ? And if so, why ?

Appreciate the input,
Chris

0 Vivek Singh over 6 years ago in reply to Chris Yorkey

TI__Guru** 109165 points

Chris,

Keep in mind, they are already reading the WDFLAG after a maximum of nearly 13ms; what they apparently see is the WDFLAG get set after 1ms and not even 3ms (this is part of the reason why there is confusion).

How are they measuring this time? Before code jumps to application, we have BOOTROM code running and also initialization code. Additionally some delay for XRSn release due to RC circuit. Internal counter starts running as soon as internal WDRST is de-asserted where as the CPU execution only happens after XRSn gets de-asserted. So this time can be less than 3ms.

Also, it seems to distinguish between a Watchdog Reset and a Power On Reset, (so, it seems to work but our understanding is it should not work ...)? Therefore, to the best of your knowledge, will it work always ? And if so, why ?

Power On Reset circuit will be different on your board and I am hoping that it'll meet the requirement of 3.7ms so in that case WDFLG bit will not be set on Power On Reset case.

Regards,

Vivek Singh

0 Chris Yorkey over 6 years ago in reply to Vivek Singh

TI__Genius 14755 points

Vivek,

How they measure (probably not clear enough in description, sorry...):
- An oscilloscope channel on XRS pin, look for the falling XRS pin, low level duration (51us) and start of RC effect;
- Another oscilloscope channel on a GPIO. Trigger for oscilloscope on the GPIO first rising edge to detect when the code starts;
- First thing done in code is set that GPIO as an output;
- Next is 10 times repeat this: if((SysCtrlRegs.WDCR & 0x0080) == 0) {GPIO =1; GPIO =0;}
- Then repeat this in a loop up to 900 times or until (SysCtrlRegs.WDCR & 0x0080) != 0);
- Then wait for 400-500ns, send a register value by toggling the GPIO (400-500ns per bit...) and monitor this with the scope as well;
- Measure the time from the falling edge of XRS until the first GPIO rising edge. This is where application code starts -> 975us after XRS falling edge;
- Measure the time from the falling edge of XRS until the GPIO stops toggling. This is where WDFLAG is set following a watchdog reset -> 1000us after XRS falling edge;

You may ask "what is the difference between the initial 10 silly repeats" and the 900x loop ?" -> execution speed... If they only use the loop, apparently, the WDFLAG is already set the first time the loop checks it. Seems like the Initialization and check for the 1st loop execution nearly takes the 20-25us gap so wanted to prove to themselves that the code can start before the flag is set ... and it's the case apparently.

Comments again welcomed! Thanks again for your support.

-Chris

0 Vivek Singh over 6 years ago in reply to Chris Yorkey

TI__Guru** 109165 points

Sorry for late reply. I need to check on this with design team.

Meanwhile can you check the value of DIVSEL bitfield in PLLSTS register before running any code (just after entering the main) and also when WDFLG is set. Please note that delay value depends on SYSCLKOUT frq and if that clock is fast then this delay will be less.

Regards,
Vivek Singh

0 Chris Yorkey over 6 years ago in reply to Vivek Singh

TI__Genius 14755 points

Vivek,

No problem, appreciate your help!

From our friends:

- DIVSEL = 3 just after entering the main (both following a Power-On-Reset and a watchdog reset). This appears to be as described in doc. "tms320f28035_RevK.pdf", page 65 note 3. Apparently set by the Boot ROM;
- DIVSEL = 3 also once WDFLG is set following a watchdog reset;
- After this, I initialize the PLL to get DIVSEL = 2, and this is what I see reported;

p.s.

For your understanding, let me explan how they monitor this. They want to make sure there is no effect of having the JTAG / debugger, so they store PLLSTS in a RAM copy when they want it and once they're happy, report all values using a GPIO;

A Very similar example...

// Macros to initialize and toggle GPIO
#define DRV_DEBUG_TP7_ENABLE {EALLOW; GpioCtrlRegs.GPADIR.bit.GPIO11= 1; EDIS;} // Debug test point TP7 enabled
#define DRV_DEBUG_TP7_ON {GpioDataRegs.GPASET.bit.GPIO11 = 1;} // "
#define DRV_DEBUG_TP7_OFF {GpioDataRegs.GPACLEAR.bit.GPIO11 = 1;} // "

// Ram copy for PLLSTS register a 3 different time stamps
uint16 Val1,Val2,Val3;

//------------------------------------------------------------------------------
int main(void)
{
// Copy PLLSTS value at initial
Val1 = SysCtrlRegs.PLLSTS.all;

// Toggle a GPIO as long as the WDFLAG is not seen logic "1" (done 10 times manually for processing speed convenience...)
DRV_DEBUG_TP7_ENABLE;
if((SysCtrlRegs.WDCR & 0x0080) == 0) {DRV_DEBUG_TP7_ON; DRV_DEBUG_TP7_OFF; }
if((SysCtrlRegs.WDCR & 0x0080) == 0) {DRV_DEBUG_TP7_ON; DRV_DEBUG_TP7_OFF; }
if((SysCtrlRegs.WDCR & 0x0080) == 0) {DRV_DEBUG_TP7_ON; DRV_DEBUG_TP7_OFF; }
// NoteL Following a watchdog reset, the GPIO toggled 3 times only, the following 7 potential toggle are not performed (i.e. WDFLAG is set now...)

if((SysCtrlRegs.WDCR & 0x0080) == 0) {DRV_DEBUG_TP7_ON; DRV_DEBUG_TP7_OFF; }
if((SysCtrlRegs.WDCR & 0x0080) == 0) {DRV_DEBUG_TP7_ON; DRV_DEBUG_TP7_OFF; }
if((SysCtrlRegs.WDCR & 0x0080) == 0) {DRV_DEBUG_TP7_ON; DRV_DEBUG_TP7_OFF; }
if((SysCtrlRegs.WDCR & 0x0080) == 0) {DRV_DEBUG_TP7_ON; DRV_DEBUG_TP7_OFF; }
if((SysCtrlRegs.WDCR & 0x0080) == 0) {DRV_DEBUG_TP7_ON; DRV_DEBUG_TP7_OFF; }
if((SysCtrlRegs.WDCR & 0x0080) == 0) {DRV_DEBUG_TP7_ON; DRV_DEBUG_TP7_OFF; }
if((SysCtrlRegs.WDCR & 0x0080) == 0) {DRV_DEBUG_TP7_ON; DRV_DEBUG_TP7_OFF; }
// Note: Following a power-on-reset, the GPIO toggled 10 times (i.e. WDFLAG is still not set...)

// A marker to show that the first 10 potential GPIO toggles are done.
DRV_DEBUG_TP7_ON;
asm(" RPT #4 || NOP");
DRV_DEBUG_TP7_OFF;

// Copy PLLSTS value once the WDFLAG is set
Val2 = SysCtrlRegs.PLLSTS.all;

// Init CPU
Mcu_Init(); // Check toggle GPIO until WDFLAG set (max 500 loops), Read and report my RAM flag on the GPIO, disable watchdog, Init PLL, Init Peripheral clocks, Init Pie..., InitFlash
Drv_Init(); // Init all my pins

// Copy PLLSTS value once the WDFLAG is set
Val3 = SysCtrlRegs.PLLSTS.all;

// Send the 3 copies of PLLSTS register
SendVal(Val1);
SendVal(Val2);
SendVal(Val3);

Then the real stuff...

}

TY,
Chris

0 Vivek Singh over 6 years ago in reply to Chris Yorkey

TI__Guru** 109165 points

Hi Chris,

If DIVSEL is set to value 3 then that means SYSCLKOUT = CLKIN and in that case WDFLG will get set before 1ms time. Value 3.7ms is for SYSCLKOUT = CLKIN/4 (DIVSEL = 0, default value). So what customer is observing is ok. Right?

Vivek Singh

0 Chris Yorkey over 6 years ago in reply to Vivek Singh

TI__Genius 14755 points

Hello Vivek,

I communicated some more with the engineer and have the following to reply:
---
So if the DIVSEL default value is 0, sampling would be typically at 3.7ms; Assuming the CPU always starts with the bootloader from the boot ROM as in document " www.ti.com/.../sprugo0b.pdf" on figure 3 - If yes, DIVSEL is always changed to 3 and we don't see where the 3.7ms can be seen anymore...;

Anyway, it seems like at beginning of code, DIVSEL is set by boot ROM to 3, then XRS sampling would be typically at 925us;
Let's say the boot ROM takes a couple of microseconds to change the DIVSEL from 0 to 3, it would make sense that the sampling for XRS pin is around 975us after XRS goes low (let say exactly 1ms for simplification) and a user could wait an additional 1ms before reading it;

... so follow-onquestions:
When performing a watchdog reset, if XRS pin is alway logic "1" at time 800us after XRS pin is released by the CPU internal circuit, will the WDFLAG indicate "0" or "1" if I read it 1ms after my code starts ?
When performing a power-on reset, if XRS pin is alway logic "1" at time 800us after XRS pin is released by the CPU internal circuit, will the WDFLAG indicate "0" or "1" if I read it 1ms after my code starts ?
-----
Thanks!
-Chris

0 Vivek Singh over 6 years ago in reply to Chris Yorkey

TI__Guru** 109165 points

Hi Chris,

... so follow-onquestions:
When performing a watchdog reset, if XRS pin is alway logic "1" at time 800us after XRS pin is released by the CPU internal circuit, will the WDFLAG indicate "0" or "1" if I read it 1ms after my code starts ?

In this case WDFLAG will be set to '1'.

When performing a power-on reset, if XRS pin is alway logic "1" at time 800us after XRS pin is released by the CPU internal circuit, will the WDFLAG indicate "0" or "1" if I read it 1ms after my code starts ?

In this case also WDFLAG may be set to '1'.

Regards,

Vivek Singh

0 Chris Yorkey over 6 years ago in reply to Vivek Singh

TI__Genius 14755 points

Vivek,

For now, our underlying conclusion is that they can't really solve the problem they wanted to avoid as simply as they wanted without a change to the circuit.

So for the moment I think they need to rely on some luck. Some potential improved solutions might not be backward compatible with the units already in the field, at the risk of some (maybe too many...!) parts to be returned at their facility. :-(

For a future design, they might consider using a different circuit topology on the XRS pin. And design recommendations to get access to the full potential of the MCU would be welcomed !

Any final comments or guidance is, as always, appreciated.

Thank you,
Chris

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28035: WDT Operation and effects