[FAQ] AM62X/AM64X : [FAQ] Debugging SBL boot in RTOS SDK

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 AM62x 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. 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 <MCU+SDK>\examples\drivers\boot\sbl_null\am62x-sk\r5fss0-0_nortos\main.c to add an infinite while loop. Create a volatile variable (say halted) and loop on it at the start of the main function.

2) Build SBL in debug mode

Run the following command from the root of MCU+SDK.

gmake -s -C ../../examples/drivers/boot/sbl_null/am62x-sk/r5fss0-0_nortos/ti-arm-clang PROFILE=debug

3) Connect to CCS and single step

Once the SBL is built in debug mode with above changes. Put the SBL to relevant boot media and boot. Then connect to the MAIN Cortex 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(halted) 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 variable named halted 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.

Regards,

Tushar