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.

AM6442: UART_UNIFLASH FAIL: EVM AND CUSTOM BOARD

Other Parts Discussed in Thread: UNIFLASH, SYSCONFIG

Dear all,

I am writing to seek your assistance with an issue I am encountering while using Uniflash on my custom board.

My custom board utilizes a QSPI instead of the OSPI found on the EVM. To address this difference, I modified the sysconfig and successfully passed all QSPI-related tests.

Next, I attempted to rebuild the sbl_uart_uniflash example for the AM64x-EVM, located at "..\examples\drivers\boot", and adapt it for my board. Unfortunately, this was unsuccessful.

As an alternative, I tried building and running the unmodified sbl_uart_uniflash example for the AM64x-EVM. However, the program appears to get stuck at step 2, forcing me to cancel the operation.

Here is the output from the console:

C:\ti\mcu_plus_sdk_am64x_08_06_00_45\tools\boot>python uart_uniflash.py -p COM8 --cfg sbl_prebuilt/am64x-evm/default_sbl_null_hsfs_tq.cfg
Parsing config file ...
Parsing config file ... SUCCESS. Found 2 command(s) !!!
Executing command 1 of 2 ...
Found flash writer ... sending sbl_prebuilt/am64x-evm/sbl_uart_uniflash_hsfs_tq.tiimage
Sent flashwriter sbl_prebuilt/am64x-evm/sbl_uart_uniflash_hsfs_tq.tiimage of size 332110 bytes in 34.51s.
Executing command 2 of 2 ...
Command arguments : --file=sbl_prebuilt/am64x-evm/sbl_null.release.hs_fs.tiimage --operation=flash --flash-offset=0x0
Sending sbl_prebuilt/am64x-evm/sbl_null.release.hs_fs.tiimage: 0%| | 0/273693 [00:00<?, ?bytes/s]
[ERROR] XMODEM send failed, no response OR incorrect response from EVM OR cancelled by user,
Power cycle EVM and run this script again !!!
C:\ti\mcu_plus_sdk_am64x_08_06_00_45\tools\boot>python uart_uniflash.py -p COM8 --cfg sbl_prebuilt/am64x-evm/default_sbl_null_hsfs_tq.cfg

Interestingly, running the default_sbl_null_hsfs.cfg with the default sbl_uart_uniflash.release.hs_fs.tiimage works as expected.

It is important to note that I did not make any modifications to the SDK in use or Sysconfig of the example. I am currently using version 8.6.0.45.

I would be grateful if you could help me identify the cause of this issue. Additionally, I would like to know if it is possible to debug the SBL via JTAG by loading the application onto the EVM.

Thank you for your time and assistance.

Sincerely,

