• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 82 subscribers
  • Views 1323 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.

CCS/TMS320F28377D: entry point when debugger is connected

John Zhou
Intellectual 460 points
Part Number: TMS320F28377D


Tool/software: Code Composer Studio

Hi,

I am currently looking into the boot process of TMS320F28377D and there are a few things that bother me. I wish you guys could shed some lights on it.

1. It is my understanding that if the debugger is connected and the device is being debugged, the device will enter emulation boot and end up in wait boot(for an unprogrammed device). So my question is that in this state, does the debugger take the application directly to the entry point no matter where it has been allocated in the memory? For example if I set up the entry point to be a random symbol such as "c_start", is the debugger going to set the PC the address of this symbol under this condition?

2. When the device is running on itself, after reset the device will start the standalone boot which will boot the device to flash(if boot to flash was chosen) and start the application at address 0x80000. Under this condition, the entry point set in the CCS is useless. Is my understanding correct?

3. In the auto-run debug option of CCS, auto-run to main is chosen. It is my understanding that this will set a breakpoint at main(). So when the device is being debugged, are all the interrupts, for example watchdog reset, going to be blocked by the debugger before main()? In other words, if watchdog has overflown before main(), for example during the execution of _c_int00, is there going to have a watchdog reset serviced by the device?

Please help me with the confusion according to the question number. Any ideas would be appreciated.

Many thanks.

Regards,

John

  • 0
    TI__Mastermind 30255 points

    John

    1. When in wait boot and you load an application, the debugger will try run to main() starting from the entry point specified in CCS project properties.

    2. Yes that's right, need to make sure in your linker that you have your starting function (ex: c_int00)  at the 0x80000 entry address

    3. Yes, watchdog is enabled and can timeout during c_int00. It possible for the device to reset and you won't reach main(). If you refer to your codestartbranch.asm file, you'll see that there is an option to disable watchdog before calling c_int00

    Best regards

    Chris

  • 0 in reply to Christopher Chiarella
    Intellectual 460 points

    Hi Chris,

    Thank you so much for your reply. It's really helpful. I was wondering if I discuss some of the issues further.

    1. In the Workshop Guide and Lab Manual_F2837xD_Microcontroller_MDW_2-0.pdf, page 111, it says the following:

    Does that mean that after clicking debug, CCS will bypass the bootloader and the settings in CPU1 EMU_BOOTCTRL Register are useless?

    2. I may have found a contradiction. In Workshop Guide and Lab Manual_F2837xD_Microcontroller_MDW_2-0.pdf, page 70, it says that if EMU_BMODE=0x03, OTP_KEY != 0x5A, emulation boot process will boot the device to flash. However, in TMS320F2837xD Technical Reference Manual.pdf, page 586, it says that "When an emulator is connected (TRSTn = 1) to the device, then an invalid key or invalid boot mode value results in wait boot mode.". Could you please confirm which one is correct?

    3. 

    Christopher Chiarella said:

    3. Yes, watchdog is enabled and can timeout during c_int00. It possible for the device to reset and you won't reach main(). If you refer to your codestartbranch.asm file, you'll see that there is an option to disable watchdog before calling c_int00

    I am working on a project in which I am using BINIT and table() in cmd file to copy some of the codes from flash to ram in _c_int00 function(there is a DO_BINIT symbol in _c_int00). When the device is not connected to the debugger, it seems that the copy takes so long that the watchdog tripped and the application was stuck. However, if I connect the debugger and click debug button, the application can safely be taken to main() and start from there as if the watchdog has not functioned in the way when the debugger was disconnected. Do you know what might cause this issue? Please let me know your thoughts. Thank you.

    Regards,

    John

  • 0 in reply to John Zhou
    TI__Mastermind 30255 points

    John,

    1. When loading an app, the boot code will not be run and as it states, the program will start from c_int00. In this case, the EMU values are irrelevant. The EMU is used so you can test out boot configurations before programming OTP. What you can do is load your app, config your EMU values, then perform a reset through CCS, and run. This will then do the full flow through boot code to c_int00 to app.


    2. I see the confusion. There is two keys, one for the EMU control word and one for the OTP boot config. If the EMU key is invalid, then it will default to wait boot. EMU key must be valid in order to use the EMU boot mode that is configured. In regards to GetMode, if the OTP key isn't valid, then it will default to flash boot. If the OTP key is valid, it will read the bootmode set in OTP. In either instance, if the bootmode decoded is invalid, then in standalone flow, it defaults to flash and when debugger is connected it defaults to wait.


    3. Maybe the window is so close that when watchdog is enabled at the end of boot that the couple lines of code before it gets to c_int00 and then starts its actions there is enough to trigger it. When debugging, you save those couple extra lines of code which may be enough for the app to be reached.

    Best regards
    Chris

  • 0 in reply to Christopher Chiarella
    Intellectual 460 points

    Hi Chris,

    Thank you so much for your reply. I'm really appreciated.

    If I load my app, set the EMU values and reset the CPU through CCS to test the boot configurations, in this way the entry point set in the project properties is useless. Am I correct?

    There is one more thing that I would like to be sure though.

    Christopher Chiarella said:

    2. I see the confusion. There is two keys, one for the EMU control word and one for the OTP boot config. If the EMU key is invalid, then it will default to wait boot. EMU key must be valid in order to use the EMU boot mode that is configured. In regards to GetMode, if the OTP key isn't valid, then it will default to flash boot. If the OTP key is valid, it will read the bootmode set in OTP. In either instance, if the bootmode decoded is invalid, then in standalone flow, it defaults to flash and when debugger is connected it defaults to wait.

    So, do you mean that if the OTP key isn't valid, it will default to flash boot no matter whether the emulator is connected or not? Does that mean that the notation under table 3-7 above is wrong? When the emulator is connected, if EMU_BMODE=0x03 and the OTP key isn't valid, the device will still boot to flash instead of entering the wait boot as it says.

    Now, if that is the case, what will happen if I do the following?

    1. Use RAM configurations(code_start is allocated at the start of RAMM0 in the cmd file)

    2.  Set EMU_BMODE=0x03 with valid EMU key(GetMode through emulation boot flow)

    3. Load the program on an unprogrammed device(OTP key invalid)

    4. Reset the CPU through CCS

    According to your description, if the emulator is connected, as long as the OTP key is invalid, the device will boot to flash. Then in the situation I set above, the device will fail to run the app since it will boot to flash whereas the code_start is at the start of RAM. Am I right?

    Best regards,

    John

  • 0 in reply to Christopher Chiarella
    Intellectual 460 points

    Hi Chris,

    I did some experiments and I have confirmed that if on an unprogrammed device, the emulator is connected and EMU_BMODE=0x03 with valid EMU_KEY and invalid OTP_KEY, the device will boot to flash instead of entering the wait boot mode. The notation under the table3-7 above in the Technical Reference Manual.pdf is wrong I think.

    Best regards,

    John

  • 0 in reply to John Zhou
    TI__Mastermind 30255 points

    John

    Yes, if you're running through boot, then the CCS properties entry point is useless.

    There are two separate keys. If debugger connected and EMU key isn't set, it will set boot mode to wait boot. If booting standalone or emulate standalone or set boot mode to GetMode, then if OTP isn't programmed, it will default to flash boot.
    In your situation, that's correct, if you configure it to use the GetMode, then it will read OTP and because OTP key isn't programmed, it will switch boot mode to flash.

    I will clarify this table notation.

    Best regards
    Chris

  • 0 in reply to Christopher Chiarella
    Intellectual 460 points

    Hi Chris,

    Thank you so much for your help.

    Regards,

    John