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] TDA4VM: Debugging SBL boot in RTOS SDK

Part Number: TDA4VM


I am trying to boot TDA4VM using SBL, but it does not work. Can someone please share a procedure debug the SBL.

  • Hi,

    This FAQ share some general guidelines to debug SBL related issues for RBL -> SBL -> RTOSApp boot flow.

    This boot flow debug can be broken into following two parts:

    • Control transfer from RBL -> SBL
    • SBL debug

    Control transfer from RBL –> SBL

    There could be a case where ROM is not able to bring up SBL. This could be due to various reasons. If you can see some logs from the SBL, then this section can be skipped. If you don’t see any logs at all from the SBL then check the following:

    1) BootMode Pin Settings

    Please make sure that boot mode is set properly. If you are using EVM, you can find the relevant boot mode settings in the user guide document. Check J721e_EVM setup guide here. If you are using a custom board then please refer to the initialization section of the TRM.

    NOTE: Please note that ROM code initializes the peripheral according to the boot pin settings and SBL is built assuming these initializations will happen before SBL takes over. So, bypassing the boot pin settings may result into SBL issues.

    2) SBL Image

    Depending on the type of access, make sure SBL is available as required by the ROM. In a file system type of access, ROM looks for tiboot3.bin. So, in case when booting with MMCSD with filesystem type access the SBL is renamed as tiboot3.bin. In case of raw access, ROM generally looks for SBL at the start of the memory. So, if booting from OSPI in raw mode, make sure SBL is flashed at 0x0.

     3) Memory Mapping

    There may be a case where the SBL is not compliant with the memory map expected by ROM code. R5 ROM will also use MCU OCM RAM and if SBL has some loadable sections in those regions being used by ROM then MCU R5F will crash in ROM code. If you are making any modifications to the SBL memory map, make sure it is complaint with what is expected by ROM

    If all the above points are taken care then ROM should be able to bring up SBL and pass the control to SBL


     SBL Debug

    In order to single step through SBL, please follow the below steps:

    1) Modify the SBL

    Modify the main() function in <PDK>\packages\ti\boot\sbl\board\k3\sbl_main.c to add an infinite while loop. Create a volatile variable and loop on it at the start of the main function.

    2) Build SBL in debug mode

    Please refer to the FAQ to see how to build SBL for debugging here

    3) Connect to CCS and single step

    Once the SBL is built in debug mode with above changes. Put the SBL is relevant boot media and boot. Then connect to the MCU R5F core. Make sure you don’t run any gel script or the launch.js

    Once the R5F is connected, load the symbols. Once you load the symbols you should see the target halted at while(ccsHalt) loop we created above. If you don’t see target halted, it means RBL is not able to load SBL, please go to the previous step and ensure everything is correct.

    If you see the target halted at the while loop, change the value of ccsHalt variable from 1 to 0. Then, you should be able to single step through the SBL all the way to app. 

    Single stepping through SBL will help you figure out if there are any issues with the SBL

    Note: Please note that the DMSC Watchdog will reset if the system is held in the while loop for more than 3 minutes. This is because TIFS will pet the DMSC watchdog and if that is not loaded within 3 minutes, the SoC will reset.