• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 578 views
  • Users 0 members are here
Support feedback
Options
Options

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.

AM2434: What is difference between sbl null (ospi boot mode)and load_dmsc.js (no boot mode)?

Moonil Heo
Intellectual 650 points
Part Number: AM2434
Other Parts Discussed in Thread: UNIFLASH

Hi Expert,

I have questions about the difference between "sbl null" (ospi boot mode) and "load_dmsc.js" (no boot mode) in SDK 08.02.00.31.

I thought both are doing the same operation for debug sessions in CCS. We are using both modes, no boot mode and ospi boot mode during our custom flash driver development. However, I found application operation is a bit different based on those of bootmode and script. For example, the application reading flash ID operation did not work with SBL NULL bootup in CCS, but it worked well with "load_dmsc.js" and no boot mode. Could you share your knowledge of their different points?

In addition to the question above, please let me know how to run TI examples of "sbl null" or "sbl ospi" in CCS. When I tried to run debug session and start "main()" for those SBL examples in CCS, the code was waiting for "Sciclient_waitForBootNotification()" infinitely.

I would appreciate it if you share your experience and knowledge on these questions.

Regards,

Moonil

 

 
  • 0
    TI__Mastermind 49015 points

    Hi Moonil,

    The SBL_NULL and CCS JS script are two different ways to initialize the board. They are both doing about the same things (Pinmux, PLL setting, DDR initialization, and release all R5F cores/M4F core from reset etc.). The only difference is that the CCS JS script is used in NO BOOT mode, while the SBL_NULL is used by memory boot (OSPI, SD, even UART boot).

    When you run the SBL_NULL from CCS, it is a awkward running environment. On one side you want to run it from a memory boot mode (OSPI, SD), on the other side you will need to somehow initialize the board for SBL_NULL to run properly. In this case the No Boot mode with CCS JS script is the best. However there is a issue with the CCS JS script for SBL_NULL, because they both will load the SysFW for the DMSC, so what you really need is a customized CCS JS script for SBL_NULL.

    Best regards,

    Ming 

  • 0 in reply to Ming Wei
    Intellectual 650 points

    Hi Ming

    thank you for your kind explanation.

    I enabled a new flash driver for uart_unitflash for our real board but it is not working on our real board as below,

    I would like to trace the code of uart_unflash in CCS, Could you help me to create CCS JS for this?

    I would appreciate it if you share any test version of CCS JS for this.

    Regards,

    Moonil

  • 0 in reply to Moonil Heo
    TI__Mastermind 49015 points

    Hi Moonil,

    I understand you need a customized CCS JS script for debugging the uart_uniflash. I checked the C:\ti\mcu_plus_sdk_am243x_08_03_00_18\tools\ccs_load\am243x\load_dmsc.js, it is all based on the SysFW on DMSC. I will need more time figure out how to customize the JS script.

    Have you tried the boot from SD card using SBL_NULL? Were you able to access the Flash ID with boot from SD card?

    Best regards,

    Ming

  • 0 in reply to Moonil Heo
    TI__Mastermind 25945 points

    Hi Moonil,

    One key difference is that load_dmsc.js loads the image by loading the .out file but SBL NULL is booted via Boot Rom which expects a x509 image. In your image it seems like your uart_uniflash image which is also an x509 image was not accepted by ROM or the uart_uniflash crashed. You can put a loop_forever() function in uart_uniflash application. After the load is completed, you can connect the debugger and debug it to find the failures.

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    Intellectual 650 points

    Hi Ming and Aakash,

    Thanks for your explanation. I wanted to know how to trace uart_uniflash application in CCS from this post.

    To see the reason why uart_uniflash was stuck, I commented out "Bootloader_socWaitForFWBoot();" while using load_dmcs.js (no boot mode). I was able to see the reason and fix the issue. Please see the details in the linked post below. This can be a way to debug uart_uniflash in CCS?

    https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1135297/am2434-for-xspi-custom-flash-driver-for-am2434-step-4-ospi_flash_io-fails-to-read-manufacturer-id-and-device-id/4356966#4356966

    However, there was another issue related to flashing which happened sometimes, which will be addressed in the linked post above.

    Regards,

    moonil

  • +1 in reply to Moonil Heo
    TI__Mastermind 25945 points

    Hi Moonil,

    As discussed over the debug call, the application had the flash erase issue because the command length was set to 4B although the flash was not configured for the same. Hence changing it to 3B (default) should be more consistent and similar behavior is expected on every test cycle.

    Best Regards,
    Aakash