This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TMS320F28335: Change back watchdog mode to Reset Mode

Part Number: TMS320F28335

Tool/software: Code Composer Studio

I'm performing BIST on my F28335 with STL library and the Watchdog self test modifies the configuration of the watchdog to Watchdog Interrupt Mode.

Since BIST is executed after previous configuration, I need to preserve and restore all registers modified by the STL WD Self-Test: SCSR and WDR.

After WD Self-Test, the SCSR register is read as:

  • WDINTS            -> 0 (Watchdog interrupt signal (WDINT) is active)
  • WDENINT          -> 1 (The WDRST output signal is disabled and the WDINT output signal is enabled)
  • WDOVERRIDE  -> 1 (Enable change of state of the watchdog disable (WDDIS) bit in the watchdog control (WDCR))

And the WDCR register is read as:

  • WDFLAG -> 0 (No watchdog reset)
  • WDDIS    -> 1 (Watchdog disabled)
  • WDCHK  -> 0,0,0 (always reads 000)
  • WDPS     -> 0,0,0 (Watchdog pre-scale default)

According to documentation, if I clear WDENINT while WDINTS is low, the device will reset immediately. WDINTS should be low only for 512 OSCCLK cycles then it should be set to 1. I'm polling its value to change clear WDENINT, but still after clearing it, the device enters in a continues reset loop.

What I'm doing is the following:

EALLOW;
SysCtrlRegs.WDKEY = 0x0055U; //Reset WD counter
SysCtrlRegs.WDKEY = 0x00AAU; //Reset WD counter
SysCtrlRegs.WDCR = 0x28u;        //Enable WD
while ((SysCtrlRegs.SCSR & WDINTS_MASK) == 0u){           //Poll WDINTS to clear WDENINT
    SysCtrlRegs.WDKEY = 0x0055U; //Reset WD counter
    SysCtrlRegs.WDKEY = 0x00AAU; //Reset WD counter
} //WDINTS set high
SysCtrlRegs.SCSR = 0u;               //Clear WDENINT to select WD reset mode ( bit 0 ignores write 0, all other bits are read only)
SysCtrlRegs.WDCR = 0x68u;        //Disable WD
SysCtrlRegs.WDKEY = 0x0055U; //Reset WD counter
SysCtrlRegs.WDKEY = 0x00AAU; //Reset WD counter
if ((SysCtrlRegs.WDCR & WDFLAG_MASK) != 0u){             //Clear WD Flag only if it was set
    SysCtrlRegs.WDCR = SysCtrlRegs.WDCR | WDFLAG_MASK | WDCHK_PASS;
}
EDIS;

I can't completely trust the debugger since stepping disables WD count-up.

The device keeps restarting after I do this.

Any idea?

Thanks.

  • Hi,

    In this code, I don't see anything which prevents this happening again. Code you have after clearing the INT (SysCtrlRegs.SCSR = 0u;  ) will not get execute because device gets reset. Do you agree?

    Regards,

    Vievk Singh

  • Hi,

    SysCtrlRegs.SCSR = 0u; is done after WDINTS has been set to 1 (after the 512 OSCCLK since it was set to 0 by the WD module).

    From the documentation, I don't see any reason why the device would reset:

    • WD signal is not present since (WDINTS is high)
    • WD Counter is not reaching max since has been constantly reset (with   SysCtrlRegs.WDKEY = 0x0055U; and WDKEY = 0x00AAU;)
    • Writting 0 to SCSR only changes mode (bit 1) since bit 0 is a write-1-to clear (write 0 ignored) and all other bits are read only

    Is there something that I'm missing from documentation that would make the device reset?

  • Hi,

    Ok, I missed the point that WDINTS was set to '0' after BIST (WD self test). From code it appeared that you were enabling the WD and then checking for it to '0' which will not be the case because it goes to '0' only after WD counter expires. That caused confusion.

    Can you change your code such that instead of enabling the WD, it just checks for the WDINTS to become '1' and then clears the WDENINT and WD counter. WD is already disable so why to enable it again and then disable.

    Regards,
    Vivek Singh
  • Also when you say "The device keeps restarting after I do this.", I am assuming you mean, device is keep getting reset. You can scope the XRSn pin to confirm the same.
  • Thanks,
    I commented the line // SysCtrlRegs.WDCR = 0x28u;
    So the while loop waits for WDINTS to be 1 without enabling the WD. I've got a deadlock at the while statement (WDINTS is never setting back to 1)
    It seems that the WD output WDINT is not updated (back to high after the 512 OSCCCLKs) because the WD is disabled. That's why I enabled it and disabled it later after clearing WDENINT, to avoid deadlock waiting for WDINTS.
    Gianpiero
  • Thanks,
    Yes, I meant device is keep getting reset. Sorry, unfortunately I don't have Oscilloscope available at the moment. But I'm quite sure it's getting reset from debug and from the rest of the software. Also, after each reset, I read WDFLAG as 1, which means the reset was caused by WD.
    Gianpiero.
  • Ok, that is strange. After WD self test, you see WDINTS = 0 and WD is disable which should not be the case. I'll do some more investigation on this and get back to you.

    Regards,
    Vivek Singh
  • Hi,

    We have not been able to reproduce this. If you have any more debug info, please do share.

    Vivek Singh
  • Hi Gianpiero,

    Do have any further update on this? If your issue is resolved then we would like to close the post.

    Vivek Singh
  • I solved the problem enabling WD before updating any WD register (risking to not update WD registers fast enough to avoid MCU reset due to WD).

    However, I can say there was a very unexpected behaviour when updating WD registers with WD disabled. The reset due to WD flag was active after changing WD mode from reset to interrupt with the WD disabled. I don't know if this is expected behaviour with the WD disabled, but seems suspicious.

    Thanks anyway.
    Gianpiero

  • Thank you for your feedback. On below -

    The reset due to WD flag was active after changing WD mode from reset to interrupt with the WD disabled.

    Since WD is enable by default, if at power-up device get reset due to WD (e.g. if BOOT to flash is set and device is not programmed then WD will reset the device) then that flag will be set.

    I'll provide the feedback to our SW team about STL library to see if anything can be improved to avoid such debug.

    Regards,

    Vivek Singh