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.

AM62D-Q1: Load SBL_NULL with USB-DFU

Part Number: AM62D-Q1

Hi experts,

I am planning to use USB-DFU for tasks such as booting SBL_NULL for debugging and launching prototype images. Could you please clarify which binary should be loaded when I want to boot SBL_NULL via USB? Reference: U-Boot DFU User Guide

As a test, I ran the following command to load sbl_null.release.hs_fs.tiimage: WinPC > dfu-util.exe -R -a 0 -D AM62D_11.2\sbl_null.release.hs_fs.tiimage

Following this, I was able to successfully connect to the C7x core via CCS and load a .out file.

However, according to the documentation below, it appears that USB-DFU is not officially supported by the RTOS SBL (SBL_NULL): SBL Examples and Support

Could you please provide the official procedure or best practices for achieving this?

Best regards,
O.H

  • Hi,

    However, according to the documentation below, it appears that USB-DFU is not officially supported by the RTOS SBL (SBL_NULL): SBL Examples and Support

    This is correct, support for SBL DFU or DFU flashing is not added in MCU+SDK.

    You could boot SBL NULL via DFU as ROM can still boot the first stage image if your SoC is set to DFU boot mode, but as you would also need to load the DM firmware to the DM R5 core, this would not be useful.

    Best Regards,

    Meet.

  • Hi Meet,

    Thank you for your reply.

    This is correct, support for SBL DFU or DFU flashing is not added in MCU+SDK.

    You could boot SBL NULL via DFU as ROM can still boot the first stage image if your SoC is set to DFU boot mode, but as you would also need to load the DM firmware to the DM R5 core, this would not be useful.

    Are there any plans to add support for SBL DFU?
    If there are no plans at this time, could you please share the reason?
    SBL DFU is supported on AM64x. AM64x MCU+ SDK: SBL DFU

    I would like to confirm the following.
    If the premise is that the application .out file is loaded via CCS, is it acceptable to load sbl_null.release.hs_fs.tiimage or sbl_emmc.release.hs_fs.tiimage using DFU?
    In addition, although the warning shown below is reported, is it reasonable to assume that the bootloader is checking the AppImage stored in QSPI and that this is where the version mismatch is occurring?

    WARNING: Bootloader_rprcImageLoad:270: Software version mismatch, Installer version 0xb020014, AppImage version 0xb010010 Some tests have failed!!

    Best regards,
    O.H

  • Are there any plans to add support for SBL DFU?

    There are no plans to add this currently.

    If there are no plans at this time, could you please share the reason?

    I will check internally for this and get back to you, could you let me know why there is a requirement for you to boot from USB DFU for you? And if there is any problem with using any other boot mode like UART or OSPI?

    If the premise is that the application .out file is loaded via CCS, is it acceptable to load sbl_null.release.hs_fs.tiimage or sbl_emmc.release.hs_fs.tiimage using DFU?

    You can load your first stage image, but once you load any .out to your C7x you will get stuck on Sciclient_init as you have not loaded your DM appimage to DM R5 yet. 

    When using SBL NULL you can use a workaround to avoid this issue. SBL NULL tries to load the DM appimage from 0xC0000 offset in the flash, so you can flash your DM firmware only once to the location so that your SBL NULL can load the DM and after that just keep loading SBL NULL from USB DFU, this should solve the problem.

    In addition, although the warning shown below is reported, is it reasonable to assume that the bootloader is checking the AppImage stored in QSPI and that this is where the version mismatch is occurring?

    This is correct, please refer to this: https://software-dl.ti.com/mcu-plus-sdk/esd/AM62DX/latest/exports/docs/api_guide_am62dx/APPIMAGE_SW_VERSION.html 

  • Hi Meet,

    Thank you for your reply.

    I will check internally for this and get back to you, could you let me know why there is a requirement for you to boot from USB DFU for you? And if there is any problem with using any other boot mode like UART or OSPI?

    While UART and QSPI are also possible, USB currently offers the best convenience for customers during debugging. It also serves as one of the update options for the final product.

    You can load your first stage image, but once you load any .out to your C7x you will get stuck on Sciclient_init as you have not loaded your DM appimage to DM R5 yet. 

    When using SBL NULL you can use a workaround to avoid this issue. SBL NULL tries to load the DM appimage from 0xC0000 offset in the flash, so you can flash your DM firmware only once to the location so that your SBL NULL can load the DM and after that just keep loading SBL NULL from USB DFU, this should solve the problem.

    I can't confirm this because "dfu-util" suddenly became unavailable on my PC's system... But I understand that debugging is possible even if a WARNING is displayed, as long as "Starting NULL Bootloader ..." is progressing. This is because it has already been written to QSPI (or eMMC).

    Best regards,
    O.H

  • Hi Meet,

    Sorry for rush you.

    Is there any update? or Do you have any additional comments?

    Best regrads,
    O.H

  • Hi,

    Support for USB DFU and USB related drivers is not added for any AM62XX devices in the MCU+SDK, As the Linux SDK supports flashing via USB DFU for these devices, users mostly utilize that if they have a requirement for flashing via USB DFU. I can raise a request internally to get this implemented for AM62D freertos SDK, but this will likely be not implemented anytime soon.

    For now, you can use any other boot media, and at least for testing purpose you can use the discussed workaround: 

    When using SBL NULL you can use a workaround to avoid this issue. SBL NULL tries to load the DM appimage from 0xC0000 offset in the flash, so you can flash your DM firmware only once to the location so that your SBL NULL can load the DM and after that just keep loading SBL NULL from USB DFU, this should solve the problem

    Please let me know if you are facing any issue with the same.

    Best Regards,

    Meet.

  • Hi Meet,

    Thank you for your reply.

    Support for USB DFU and USB related drivers is not added for any AM62XX devices in the MCU+SDK, As the Linux SDK supports flashing via USB DFU for these devices, users mostly utilize that if they have a requirement for flashing via USB DFU.

    As a confirmation, please tell me the method for writing to the flash device (OSPI NOR flash for AM62DEVM) using USB DFU boot, as described: "As the Linux SDK supports flashing via USB DFU for these devices,."
    Q: Could you provide example commands about2(such as setenv, dfu-util -R)?
    1: Boot u-boot via DFU
    2: Write to QSPI via DFU 

    Reference:
    3.1.2.3. SD, eMMC and USB — Processor SDK AM62Ax Documentation
    3.1.2.5. OSPI/QSPI NOR/NAND — Processor SDK AM62Ax Documentation - [Flashing Images to OSPI NAND using TFTP server], [Flashing images to OSPI NAND using SD card]

    Best regard,
    O.H
  • Hi Meet,

    Sorry for rush you. Is there any update? or Do you have any additional comments?

    Best regrads,
    O.H

  • Hi,

    For booting u-boot using DFU you can refer to this guide: https://texasinstruments.github.io/processor-sdk-doc/processor-sdk-linux-AM62DX/esd/docs/master/linux/Foundational_Components/U-Boot/UG-DFU.html 

    And then for flashing OSPI from u-boot you can refer to this thread: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1622373/am625-q1-how-to-flash-ospi_nor-ospi_nand-flash-by-dfu-booting/6254698

    This is for am62x but the procedure should be same for am62d as well.

    Best Regards,

    Meet.

  • Hi Meet,

    Sorry for late reply. Thank you for your support.

    We understood. If any further questions arise, I will create a new thread.

    Best regards,
    O.H