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.将blinky.axf传递给Keil的fromelf.exe实用程序--bincombined --cpu = cortex-M0选项以获得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.脚本发送图像并将其校验和与设备报告的内容进行比较，此处的成功。
6.获取CRC后，脚本会发送回ACK = 0x06。
7.此时执行似乎没有开始, 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
嗨kyflores，
在使用Keil构建项目后，您不必通过该实用程序传递.1458x_sdk \ 5.0.4 \ projects \ target_apps \ peripheral_examples \ blinky \ keil_5 \ Out目录，您将能够找到相应的。十六进制文件。如果自定义PCB正常运行并且由于FW成功下载到设备，那么我就不会看到任何对您所描述的程序都不发出错误。关于您对SP和PC所提到的值，在通过JTAG下载代码的情况下，您将通过Keil加载这些值，因此由于ROM Booter（从外部设备启动时）将照顾那些二进制文件一旦Donwloaded进入设备。尝试通过Smart Scippets UART Booter卸载代码，并检查电路板是否应该这样运转。
谢谢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
...等等：1000000000980020A5040020AD040020C5040020B5
:1000100000000000000000000000000000000000E0
：100020000000000000000000000000000000000000000000000000dd040000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000dd04000000000000000000000000000000000000000000000000000000000000000000000000000000000000000dd0400000000000000000000000000000dd040020cf.
：1000300000000000000000000000f5040020fd1d00206d.
:1000400035230020232400200D310300112400203B
或者，在某种程度上，Keil将以直接兼容的不同格式输出其.hex文件？对不起，如果这是一个明显的问题，我们不会使用Keil作为我们的主要开发工具。
无论如何，我给了Smart Scippets A Go，它的工作正常，所以我的加载脚本一定是错误的。我比较了来自Smart Scippet的装载机和我的波形，看起来我的最终ACK = 0x06来自PC侧的到达比智能片段更高。您认为这可能导致图像加载到RAM，但执行无法启动吗？
Thanks!
-Kyle
嗨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.
谢谢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.