WDCR stuck during power cycle.

I removed the initialization of the WD from my code.  The WDCR.WDFLAG is still set on a POWER ON EVENT.  Note we are using an external v1.8 regulator.

Can someone at TI confirm if this is the state at power up or is there another way to determine why this is set?

Tom

Hi Tom,

The WD is enabled at reset by default without any initialization code.

If a WD event causes a reset then bit 7 in the WDCR is set as you describe the WDCR.WDFLAG bit.  This bit will remain set until software resets it to 0.  To reset it to 0 the code must use the EALLOW instruction to gain access to the WDCR.  Then the code must write a 1 to the WDFLAG bit to clear this bit since it is a W1C-0 bit, a bit that is only cleared by a write of a '1'.

Note that the WDCR register requires that the WDCR.WDCHK bits are always written as '101' when a WDCR write occurs.  If this does not happen, then an immediate reset occurs.  This is by design to make sure that software accessing this register is operating properly.

If the WDFLAG b it is not cleared then the bit will remain set through all future resets and power cycles, even if additional WD events do not occur.

So your observations that the WDFLAG bit is set at power-up indicates that this device has experience a WD event at some point.  When you are ready to test your WD management software, I recommend resetting this bit and testing it at every power-up.

I hope this helps,

Jeff

I'm trying to track down the issue with the WDFLAG being set.   I have added a logging function which writes the state of the WDCR to a RAM variable that is not initialized by the C_INIT00 routine.   I place this throughout the code to see at which point the WDFLAG is set.  It appears to occur in the C_INIT00 rountine.  To confirm, I attempt to use the JTAG debugger, but this seems to complicate the matter as the debugger is also setting that bit! 

I proved the debuger issue by capturing the WDCR value in an uninitialized RAM variable, then the codes spins on  a while(wait==0) loop.  Then I launch a debug session, connect debugger, and load symbols.  I've removed all resets from the Debugger script as well as the GEL File to ensure no reset occurs, so I believe I have a hot attachment.    My latched RAM variable shows 0x40 for WDCR ( implies disabled dog, no WDFLAG is set), but the SysCtrlReg shows a value of 0xC0 for WDCR!

I've also confirmed that even if the WD Is disabled, writting invalid sequence into the WDCHK will cause the WDFLAG to be set, even though no reset occurs.

So, can you confirm if there is some logic in the JTAG deubgger which may be causing the bit to be set?  This is still not the final solution, as the WDFLAG is still being set in the CINIT00 routine.

Tom

Can you ask the team responsible for the C2000 Jtag debugger if there could be some debug routines that are manipulating the WDCR, and if so, could they be done incorrectly (i.e. coud they be accessing the WDCR without the WDCHK being used properly)?  This seems to be the behavior i'm seeing for the JTAG part of my problem.  Are these functions "public", can I see what the JTag debugger is actually doing?

Tom

tom prohaszka said:

Can you ask the team responsible for the C2000 Jtag debugger if there could be some debug routines that are manipulating the WDCR, and if so, could they be done incorrectly (i.e. coud they be accessing the WDCR without the WDCHK being used properly)?  This seems to be the behavior i'm seeing for the JTAG part of my problem.  Are these functions "public", can I see what the JTag debugger is actually doing?

Tom

Tom,

Which device?  I ask because we have an errata for the 281x series and the WDFLAG is not reliable on that device.

I don't believe the emulators are watchdog aware but I will check.

Can you check your .gel file in CCS and see if it is doing anything with the watchdog?  How to view the GEL file in CCS v4: http://processors.wiki.ti.com/index.php/GEL

Regards,

Lori

Hi Lori,

We are using  the F28034/35 C2000.   I modified the GEL file to remove the reset, and a few other options to see if that was the issue, but the problem still exists.

Thanks.

Tom

tom prohaszka said:

Hi Lori,

We are using  the F28034/35 C2000.   I modified the GEL file to remove the reset, and a few other options to see if that was the issue, but the problem still exists.

Thanks.

Tom

Thanks Tom,

Which emulation pod are you using?  I will try to reproduce the issue when I'm in the office tomorrow.

Regards

Lori

The Blackhawk USB2000.

Tom

Hi Lori,

I wonder if the Jtag problem is related to an issue we found a few months ago regarding the debugger incorrectly overlaying the CSM sections.  Is it possible that a similar situation  is occuring with the system control registers?

Tom

I have additional info on the WDFLAG being set.   Immediately out of reset (the debugger is NOT connected), I do the following:

      EALLOW;

      SysCtrlRegs.WDKEY = 0x55;

      SysCtrlRegs.WDKEY = 0xAA;

      SysCtrlRegs.WDCR = 0x6F; //set prescaler

      EDIS;

      wdreg2=SysCtrlRegs.WDCR;

      i=0;

      for(i=0;i<0xffff;i++)

      {

      EALLOW;

      SysCtrlRegs.WDKEY = 0x55;

      SysCtrlRegs.WDKEY = 0xAA;

      EDIS;

      }

      wdreg3=SysCtrlRegs.WDCR;

 The result:

