• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 55 subscribers
  • Views 1524 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.

Original question:

[FAQ] Compiler/TMS320F28377D: Copy flash code to ram issue using BINIT and table() operator

Compiler/TMS320F28377D: Watchdog is disabled or blocked by debugger

John Zhou
Intellectual 460 points

Part Number: TMS320F28377D

Tool/software: TI C/C++ Compiler

Hi,

Previously I encountered a problem where the copy of BINIT table was taking too long so that the watchdog is triggered during stand-alone boot.

The problem was solved by disabling the watchdog in code_start. However, if I connect the device to the debugger and the device is being debugged, the application works fine, and watchdog is not triggered.

The TI engineer who answered my previous posts said that when the device is being debugged, debugger will automatically disable the watchdog, which I have checked that after loading the program and the application being taken to main(), watchdog is disabled.

But what confuses me is that during debug, after I "reset" in CCS and "resume", the application works fine as well. Here is what I did:

1. Load the application to flash and chose the emulation boot to flash. After loading, I saw that the watchdog was disabled and application stopped at main().

2. In code_start, I do not disable the watchdog.

3. Put a breakpoint at the beginning of code_start.

4. After "reset", watchdog was disabled. But after "resume" in CCS and the application stopped at the start of code_start. watchdog was enabled again(checked WDCR register). 

After "reset":

After "resume" and stopped at "LB  _c_int00":

Now in theory, after "reset" and "resume", device will go through the emulation boot flow, and trigger the watchdog since it has not enough time to copy the BINIT table, and watchdog is enabled again after the emulation boot flow and before it enters code_start.

5. I then pressed the "resume" twice, however, the application can safely run to main() where the other breakpoint was inserted and run the rest of its course without triggering the watchdog.

As mentioned above, watchdog was enabled again after "resume"(presumably during the boot flow) and before code_start can even execute, then why the watchdog was not triggered later on? I have checked the RESC register, WDRSn was not set during the experiment. It means that watchdog didn't even triggered. So is this because the time needed for the copy of BINIT table is shorter when the debugger is connected? Or is this because debugger will block the watchdog reset entirely even prevent the WDRSn bit in RESC register from being set?

Regards,

John

  • 0
    TI__Guru** 116601 points

    Hi Zhou,

    So is this because the time needed for the copy of BINIT table is shorter when the debugger is connected? Or is this because debugger will block the watchdog reset entirely even prevent the WDRSn bit in RESC register from being set?

    Debugger does not block the watchdog reset. So the possibility is that CPU taking less time to copy BINIT table after debug reset and emulation boot. As per the BOOT flow, in emulation boot, PLL is not bypass so if your application code locks the PLL after power-up and then you connect to debugger and issue debug reset (which does not reset PLL settings) then CPU may be running faster hence take less time to copy the BINIT table.

    Can you check the PLL register setting after CPU halts at code_start ?

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Intellectual 460 points

    Hi Vivek,

    Sorry for the late reply. I've been out of my office for a few days and just got back.

    I reproduced the situation and it was exactly as you said. The clock was different. The PLL had already been enabled and locked as I "reset" and "resume" my application in CCS while the watchdog was not disabled manually in code_start. While it was left running by itself, the device was using the internal 10MHz clock to copy the BINIT table in _c_int00, which would be much slower compared to the SYSCLK after I set the PLL.

    Thank you so much for your insight. Really appreciated.

    Best regards,

    John