Isaac Yuki

  • Hi Isaac,

    If you are having custom flash part on your board, there is no point in trying the unmodified or prebuilt sbl_uart_uniflash as they are bound to fail. I see you have tried modifying the sbl_uart_uniflash to adapt to your custom board.

    Could you please let me know if you have integrated the custom flash configurations in sbl_uart_uniflash? If yes, could you please share the flashing logs w.r.t to your modified sbl_uart_uniflash.

    I would like to know if it is possible to debug the SBL via JTAG by loading the application onto the EVM.

    You may refer to the following FAQ for this

    [FAQ] AM62X/AM64X : [FAQ] Debugging SBL boot in RTOS SDK - Processors forum - Processors - TI E2E support forums

    Regards,

    Prashant

  • I'm sry, I meant I tried it on the EVM.

  • Hi Isaac,

    I am a little confused here. So, you have your custom board and TI AM64x EVM (not SK, EVM is big green one) as well. And you have tried the sbl_uart_uniflash but it is failing on both boards, right?

    Regards,

    Prashant

  • Right, but I think I might have found the problem. Give me a sec, if it doesn't fail, I will mark this thread as done and open a new one, because as I said on the CUSTOM BOARD* it's not working. Thx for the quick reply!

  • Hello ,

    following result.. I remembered that I changed the ospi_flash.c file under board/flash/ospi. Now building the raw example and loading the.tiimage(hsfs) into the EVM-board does work untill the point that it is done with flashing:

    ``` cmd

    C:\ti\mcu_plus_sdk_am64x_08_06_00_45\tools\boot>python uart_uniflash.py -p COM8 --cfg sbl_prebuilt/am64x-evm/default_sbl_null_hsfs_tq.cfg

    Parsing config file ...
    Parsing config file ... SUCCESS. Found 2 command(s) !!!

    Executing command 1 of 2 ...
    Found flash writer ... sending sbl_prebuilt/am64x-evm/sbl_uart_uniflash_hsfs_tq.tiimage
    Sent flashwriter sbl_prebuilt/am64x-evm/sbl_uart_uniflash_hsfs_tq.tiimage of size 333924 bytes in 32.7s.

    Executing command 2 of 2 ...
    Command arguments : --file=sbl_prebuilt/am64x-evm/sbl_null.release.hs_fs.tiimage --operation=flash --flash-offset=0x0
    Sent sbl_prebuilt/am64x-evm/sbl_null.release.hs_fs.tiimage of size 273661 bytes in 28.24s.
    [STATUS] ERROR: Flash verify failed !!!

    All commands from config file are executed !!!

    ```

    (By the way, question: are the built images only for hsfs boards or would they work on GP as well? Is important, because the custom board I have is a GP architecture). 

  • Hello Isaac,

    [STATUS] ERROR: Flash verify failed !!!

    This error basically means that when the sbl_uart_uniflash reads back the image from OSPI after writing, it did not match with the received image over UART and hence the verification failure. This may happen in case you still have the custom changes in the OSPI driver.

    Have you made sure there are no more custom changes in the OSPI driver? In case of any doubt, you can do a fresh install of the SDK and try flashing with the same.

    By the way, question: are the built images only for hsfs boards or would they work on GP as well

    The MCU+ SDK v8.6 has support for both GP and HS boards. The GP images are identified by the extensions (.tiimage & .appimage). Please note the MCU+ SDK v8.6 is the last release that support GP devices. The newer releases v9.x have dropped the support for GP devices in an effort to move to HSFS devices by default.

    Regards,

    Prashant

  • Oh I thik that it might be the problem, that if you change the OSPI-File you have to rebuild the library right? And I think I've done it

  • if you change the OSPI-File you have to rebuild the library right?

    Yes, this is indeed the case. After any changes in the source folder, you would want to rebuilt the libs with

    gmake -s libs PROFILE=release
    gmake -s libs PROFILE=debug

    and then rebuild whatever example you are using.

    If you think you have done these steps & still failing, could you please try fresh install of the SDK.

  • Ok it seemed to work, it were the library changes. I'm sry.  I think I will open another thread related to this because of my custom board.

    Still just to confirm:

    If I build the project I get these bin files: 

    (1)`sbl_uart_uniflash_am64x-evm_r5fss0-0_nortos_ti-arm-clang.tiimage` 

    (2)`sbl_uart_uniflash.Debug.hs_fs.tiimage`

    Image (1) would be for the GP architecture right?

    Thank you for your help!

  • No worries, happy to help.

    Image (1) would be for the GP architecture right?

    Yes, this is correct.

    I think I will open another thread related to this because of my custom board.

    Sounds good. I will close this thread then.

  • Hello again

    Gotta reopen this Thread, because now I'm getting problems with the prebuilt sbl_ospi_hs_hs.tiimage..

    When booting the application on the EVM from OSPI I get following message:

    ```

    DMSC Firmware Version 8.6.4--v08.06.04 (Chill Capybar
    DMSC Firmware revision 0x8
    DMSC ABI revision 3.1

    Some tests have failed!!

    ```

    Tried loading the hello world app.

    I must mention that I've made some modifications to the flash writer itself:

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1264559/am6442-use-the-uart_uniflash-tool-to-flash-the-sbl_null-program-to-qspi-flash-and-report-an-error and removed the DDR of the Sysconfig of the sbl_uart_uniflash.

    But in my understanding this should not lead to the problem.

    Best regards,

  • Hello again,

    But in my understanding this should not lead to the problem.

    There shouldn't be any problem as long as the flashing is successful. But may I know why you are changing the sbl_uart_uniflash if you are using it for TI EVM?

    When booting the application on the EVM from OSPI I get following message:

    I suspect the issue comes because of Authentication failure which is performed on HS boards. You can once try skipping the Authentication check & see if the application boots.

    Please uncheck the "Application Image is X509 Signed" box in the Sysconfig of SBL OSPI like shown below. Unchecking this ensures there are no Authentication checks performed.

    Let me know if this change boots the example.

    Regards,

    Prashant

  • There shouldn't be any problem as long as the flashing is successful. But may I know why you are changing the sbl_uart_uniflash if you are using it for TI EVM?

    Yeah I'm testing if the change would actually work, since I do not wish to use the DDR Ram on my custom board for flashing applications for now(as it would also require having the right DDR configs).

    I suspect the issue comes because of Authentication failure which is performed on HS boards. You can once try skipping the Authentication check & see if the application boots.

    Please uncheck the "Application Image is X509 Signed" box in the Sysconfig of SBL OSPI like shown below. Unchecking this ensures there are no Authentication checks performed.

    Ok I'll give it a try. Could you maybe explain why exactly this is necessary?

    Thx!

  • It worked... Still I understood it that way, that the application has to be X509 signed right? What does that mean and why?

  • the application has to be X509 signed right? What does that mean and why?

    So, the Authentication checks are something that are specifically done on HS devices to enforce secure booting.

    The appimage is signed with a X509 certificate resulting in the bootable image with extension `.appimage.hsfs`. The SBL at run time first requests the System Firmware to do authentication of the image. Only if the authentication is successful, the SBL goes ahead and boots the application.

    Now, the failure you observe "Some tests have failed!!!" might have been caused by this Authentication failure of the appimage & so the SBL did not boot the appimage.

    What I suggested was to basically skip this authentication check (not recommended at all for production on HS devices) & see if the appimage boots. In this case, the SBL at run time will directly boots the appimage without any checks.

    Regards,

    Prashant

  • Ok how do I generate a .hsfs image? Or is this a common feature of all generated images through CCS? 

  • Ok how do I generate a .hsfs image? Or is this a common feature of all generated images through CCS? 

    Okay, so did you flash the Hello World image named something `hello_world*.appimage` before. If yes, this explains why you observed that failure. The examples images with extension `.appimage` are plain images not signed and so they are meant for GP devices where no authentication checks are performed.

    For HSFS device, you need to specifically flash the HSFS appimages identified with extension `.appimage.hs_fs` for the authentication check to pass. These HSFS appimages are generated along with GP appimages by default for all examples as you can note here for the Hello World example.

    ~/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang main
    ❯ make -s all
    Generating SysConfig files ...
    Running script...
    Validating...
    info: /kernel/dpl/debug_log uartLog.baudRate: Actual Baudrate Possible: 115385 (0 % error)
    Generating Code (example.syscfg)...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_dpl_config.c...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_dpl_config.h...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_drivers_config.c...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_drivers_config.h...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_drivers_open_close.c...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_drivers_open_close.h...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_pinmux_config.c...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_power_clock_config.c...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_board_config.c...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_board_config.h...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_board_open_close.c...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_board_open_close.h...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_enet_config.c...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_enet_config.h...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_enet_open_close.c...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_enet_open_close.h...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_enet_soc.c...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_enet_lwipif.c...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_enet_lwipif.h...
    Writing /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/generated/ti_pru_io_config.inc...
    Compiling: am64x:r5fss0-0:nortos:ti-arm-clang hello_world.release.out: ../../../hello_world.c
    Compiling: am64x:r5fss0-0:nortos:ti-arm-clang hello_world.release.out: ../main.c
    Compiling: am64x:r5fss0-0:nortos:ti-arm-clang hello_world.release.out: generated/ti_drivers_config.c
    Compiling: am64x:r5fss0-0:nortos:ti-arm-clang hello_world.release.out: generated/ti_drivers_open_close.c
    Compiling: am64x:r5fss0-0:nortos:ti-arm-clang hello_world.release.out: generated/ti_board_config.c
    Compiling: am64x:r5fss0-0:nortos:ti-arm-clang hello_world.release.out: generated/ti_board_open_close.c
    Compiling: am64x:r5fss0-0:nortos:ti-arm-clang hello_world.release.out: generated/ti_dpl_config.c
    Compiling: am64x:r5fss0-0:nortos:ti-arm-clang hello_world.release.out: generated/ti_pinmux_config.c
    Compiling: am64x:r5fss0-0:nortos:ti-arm-clang hello_world.release.out: generated/ti_power_clock_config.c
    .
    Linking: am64x:r5fss0-0:nortos:ti-arm-clang hello_world.release.out ...
    Linking: am64x:r5fss0-0:nortos:ti-arm-clang hello_world.release.out Done !!!
    .
    Boot image: am64x:r5fss0-0:nortos:ti-arm-clang /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/hello_world.release.appimage ...
    Generating certificate for hello_world.release.appimage ...
    Boot image: am64x:r5fss0-0:nortos:ti-arm-clang /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/hello_world.release.appimage Done !!!
    .
    Boot image: am64x:r5fss0-0:nortos:ti-arm-clang /home/p-shivhare/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/hello_world.release.appimage.hs_fs Done !!!
    .
    
    ~/ti/mcu_plus_sdk/am64x/08_06_00_45/examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang main*
    ❯ ls -l hello_world.release.appimage.hs_fs
    -rw-r--r-- 1 p-shivhare p-shivhare 27730 Feb 15 18:09 hello_world.release.appimage.hs_fs

  • ok, yes now I see. Yes, for now I think we can close this issue.

    Thank you very much for your support! It was very helpfull.

  • Always happy to help!!!

    I will close this thread. Feel free to create another thread for your custom board related issue.