Other Parts Discussed in Thread: TMDS64EVM, UNIFLASH
I'm working with a TMDS64EVM evaluation module from TI (HS-FS AM64x EVM, PROC101C(004) revision) and MCU-PLUS-SDK-AM64X v09.01.00.41. For some context on my goals at this time, I'm just doing my best to verify the default support before introducing any of my own changes to the software or hardware.
- After following the default MCU+ install steps, I am able to use uart_uniflash.py to flash the OSPI NOR with the pre-built SBL_NULL. This works great and the SBL_NULL boots successfully and consistently.
- When I attempt to use uart_uniflash.py to flash the OSPI NOR with the pre-built SBL_OSPI, I am running into trouble that closely resembles the issue reported in the parent e2e thread
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1202676/processor-sdk-am64x-cannot-ospi-boot-the-hs_fs-application-image-on-am6442-a53-core/4562451?tisearch=e2e-sitesearch&keymatch=TMDS64EVM%25252520sbl_ospi#4562451
Problem 1:
Attempting to use the default_sbl_ospi.cfg with uart_uniflash.py yields the following error:
C:\ti\mcu_plus_sdk_am64x_09_01_00_41\tools\boot>python uart_uniflash.py -p COM36 --cfg=sbl_prebuilt\am64x-evm\default_sbl_ospi.cfg
Parsing config file ...
Parsing config file ... ERROR. 1 error(s).
[ERROR] Parsing error found on line 30 of sbl_prebuilt\am64x-evm\default_sbl_ospi.cfg
[ERROR] File not found !!!
Checking the C:\ti\mcu_plus_sdk_am64x_09_01_00_41\examples\drivers\ipc\ipc_rpmsg_echo\am64x-evm\system_freertos_nortos directory seems to indicate that the default v09.01.00.41 MCU+ is missing the pre-built ipc_rpmsg_echo_system.release.appimage_xip file required for the unmodified default_sbl_ospi.cfg to work.
Is this a known issue with MCU+ v09.01.00.41 or am I missing some setup step?
Problem 2:
In an attempt to workaround Problem1 (above), I imported the hello_world_am64x-evm_r5fss0-0_nortos_ti-arm-clang example into CCS (I didn't make any changes to the example once imported) and built it successfully.
I tested the resulting hello_world_am64x-evm_r5fss0-0_nortos_ti-arm-clang.out binary using the SBL_NULL (using JTAG and CCS to load the .out) and it works successfully and consistently.
I then updated default_sbl_ospi.cfg to reflect the following:
#-----------------------------------------------------------------------------#
# #
# DEFAULT CONFIGURATION FILE TO BE USED WITH THE FLASHWRITER SCRIPT #
# #
#-----------------------------------------------------------------------------#
#
# By default this config file,
# - points to pre-built flash writer, bootloader for this EVM
# - The application image points to relative path of the ipc echo application image for this EVM
# - Make sure this application is built before running this script
# - You can customized this config file to point to your own bootloader and/or application images
# - You can use --operation=flashverify if you just want to verify the flash contents and not flash the file.
#
# First point to sbl_uart_uniflash binary, which function's as a server to flash one or more files
--flash-writer=sbl_prebuilt/am64x-evm/sbl_uart_uniflash.release.hs_fs.tiimage
# Now send one or more files to flash or flashverify as needed. The order of sending files does not matter
# Program the OSPI PHY tuning attack vector
--operation=flash-phy-tuning-data
# When sending bootloader make sure to flash at offset 0x0. ROM expects bootloader at offset 0x0
--file=sbl_prebuilt/am64x-evm/sbl_ospi.release.hs_fs.tiimage --operation=flash --flash-offset=0x0
# When sending application image, make sure to flash at offset 0x80000 (default) or to whatever offset your bootloader is configured for
#--file=../../examples/drivers/ipc/ipc_rpmsg_echo/am64x-evm/system_freertos_nortos/ipc_rpmsg_echo_system.release.appimage.hs_fs --operation=flash --flash-offset=0x80000
--file=../../../workspace/hello_world_am64x-evm_r5fss0-0_nortos_ti-arm-clang/Release/hello_world_am64x-evm_r5fss0-0_nortos_ti-arm-clang.appimage.hs_fs --operation=flash --flash-offset=0x80000
# send the XIP image for this application, no need to specify flash offset since flash offset is specified within the image itself
#--file=../../examples/drivers/ipc/ipc_rpmsg_echo/am64x-evm/system_freertos_nortos/ipc_rpmsg_echo_system.release.appimage_xip --operation=flash-xip
--file=../../../workspace/hello_world_am64x-evm_r5fss0-0_nortos_ti-arm-clang/Release/hello_world_am64x-evm_r5fss0-0_nortos_ti-arm-clang.appimage_xip --operation=flash-xip
Using this new default_sbl_ospi.cfg with uart_uniflash.py seemed to be successful:
C:\ti\mcu_plus_sdk_am64x_09_01_00_41\tools\boot>python uart_uniflash.py -p COM36 --cfg=sbl_prebuilt\am64x-evm\default_sbl_ospi.cfg
Parsing config file ...
Parsing config file ... SUCCESS. Found 5 command(s) !!!
Executing command 1 of 5 ...
Found flash writer ... sending sbl_prebuilt/am64x-evm/sbl_uart_uniflash.release.hs_fs.tiimage
Sent flashwriter sbl_prebuilt/am64x-evm/sbl_uart_uniflash.release.hs_fs.tiimage of size 320037 bytes in 31.75s.
Executing command 2 of 5 ...
Command arguments : --operation=flash-phy-tuning-data
Sent flash phy tuning data in 3.49s.
[STATUS] SUCCESS !!!
Executing command 3 of 5 ...
Command arguments : --file=sbl_prebuilt/am64x-evm/sbl_ospi.release.hs_fs.tiimage --operation=flash --flash-offset=0x0
Sent sbl_prebuilt/am64x-evm/sbl_ospi.release.hs_fs.tiimage of size 322349 bytes in 31.93s.
[STATUS] SUCCESS !!!
Executing command 4 of 5 ...
Command arguments : --file=../../../workspace/hello_world_am64x-evm_r5fss0-0_nortos_ti-arm-clang/Release/hello_world_am64x-evm_r5fss0-0_nortos_ti-arm-clang.appimage.hs_fs --operation=flash --flash-offset=0x80000
Sent ../../../workspace/hello_world_am64x-evm_r5fss0-0_nortos_ti-arm-clang/Release/hello_world_am64x-evm_r5fss0-0_nortos_ti-arm-clang.appimage.hs_fs of size 51435 bytes in 7.55s.
[STATUS] SUCCESS !!!
Executing command 5 of 5 ...
Command arguments : --file=../../../workspace/hello_world_am64x-evm_r5fss0-0_nortos_ti-arm-clang/Release/hello_world_am64x-evm_r5fss0-0_nortos_ti-arm-clang.appimage_xip --operation=flash-xip
Sent ../../../workspace/hello_world_am64x-evm_r5fss0-0_nortos_ti-arm-clang/Release/hello_world_am64x-evm_r5fss0-0_nortos_ti-arm-clang.appimage_xip of size 52 bytes in 2.94s.
[STATUS] SUCCESS !!!
All commands from config file are executed !!!
After powering off the EVM and changing the boot mode to OSPI Boot, I get inconsistent behavior at boot:
DMSC Firmware Version 9.1.6--v09.01.06 (Kool Koala) DMSC Firmware revision 0x9 DMSC ABI revision 3.1 [BOOTLOADER_PROFILE] Boot Media : NOR SPI FLASH [BOOTLOADER_PROFILE] Boot Media Clock : 166.667 MHz [BOOTLOADER_PROFILE] Boot Image Size : 0 KB [BOOTLOADER_PROFILE] Cores present : r5f0-0 [BOOTLOADER PROFILE] SYSFW init : 12166us [BOOTLOADER PROFILE] System_init : 570us [BOOTLOADER PROFILE] Drivers_open : 288us [BOOTLOADER PROFILE] Board_driversOpen : 21916us [BOOTLOADER PROFILE] Sciclient Get Version : 9895us [BOOTLOADER PROFILE] CPU Load : 15624us [BOOTLOADER_PROFILE] SBL Total Time Taken : 60465us Image loading done, switching to application ... Hello World! DMSC Firmware Version 9.1.6--v09.01.06 (Kool Koala) DMSC Firmware revision 0x9 DMSC ABI revision 3.1 Some tests have failed!! DMSC Firmware Version 9.1.6--v09.01.06 (Kool Koala) DMSC Firmware revision 0x9 DMSC ABI revision 3.1 Some tests have failed!! DMSC Firmware Version 9.1.6--v09.01.06 (Kool Koala) DMSC Firmware revision 0x9 DMSC ABI revision 3.1 Some tests have failed!! DMSC Firmware Version 9.1.6--v09.01.06 (Kool Koala) DMSC Firmware revision 0x9 DMSC ABI revision 3.1 Some tests have failed!! DMSC Firmware Version 9.1.6--v09.01.06 (Kool Koala) DMSC Firmware revision 0x9 DMSC ABI revision 3.1 Some tests have failed!! DMSC Firmware Version 9.1.6--v09.01.06 (Kool Koala) DMSC Firmware revision 0x9 DMSC ABI revision 3.1 Some tests have failed!!
This seems to be the same issue encountered in the parent e2e thread, except for the hardware being an unmodified TDS64EVM (nothing custom) and a newer MCU+ version (based on the different DMSC firmware version shared in the parent e2e thread).
After about 30 boots I got a successful boot 1/30, so successful boots seem to be possible but very rare
- I'm fairly certain the only successful boot was on the very first OSPI boot attempt, mentioning this because I haven't been able to get another successful boot since.
Please advise if I am making any critical errors in my procedure, I'm curious if this is working for anyone at TI.
