• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 417 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.

AM263P4: AM263Px OSPI Boot - "SBL failed!!" error

Şule Nur Demirdaş
Prodigy 10 points
Part Number: AM263P4
Other Parts Discussed in Thread: SYSCONFIG, UNIFLASH

Tool/software:

Hello,

I am working with an AM263Px development board and trying to run the sdl_ccm_example from the MCU+ SDK. After flashing the application via UART, I switch to OSPI boot mode, but the board fails to boot and I receive an "SBL failed!!" error on the serial terminal.

Development Environment:

  • Board: AM263Px EVM

  • SDK Version: MCU+ SDK 10.02.00.15

  • CCS Version: 12.8.1

  • SysConfig Version: Project is configured for v1.23.0

Steps I Have Taken:

  1. I imported the sdl_ccm_example_am263px-cc_r5fss0-0_nortos_ti-arm-clang project into Code Composer Studio.

  2. I set the DIP switches on the EVM to UART boot mode.

  3. I build the code and flashed the .appimage file to the board using the uart_uniflash.py script with the following command:

    python uart_uniflash.py -p COM25 --cfg=C:\ti\mcu_plus_sdk_am263px_10_02_00_15\tools\boot\sbl_prebuilt\am263px-cc\default_sbl_ospi.cfg
  4. I receive a [STATUS] SUCCESS !!! message after each step, including flashing the application binary.
  5.  I set the DIP switches to OSPI boot mode.

  6. I then power-cycled the board and monitored the serial terminal.

The Problem:

Even with a successful flash, when the board attempts to boot from OSPI, the terminal displays the following message and hangs:

Starting OSPI Bootloader ...

SBL failed!!

My Questions:

  1. Since both the SBL and the application binaries are flashed successfully, what are the common reasons for the SBL to fail during the boot sequence?

  2. Could this issue be related to the application's memory map or linker settings? The application is being flashed to 0x81000, as defined in the default config file. Is this the correct offset for this example?

  3. Are there any debugging steps I can take to get more information about why the SBL is failing? For instance, is it possible to enable a more verbose boot log?

I would appreciate any guidance on how to troubleshoot this further.

Thank you

  • 0
    TI__Expert 3430 points

    Hi ,

    Apologies for the delay!!

    Can you please let me know which AM263P CC are you using SIP / NON- SIP? Quick way to identify if to see if an ISSI flash part is on the board.
    Did you change any thing in the SBL_OSPI ?

    Şule Nur Demirdaş said:
    how to troubleshoot this further.

    Can you debug and check where it is getting failed? Please refer to this FAQ for SBL debug.


    Thanks & Regards,
    Rijohn

  • 0 in reply to Rijohn Pius
    Prodigy 10 points

    Hi Rijohn,


    I have resolved the original     SBL failed!! issue. Instead of using the uart_uniflash.py script, I used the UniFlash tool with the settings shown in the image below. This successfully flashed the SBL and the application.

    For reference, my board's serial number is S26D0074.

    However, I have encountered a new issue. After successfully flashing the sdl_ccm_example, the application starts, but it hangs after printing the first few lines. Here is the complete output I see on the serial terminal:

    Starting OSPI Bootloader ...
    KPI_DATA: [BOOTLOADER_PROFILE] CPU Clock : 400.000 MHz
    KPI_DATA: [BOOTLOADER_PROFILE] Boot Media : NOR SPI FLASH
    KPI_DATA: [BOOTLOADER_PROFILE] Boot Media Clock : 133.333 MHz
    KPI_DATA: [BOOTLOADER_PROFILE] Boot Image Size : 39 KB
    KPI_DATA: [BOOTLOADER_PROFILE] Cores present :
    r5f0-0
    KPI_DATA: [BOOTLOADER PROFILE] System_init : 617us
    KPI_DATA: [BOOTLOADER PROFILE] Drivers_open : 137us
    KPI_DATA: [BOOTLOADER PROFILE] LoadHsmRtFw : 8448us
    KPI_DATA: [BOOTLOADER PROFILE] Board_driversOpen : 2741us
    KPI_DATA: [BOOTLOADER PROFILE] CPU load : 4628us
    KPI_DATA: [BOOTLOADER PROFILE] SBL End : 18us
    KPI_DATA: [BOOTLOADER_PROFILE] SBL Total Time Taken : 16590us

    Image loading done, switching to application ...
    R5 CPU Application
    CCM Example Test Started: R5F0

    It seems the application is freezing during the CCM test initialization. Since the SBL is now working, what could be causing the application itself to hang at this specific point? Are there any common configuration issues with the CCM example that I should check in SysConfig?

    Thank you again for your help.

  • 0 in reply to Şule Nur Demirdaş
    TI__Expert 3430 points

    Hi ,

    I am reassigning the query to sdl_ccm SME. SDL team will help you further on this.

    Thanks & Regards,
    Rijohn

  • 0 in reply to Rijohn Pius
    Prodigy 30 points

    Hi  

    It is known issue(PROC_SDL-9151), and we are working with SBL team. Can you use as workaround CCS or r5fss1-0 core.

  • 0 in reply to Rajesh Chinnasamy
    Prodigy 10 points

    Hi  ,

    I have an update on my issue. I've found a specific flashing sequence that works, which might help identify the problem.

    First, I use UniFlash to load the sbl_ospi.tiimage and the application image for the r5fss1-0 core. After this step, the terminal output is corrupted:

    Starting OSPI Bootloader ...
    AUÕ¹�Ñ¥½¹…±¥ÑåA…ÍÍ•‘±±Ñ•ÍÑÍ¡…Ù•Á…ÍÍ•‘ÿ

    Next, I load the application image for the r5fss0-0 core without erasing the flash first.

    After this sequence, I soft reset the board and the sdl_ccm example runs perfectly with the correct output.

    However, if I only flash the r5fss0-0 image after a full erase, the application hangs. It seems that flashing the r5fss1-0 image first is setting some required configuration on the flash.