This post relates to getting the flashloader built and loaded/running on RT1064 using sdphost.
Our end goal is to customise the flashloader with some added functionality (as part of the
provisioning workflow). So the first step is getting the SDK flashloader example working.
I can debug load/run the flashloader from mcuxpresso, but when I try to load the binary using sdphost, it resets the CPU. Here is the .sb file I am using to create the bootable image.
options {
flags = 0x00;
startAddress = 0x20000000;
ivtOffset = 0x400;
initialLoadSize = 0x2000;
#entryPointAddress = 0x20002000;
}
sources {
elfFile = extern(0);
}
section (0)
{
}
=====
I create the image using the command:
elftosb.exe -f imx -V -c imx-unsigned.bd -o ivt_1064_flashloader.bin Debug/evkmimxrt1064_flashloader.axf
I load the image using the commands:
./sdphost.exe -u 0x1fc9,0x0135 -V -- write-file 0x20000000 ivt_1064_flashloader.bin
./sdphost.exe -u 0x1fc9,0x0135 -V -- jump-address 0x20000400
Subsequently, the CPU resets.
I have tried attaching the debugger (just before running sdphost commands) and the debugger halts on main, but I can't get it to halt on Reset_Handler. It looks like the reset handler is not run, as data is not properly initialized and the system resets after a CPU exception. However, I can see that the reset handler address is valid in both the ivt and the arm vector table. (In contrast the reset handler is clearly run when I load the program using mcuxpresso debugging.)
Here is a partial dump of ivt_1064_flashloader.bin
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000400 00d1 4020 24a1 2000 0000 0000 0000 0000
0000410 0420 2000 0400 2000 0000 0000 0000 0000
0000420 0000 2000 3b88 0001 0000 0000 0000 0000
0000430 0000 0000 0000 0000 0000 0000 0000 0000
*
0002000 e600 2020 24a1 2000 24ed 2000 bd8d 2000
0002010 24e9 2000 24e9 2000 24e9 2000 0000 0000
0002020 0000 0000 0000 0000 0000 0000 24f5 2000
I'd appreciate it if anyone can direct me how to get the flashloader example working with sdphost. Thanks.
Peter
Hi @astrobuf
Many thanks for contacting us. My apologies for the delayed response.
The elftosb is now obsolete.
If you want to use low level tool commands, please make sure to install latest version of the Secure Provisioning SDK. See installation details here: Installation Guide I want to ensure that you have latest version of the BLHOST, SDPHOST and the nxpimage, which replaces elftosb.
Now, there is another trick to evaluate this with ease. First install our MCUXpresso Secure Provisioning Tool v8, currently this is the latest version currently. I mention this tool since uses the same tools from the SPSDK, and plus contains reference bd files and scripts.
If you create a new workspace, for instance, I am using RT1020, when you click on start flashloader option, the log will show that the tool builds the flashloader.bin using a bd file and srec. See an example below.
### Build flashloader as unsigned bootable image ###
nxpimage hab export -c "C:...\bd_files\unsigned_MIMXRT1020_flashloader_win.bd" -o "C:..\bootable_images\unsigned_MIMXRT1020_flashloader.bin" "C:\nxp\MCUX_Provi_v8\bin\_internal\data\targets\MIMXRT1020\flashloader.srec"
Success. (HAB container: C:\Users\nxf59533\secure_provisioning40000000044060434525941000\bootable_images\unsigned_MIMXRT1020_flashloader.bin created.)
nxpimage succeeded
Actually, the SPSDK is now implementing a new nxpimage tool, described over here https://spsdk.readthedocs.io/en/latest/apps/nxpimage.html
A quick test that you can do is import our flashloader demo from the SDK, and find where the tool replace the tool's flashloader.srec by yours. I found that the tool places flashloader screc for the RT1064 in this address : MCUX_Provi_v8\bin\_internal\data\targets\MIMXRT1064
The tool should use the flashloader that you created and then you can take commands as an example.
Please let me know if this helps you!!!
Diego
I got a couple of recommendations. This GUI loads our flashloader to write images and provision fuses etc using NXP tools , such as BLHOST, SDPHOST and elftosb.Those tools are contained in the MCUXpre
I tried using elftosb on s-records file, accordingly to information in the i.MX MCU Manufacturing User's Guide. See this example from section 4.2:
And guess what, elftosb segfaults with zero indication why. Terrific. By luck I discovered that the identifier "srecFile" must be "elfFile" (even though it's not an elf file) and it finally works.
So.... elftosb silently corrupts your program and also segfaults on simple issues like above. Why after all these years haven't these buggy tools been fixed?
NXP: are you listening?
Disgruntled User
Update: this is exactly the same problem as here https://community.nxp.com/t5/i-MX-RT/elftosb-issue/m-p/994838
elftosb is silently truncating the data section from the program image. It requires s-records file to be used.