• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 540 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/TMDSIDK437X: Debugging Secondary Bootloader (SBL) in CCS

Liliane Paradise
Intellectual 320 points
Part Number: TMDSIDK437X

Tool/software: Code Composer Studio

Hi community,

We are currently working on a custom board based on the TMDSIDK437X. Since the custom board does not have the I2C EEPROM, we added a custom board to the PDK build with the information originally stored on the EEPROM hardcoded. In order to verify the correct functionality of the modified secondary bootloader (SBL), it would be helpful to port the SBL into a CCS project. As stated in  the build for starterware included in the package only supports make based build.
Does that mean it is not possible to debug the SBL via CCS?
If not, can you give me some hints on how I can verify the functionality of the modified SBL? It seems that this question has been answered for Linux U-Boot, but not for RTOS starterware. 

Regards,
Liliane

  • 0
    TI__Guru** 116170 points

    Liliane,

    Debugging the modified bootloader using CCS has ben explained here:

    http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_Foundational_Components.html#software-debug-steps

    The secondary bootloader like any application can be loaded over JTAG or from a boot media. When you load the SBL (.out or .xe<core>) over JTAG, the binary and symbols will be loaded so it shows in the CCS debug view. When you load the SBL using a boot media like UART or SDcard or flash media, the binary is loaded by the ROM bootloader(RBL) so you will need to load the symbols only over JTAG to correlate the loaded SBL binary with the source.

    Debugging SBL in CCS doesn`t require you to create a project in CCS however CCS will need help to locate the source, so you may need to browse to the directory containing SBL_main.c so CCS can locate the full source relative to that file. CCS editor will prompt you when you load the binary and the PC is at main to locate the source on your PC.

    Regards,

    Rahul  

  • 0 in reply to Rahul Prabhu
    Intellectual 320 points

    Hi Rahul,

    Thank you for your prompt response. Your answer helped me to debug the starterware demo apps.
    However I have a follow-up question.
    To my best understanding if I load the code via XDS debug probe by launching a target configuration, the board initialization will be executed solely by the corresponding GEL file, and any executable located in the starterware folder will not be executed? I was unsure about this but when I tried to disable the initialization of the DDR, any changes in the starterware code had no impact. Can you tell me if my understanding is correct? If yes, then the secondary bootloader is only loaded when booting via boot media such as qspi, right?

    Any advice is greatly appreciated.

    Thank you in advance,

    Liliane

  • 0 in reply to Liliane Paradise
    TI__Guru** 116170 points

    Liliane,

    Sorry for the delayed response. 

    your understanding is partially correct. when you create a target configuration with GEL file associated with it and connect to the target. The GEL function for OnTargetConnect will run through and initialize the clocks and DDR.  However, when debugging boot, you can create a target configuration without the GEL file. Then do a CPU reset and load the secondary bootloader code to debug the boot process. If you have the remaining application programmed in QSPI then you can see the secondary bootloader copy the image from QSPI into onchip or DDR memory and branch to the application entry point.

    Regards,

    Rahul