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 4th 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 ?
-----