• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 594 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RM48 DWD (Digial Window Watchdog), Response and operation in Debug Mode

stomp
Genius 4705 points

Other Parts Discussed in Thread: RM48L952

Hi,

I am facing a complex issue with validation of the DWD functionality, we are using the DWD with 100% window for now. And I note (BIG Note) that the COS (Continue on Suspend) bit in RTIGCTRL is 0 (meaning counters are halted in debug mode).

We have an RM48L952, main application is in FLASH bank 0, Bootloader is in Bank 1.

During testing, we vector to the bootloader application by performing a jump to Bank 1. The startup code for the bootloader executes a sub-set of the _c_int00(), however we do not re-run any of the BIST's, PARITY or Memory tests.

I can connect to the RM4 and debug the bootloader in "connect only mode" (i.e. do not load the binary), I can set break points and verify that the bootloader is entered.

What I am seeing is:

  • I can only use the first breakpoint;
  • If I try and run to a second breakpoint (even if that breakpoint is on the next line) I get a WDT end violation and a reset.
  • When stepping through code I can see the WDT counter decrement as I would expect and I do not get a WDT violation.

So my question is what is the actual behavior here of the WDT during debug->run conditions?.

It appears that any attempt to run code causes an immediate WDT violation despite the the WDTCNTR being in excess of 0x01FFFF00.

Any suggestions would be appreciated?

Thanks

Stomp!

  • 0
    TI__Guru 59540 points
    Hello Stomp,

    My apologies for the delay in answering, however, we are in the process of investigating the issue you have described.
  • 0
    TI__Guru 59540 points
    Hello Stomp,

    After conferring with some colleagues, is it possible for you to change the configuration of your watchdog to perform an interrupt so that you can trap the issue in the ISR and double check the counter value to see if this is really what is going on. The reason for asking is that the counter is reset to 0 when the reset occurs and we would like to know what the real value of the counter was/is when the second breakpoint is hit.