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.

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

Part Number: TMS320F28377D

Tool/software: TI C/C++ Compiler

Hi,

Background:

I was trying to run my code from flash memory but some of the functions were being executed from ram for better performance. In the cmd file, table operator and BINIT was used and I hope the auto copy feature of bootloader would be able to copy the code from flash to ram during boot time.

Problem description:

When the debugger was connected, the project worked fine. The compiler built the project without any error messages, and after debug button was clicked, the debugger can take the application to main automatically and the code could safely run from there after I pressed run.

However, if I disconnect the debugger and press the reset button(on board) to reset the device, the program was stuck. I have a LED flashing function in main() to indicate the program was running well, but LEDs were not flashing. If I power down the device and power up again(with or without the debugger connected), program would not run still.

Possible cause:

I saw a thread posted on the forum with similar issue. In their case, the cause was that the code that needs to be copied was too large, so that it took bootloader too long to copy it and the watchdog was tripped. If that is also the cause for my problem, I have a question that I wish you guys could help me with.

In the boot28.asm, I can see that if binit and table operator are used, there are codes that will be used to copy the relative functions from flash to ram during boot time. If watchdog is the cause of this issue, than why in my case the watchdog was not tripped when the debugger was connected and the device was being debugged? Isn't that strange that the watchdog only trips when debugger was disconnected or the device was not being debugged?

I mean whether the debugger is connected or not, or whether the device is being debugged or not, the code_start function and _c_int00 function should be executed under all conditions to set up C environment. Then why in the case where the device was being debugged, the watchdog did not trip? Is the watchdog reset interrupt being blocked by debugger when the device is being debugged? Thank you all for any help.

Regards,

John

  • John,

    John Zhou said:
    I saw a thread posted on the forum with similar issue. In their case, the cause was that the code that needs to be copied was too large, so that it took bootloader too long to copy it and the watchdog was tripped.

    You can check if the cause of your issue is watchdog related by disabling watchdog at the very beginning of code_start routine. In this case the watchdog will be disabled prior to calling the c_int00 routine in boot28.asm that processes the BINIT tables. 

    When the code is loaded and debugged using CCS, GEL files are typically used to set up and initialize target to a state that is necessary for connecting the debugger. Although I haven't verified it is quite likely that the watchdog is disabled in the GEL file during target connect so the behavior is not triggered when debugging using CCS but only when running stand-alone. 

    Hope this helps.

  • Hi Aarti,

    Thank you so much for your thoughts. That's exactly what I am looking for.

    AartiG said:

    You can check if the cause of your issue is watchdog related by disabling watchdog at the very beginning of code_start routine. In this case the watchdog will be disabled prior to calling the c_int00 routine in boot28.asm that processes the BINIT tables. 

    I will check it like you said and let you know the result. But I don't have a test board currently beside me. I will do that in 2 days once I get my hands on the test board when I'm back to my office.

    AartiG said:

    When the code is loaded and debugged using CCS, GEL files are typically used to set up and initialize target to a state that is necessary for connecting the debugger. Although I haven't verified it is quite likely that the watchdog is disabled in the GEL file during target connect so the behavior is not triggered when debugging using CCS but only when running stand-alone. 

    If that's the case, then it definitely explains a lot. If you are able to verify that later on, could you please let me know the results? Thank you so much.

    Regards,

    John

  • Hi Aarti,

    I have done checking the issue with the watchdog disabled. It is true that the watchdog is the one that's been causing the problem.

    Once I disabled the watchdog at the beginning of CodeStartBranch.asm(code_start function), application can be safely loaded into flash and run without the debugger connected and without the device being debugged.

    It seems very likely that the assumption that watchdog has been disabled while the device being debugged and before the application being taken to main() by the debugger is correct. Anyway, could you let me know the results if you are able to verify this? Thank you very much.

    Best regards,

    John

  • Glad to hear that your issue is resolved.

    John Zhou said:
    It seems very likely that the assumption that watchdog has been disabled while the device being debugged and before the application being taken to main() by the debugger is correct. Anyway, could you let me know the results if you are able to verify this?

    Yes, that is the case, and you can even confirm this yourself by checking the WDCR register in the CCS Registers view when using CCS to debug.

  • Hi Aarti,

    I have checked the WDCR register. Watchdog was disabled after I pressed "debug" button in CCS.

    Thank you so much for your help.

    Regards,

    John