wdreg2=0x47

wdreg3=0xC7!!!!!

It looks like the WDFLAG is being toggled high even though the WD is disabled.   Please confirm.  I am using a control stick F28035 with the stock TI explorer kit.

Tom,

I wanted to give you an update.  I wrote a small bit of code and seem to have reproduced the issue.  My code toggles LEDs based on the state of the WDFLAG bit. 

With the emulator connected, my code indicates the WDFLAG is clear.  It keeps feeding the dog and checking in a loop and never sees the WDFLAG go high.

With the emulator disconnected, my code indicates different behavior - WDCR is not what I expected.  I need to dig a bit more to make sure its the flag that is not as expected.

The WDFLAG depends on the duration of the XRSn line so I need to also check that this board is holding it low long enough.

When the XRS line is low, the WDFLAG bit is forced low. The WDFLAG bit is only set if a rising edge on
WDRST signal is detected (after synch and an 8192 SYSCLKOUT cycle delay) and the XRS signal is
high. If the XRS signal is low when WDRST goes high, then the WDFLAG bit remains at 0. In a typical
application, the WDRST signal connects to the XRS input. Hence to distinguish between a watchdog reset
and an external device reset, an external reset must be longer in duration then the watchdog pulse.

-Lori

I'm glad you can see this behavior and hopefully it's something that has a work around. I have some more information to add. I was able to trap the WDCR immediately at reset, and it was 0x00.

I then forced a watchdog reset by starving the dog.  I expected the WDCR to show 0x80, but it was 0x00!!  This is another case that does not make sense. So, there is something that is not being done correctly in silicon?

The reason I need this is to distinguish between the POR/BOR vs. WD resets.  If the XRS needs to be asserted for a specific time, does the POR/BOR circuit assert this for the necessary time? 

Thanks for the help.

Tom

Tom,

I apologize for the delay - I've asked one of my coworkers to take a look on one of our internal test boards.  I just wanted you to know we are still investigating.

Regards

Lori

Hi Lori, any more info on this issue?

Tom

Tom,

One of my colleagues, Manoj, ran some tests for me. 

Like me, he was able to reproduce the issue on the controlCARD.  The good news is he was not able to reproduce it when using one of our internal test boards so the silicon is healthy (he tried multiple devices).

At this point we are suspecting the reset logic on the controlCARD/controlSTICK is not holding the XRSn pin long enough to differentiate a WD reset from a normal reset but the test board is.

-Lori

Lori,

I have run a test where I hold the XRS during power up, and the WDCR flag indicates a power on event.

I'm concerned that the state of XRS needs to be asserted for a power up event.  This implies that there is an external reset chip that asserts the XRS during a power up event until the voltage is in an adequate range.   What is the purpose of the POR logic in the chip if this doesn't do the same thing?  The data sheet details that the POR/BOR is supposed to monitor the voltages and only release the chip from reset if the voltages are "valid" for operation, and the register indicates that the flag is an indication of a power on event or watchdog event.  

Please clarify if the expectation is that the WDCR flag expects the XRS held low while power is applied to the chip to properly clear the flag.  Thanks.

Tom,

I will double check my understanding of POR with regards to your concern.

-Lori

Thanks for the Wiki Lori.

It sounds like during power up, that the F2803x begins running as soon as core voltage releases it from the POR, then it samples the XRS pin? 

Thanks. Tom

tom prohaszka said:

Thanks for the Wiki Lori.

It sounds like during power up, that the F2803x begins running as soon as core voltage releases it from the POR, then it samples the XRS pin? 

Thanks. Tom

Tom,

I need to do some more digging on this.  Will get back to you as soon as possible.

-Lori

Thanks Lori.  We are presently doing the RAM based value as this issue was being looked at. 

For a POR, our assumption is that RAM is scrambled.  If we don't see a proper checksumed signature in the RAM (which we ensure it is not initialized during C_INIT), then we assume a POR, then write a checksumed signature to RAM. 

During a WD reset, we assume RAM has integrity, and if the siganture is valid, we infer a spurious reset due to watchdog.

Thanks for all the help.

Tom

Hi All,

I've seeing the "Reset Circuit to Detect WDRST" at the end of the "http://processors.wiki.ti.com/index.php/WDFlag_on_Piccolo".

My question is: where is the peak maximum current the XRS pin (pulled to GND) can accept when WDRST or when PBRS are actives?!

I've used only an external RC circuit on XRS pin (R = 100kohm and C = 1uF ceramic). When I call a software reset writing an invalid sequence on WDCR.WDCHK register i see the voltage on XRS pin decrease constantly of 1,5 volts on 42us.

42us= 512/12MHz (12MHz is my external resonator frequency). The decrease time and the linearity seems like to have a constant current discharge of the external capacitor for a value of 36mA (without consider the 33uA due to the external pull-up resistor).

This current is a problem ? The fact that the voltage on XRS pin don't goes to 0V is a problem for BOR or POR circuitry?

Thanks to everyone.