Hi,
I'm trying to bootload from UART via an FT232 breakout acting as a com port for a python pyserial script that implements the boot protocol described in AN-B-001. The DA14580 is mounted on a custom PCB. So far, I believe I've produced a viable binary image that successfully loads onto the DA14580 chip, but execution does not seem to start afterwards. Here are the steps I have taken so far that led me to this conclusion:
1. Build Blinky project from the SDK (projects/peripheral_examples/blinky) as-is, producing blinky.axf.
2. Pass blinky.axf to Keil's fromelf.exe utility with options --bincombined --cpu=Cortex-M0 options to get blinky.bin
3. Pass blinky.bin to python script that trades messages with the device (I could include this if it helps, but omitted for brevity). Script listens for STX = 0x02 from AN-B-001 Table 5.
4. Toggle the reset line on the board, it sends the STX message and script replies, etc.
5. Script sends over the image and compares its checksum to what the device reports, success here.
6. After getting the CRC, script sends back ACK=0x06.
7. At this pointexecution doesn't appear to begin, but attaching to the processor under Segger JLINK tools + gdb and doing 'dump memory' starting at 0x20000000 shows that the image has made it on the device.
I've also found that if I setup Keil to not load its application when starting debug, I can run my bootload script successfully, then attach with Keil and also find my image intact in the memory. While attached with the Keil debugger, I can continue and my the blink app loaded by my script WILL start. I noticed that when entering debug mode, Keil sets $SP = 0x20000000 and $PC = 0x20000004, which I don't think my process can do in any way, but I thought the bootloader did something like this for you.
Anyway, I must be missing a step somewhere so if you could suggest what that might be that would help me greatly. Thanks!
-Kyle
Hi kyflores,
在你建造您的项目使用的解答你dont have to pass the .axf file through that utility, in the DA1458x_SDK\ 5.0.4\ projects\target_apps\ peripheral_examples\ blinky\ Keil_5 \out directory you will be able to find the corresponding .hex file. If the custom PCB operates properly and since the fw is successfully downloaded to the device then i dont see anything that is obvisously wrong to the procedure that you describe. Regarding the values that you mentioned for the SP and the PC those values are loaded via keil in the case of downloading code via JTAG, you dont have to worry about that since the ROM booter (when booting from external devices) will take care of those values as soon as the binary is donwloaded into device. Try to donwload code through the Smart Snippets UART booter and check if the board operates as it should that way.
Thanks MT_dialog
Ah, is that so that you can just load Keil's HEX file as is? When I looked at it in an editor, it looked like intel hex format, here's just a short snippet of what my .hex blob looked like
:020000042000DA
...etc:1000000000980020A5040020AD040020C5040020B5
:1000100000000000000000000000000000000000E0
:10002000000000000000000000000000DD040020CF
:100030000000000000000000F5040020FD1D00206D
:1000400035230020232400200D310300112400203B
Alternatively is there a way that Keil will output its .hex file in a different format that is directly compatible? Sorry if that's an obvious question, we don't use Keil as our primary development tool.
Anyway I gave Smart Snippets a go and it worked fine, so something must be wrong with my load script. I compared the waveforms from Smart Snippet's loader and mine, and it looks like my final ACK = 0x06 from the PC side arrives much later than with Smart Snippets. Do you think that could result in the image loading to ram but execution failing to start?
Thanks!
-Kyle
Hi kyflores,
I 've mentioned that keil outputs a .hex file format since you 've mentioned that you have explictly made the conversion from an .axf file, what you should download into the device its not the .hex file itself but you will have to convert the .hex file to the corresponding .bin file and then load it to your device (i suppose that you allready do that since you 've mentioned that when you attach the debugger you can see the image and the image is able to run, unless if you dont properly configure keil and it re-downloads the same fw when attaching). You will be able to convert the .hex to a .bin file using the hex2bin.exe located in the DiaSemi\SmartSnippetsStudio\Toolbox\common_resources\firmware_upload. This is also what Smart Snippets does when you load the .hex file. Regarding the fact that its takes time for your ACK to reach the device from the script, yes, there is a timeout when the device expects data from the external device, this timeout is about 60 ms, so yes this is a valid reason for your script not to boot.
Thanks MT_dialog
I had a look again how my script was sending the final ack on closer inspection (it was wrong, AND late) and there was a problem there that needed attention. Thanks for mentioning the component of SmartSnippets to do the hex -> bin conversion though, that's helpful to know too. I would say that this is resolved.