TMS320F280039C: No watchdog reset if no delay applied between config and activation

Nicolas Audouy

Part Number: TMS320F280039C
Other Parts Discussed in Thread: C2000WARE

Tool/software:

During the tests to simulate an infinite loop, I noticed that the watchdog reset didn't occur 100% of the time. With 10 tries, I have 3 cases where the reset occurred and 7 cases where the software doesn't do a reset.

The code sequence I use for configuration is:

  /*Configure predivider*/
  SysCtl_setWatchdogPredivider(SYSCTL_WD_PREDIV_512);

  /*Configure prescaler*/
  SysCtl_setWatchdogPrescaler(SYSCTL_WD_PRESCALE_64);

  /*Configure watchdog mode*/
  SysCtl_setWatchdogMode(SYSCTL_WD_MODE_RESET);

  /* Enable watchdog */
  SysCtl_enableWatchdog();

With the optimizations set to level 4.

The workarounds to get a reset on every try are as follows :

Define the optimizations to 0

Add a delay of 1µs between SysCtl_setWatchdogMode and SysCtl_enableWatchdog

Comment the line SysCtl_setWatchdogMode(SYSCTL_WD_MODE_RESET);

Update the sequence of the code by :
- SysCtl_setWatchdogMode(SYSCTL_WD_MODE_RESET);
- SysCtl_setWatchdogPredivider(SYSCTL_WD_PREDIV_512);
- SysCtl_setWatchdogPrescaler(SYSCTL_WD_PRESCALE_64);
- SysCtl_enableWatchdog();

In case I try with this sequence I have the same problem :

SysCtl_setWatchdogPredivider(SYSCTL_WD_PREDIV_512);
SysCtl_setWatchdogMode(SYSCTL_WD_MODE_RESET);
SysCtl_setWatchdogPrescaler(SYSCTL_WD_PRESCALE_64);
SysCtl_enableWatchdog();

When I look at the disassembly code, turning off optimizations results in more code (function calls)

With Optimizations :

Without Optimizations

When the watchdog reset doesn't occurs I can see that the register is configured the same way as when it works :

The WDCNT then increases to 0x00FF then returns to 0 but without triggering a reset.

Tests seem to show that when configuring Watchdog Mode it's necessary to apply a certain delay before activating the watchdog, otherwise sometimes the reset doesn't occur even if the register indicates that the watchdog reset is enabled.

Can you confirm the problem and what would be the recommended workaround?

Thanks

over 2 years ago

0 Vivek Singh over 2 years ago

TI__Guru** 117481 points

Hi,

We have below section in our device TRM -

Vivek Singh

0 Nicolas Audouy over 2 years ago

Prodigy 30 points

Hi Vivek,

Thanks, I found similar topic with the same issue:

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1188459/tms320f280025c-watchdog-stops-triggering-or-never-triggers

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1067391/tms320f280023c-watchdog-stops-triggering/3963305?tisearch=e2e-sitesearch&keymatch=watchdog#3963305

What I don't understand is that the function SysCtl_setWatchdogMode will write the SCSR register that are not in this list. If I comment the line to configure the watchdog mode it's ok. Does the register SCSR must be in the table 3.15?

As another member mentioned, the SW watchdog is part of the security features and the fact that it doesn't always seem to be properly configured is worrying. All register indicate a normal watchdog operation / configuration but the reset will not appear in some case.

Perhaps an errata description would help to better identify the precautions to take for a correct configuration of the watchdog

0 Prarthan Bhatt over 2 years ago in reply to Nicolas Audouy

TI__Mastermind 20706 points

Hi Nicolas,

The issue is related to the registers having limitation where there is clock domain crossing from SYSCLK to INTOSC1.

Optimization will affect how register writes are placed, hence you see the difference in the behavior.

Nicolas Audouy said:
What I don't understand is that the function SysCtl_setWatchdogMode will write the SCSR register that are not in this list. If I comment the line to configure the watchdog mode it's ok. Does the register SCSR must be in the table 3.15?

No, SCSR is not in the list of the registers in INTOSC1 domain.

I would recommend that you use the latest c2000ware where we have added the delays after each register write that has this limitation in the driverlib function itself.

Example:

Thanks.

0 Nicolas Audouy over 2 years ago in reply to Prarthan Bhatt

Prodigy 30 points

Hi Prarthan

Thanks, I can confirm that if we use the C2000Ware library in v5.2, it's ok.

Is there somewhere the complete list of bugs fixed in each release of C2000Ware?

For example between the v5.2 and v5.3 I can found a change for SPI

Or another delay added in sysctl :

But without any details on the release note

0 Prarthan Bhatt over 2 years ago in reply to Nicolas Audouy

TI__Mastermind 20706 points

Hi Nicolas,

Nicolas Audouy said:
Or another delay added in sysctl :

The sysctl delay was there before we just created a define for the delay for better code structure.

Nicolas Audouy said:
For example between the v5.2 and v5.3 I can found a change for SPI

If you can create a thread just for the release notes query regarding 5.3 changes, we will assign that to software team and ask for further clarifications as needed.

Thanks

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F280039C: No watchdog reset if no delay applied between config and activation