Hi folks,
Having some trouble getting FlashTool to do anything worthwhile under linux Ubuntu 18.10. I do the following with FlashTool for 1020 V1.0;
$ sudo Tools/sdphost/linux/amd64/sdphost -u 0x1fc9,0x0130 -- write-file 0x20000000 Tools/mfgtools-rel/Profiles/MXRT102X/OS\ Firmware/ivt_flashloader.bin
Preparing to send 60415 (0xebff) bytes to the target.
(1/1)1%Status (HAB mode) = 1450735702 (0x56787856) HAB disabled.
Reponse Status = 2290649224 (0x88888888) Write File complete.
$ sudo Tools/sdphost/linux/amd64/sdphost -d -u 0x1fc9,0x0130 -- jump-address 0x20000400
[01 0b 0b 20 00 04 00 00 00 00 00 00 00 00 00 00 00]
<03 56 78 78 56>
Status (HAB mode) = 1450735702 (0x56787856) HAB disabled
$
...and at this point the device re-enumerates as 0x1fc9.0x0130...i.e. it doesn't transfer control over to the flashloader, but appears to reboot. Adding '-d' to the write-file command generates a lot more output (which all looks sane) but doesn't change the result.
If I try this under Windows it _does_ appear to load and re-enumerate and, indeed, if I retain the contents of the memory and re-boot (to re-enumerate to the simple loader that sdptool communicates with) then the jump-address command does seem to work correctly....from which I suspect it's a 'load' issue rather than a 'go' issue. I get the same failure-to-boot issue if I run sdptool over the serial link rather than the USB HID one.
The version of sdptool in the 1050 v1.1 tools appears to be the same as in the 1020 v.1.0 tools so I've not bothered trying that. The binary file being transferred is a bit shorter (60415 bytes) than the one shown in AN12238 (90039 bytes) but I re-downloaded the image with no changes.
Any suggestions? I'm a bit stuck here....
Regards
DAVE
解決済! 解決策の投稿を見る。
OK, problem found. The address in AN12238 Rev. 1 09/2018 are wrong...its trying to load into DTCM rather than just OCRAM. This sequence works correctly;
Tools/sdphost/linux/amd64/sdphost -t 10000 -u 0x1FC9,0x0130 -- write-file 0x20208000 Tools/mfgtools-rel/Profiles/MXRT102X/OS\ Firmware/ivt_flashloader.bin
Tools/sdphost/linux/amd64/sdphost -t 10000 -u 0x1FC9,0x0130 -- jump-address 0x20208400
sleep 1
Tools/blhost/linux/amd64/blhost -u 0x15a2,0x0073 -- get-property 1
Regards
DAVE
Hi Dave Marples,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
According to your description, you're stuck in fail to contact the i.MX RT via the Blhost tool after sdphost executing the jump-address command, is it right?
In furhter, whether this same issue happens at the both of Ubuntu and Window.
If yes, I was wondering if you can upload the complete testing result.
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
OK, problem found. The address in AN12238 Rev. 1 09/2018 are wrong...its trying to load into DTCM rather than just OCRAM. This sequence works correctly;
Tools/sdphost/linux/amd64/sdphost -t 10000 -u 0x1FC9,0x0130 -- write-file 0x20208000 Tools/mfgtools-rel/Profiles/MXRT102X/OS\ Firmware/ivt_flashloader.bin
Tools/sdphost/linux/amd64/sdphost -t 10000 -u 0x1FC9,0x0130 -- jump-address 0x20208400
sleep 1
Tools/blhost/linux/amd64/blhost -u 0x15a2,0x0073 -- get-property 1
Regards
DAVE
Thanks for your reply.
Goad to hear the issue had been solved.
If you have any further questions about it, please feel free to contact me.
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Yes, basically that is correct, except that I can use blhost after I've done the initial sdphost using windows.
I'm not sure what 'complete testing result' you are expecting - the text above is exactly what happens, what else would you like to to provide? blohost ping fails if I try to use it from that point, and both the wrte file and jump sdphost instructions still work, leading me to believe that it's restarted the simple boot handler.
Regards
DAVE