Author Topic: LM3S6XXX watchdog  (Read 8925 times)

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3236
    • View Profile
    • uTasker
LM3S6XXX watchdog
« on: November 12, 2007, 02:05:35 AM »
Hi All

Here are some details of my first experiences with the watchdog:


The LM3S6965 contains a watchdog timer. This is used to monitor that the system is operating correctly and can generate an NMI and system reset when it triggers. The watchdog solution is not bad since it allows the user to protect a running watchdog against run away code manipulating it. It times out twice before performing a hardware reset (if it is enabled), first with an interrupt and then after a second timeout with the reset.

When running with 50MHz system clock a watchdog timeout period of up to about 85 seconds is possible. To configure the required time, the define WATCHDOG_TIMEOUT_MS has been added to the project configuration file app_hw_lm36xxx.h. This time is the sum of the two timeout periods since the interrupt is effectively ignored.
The watchdog is also used to command a reset of the board. In this case the lock state is removed (by writing 0x1acce551 to the register WDTLOCK) and then setting a zero timeout period.

Can the watchdog stop the debugger loading to FLASH?

The first time I started working with the watchdog enabled I also started to have problems with the debugger. The debugger worked fine until I wanted to download new code, and then it couldn’t program the FLASH any more; the error was that it couldn’t download the flash loader.

I had the impression that the watchdog was still running after a reset and was possibly causing the problem because the debugger could not turn it off, although the debugger log said that it had deactivated the watchdog. I tried with a second board and the result was identical – I now had two boards which no longer accepted downloads and I started to get a bit panicky!

The solution to recover the board was to delete the FLASH by using the connected debugger (connect by suppressing download and letting the program on the board configure the PLL to 50MHz) and commanding the mass erase command. That is, write 0xa4420004 to the address 0x400fd008. The register USECR at address 0x400fe140 is set by default to 0x31 which sets the FLASH erase time to suit 50MHz clock.

After erasing the complete flash it is then necessary to power down the board (otherwise the watchdog seems to still be actively causing the problem) and then the debugger can load new code correctly.

I will be watching this and updating this section when more details are known. At least I am not so nervous any more because the recovery process is not so complicated…



« Last Edit: November 23, 2007, 07:54:28 PM by mark »