【NXP Rapid IoT评测】SWD烧写程序注意事项

cruelfox

【NXP Rapid IoT评测】SWD烧写程序注意事项 [复制链接]

　　Rapid-IoT 可以使用SWD进行调试，如果没有购买 hexiwear 底板，也不打算自己做扩展板的话，可以撬开外壳，把SWD的信号飞出来接现有的 xxLink 调试器。具体从哪里连线见我前头发的帖子　https://bbs.eeworld.com.cn/thread-1065854-1-1.html
　　现在说一下 SWD 烧写程序的注意事项，因为我原来不知道，遇到过小麻烦。

　　通过 rapid-iot-studio 在线IDE的编译功能，可以直接得到编译好的 .bin 文件，然后从USB下载到 Rapid-IoT 里面运行（办法是按住SW3按钮，也就是左上方那个，再捅背后的复位按钮复位MCU. MCU重启后，USB识别出可移动磁盘，可将 .bin 文件 copy 过去，然后 Rapid-IoT 会执行烧写并在完成后重启）。这个烧写功能是 MCU (K64) 的固件自带，属于 bootloader. 我在 SDK 里面见到过 bootloader 目录。
　　于是我开始认为在线生成的 .bin 里面是包含 bootloader 的，也就是说 USB 功能其实也在里面，只是启动时 SW3 必须是按下的才能切换到 bootloader 模式。

　　但是我第一次用 Jlink OB 将在线IDE生成的 .bin 通过SWD连接写到 FLASH 0x0起始处（查K64手册，FLASH是从内存0x0地址开始）之后，重启动却没有起来(屏幕无显示，串口也没反应)。当然 SWD 并没有挂掉，还是能用的，它不大可能变砖。
　　幸好，我第一次用 SWD 连接时就把 FLASH 内容读出来保存到电脑上了。于是我把保存的文件重新写回 FLASH，重启，它又活过来了。
　　那么是什么环节出了问题呢？我将这个在线生成的 .bin 用 USB 方式烧写一次，然后重启，再用 SWD 连接上去，将 FLASH 内容全部读出来保存成文件，比较下两个文件的不同看看吧。

　　的确这两次结果的 FLASH 内容是不一样的，从一开始的中断向量表就大不相同了，所以我从 SWD 烧写的不正确。

　　那么下载的 .bin 到哪里去了？加密存放没有必要，于是找找看。检索文本比较方面，很快就比对到了：

　　注意前面的地址，0x7BEE00-0x67EE00 = 0x14000. 也就是说，很可能工程的.bin文件实际上存放在 FLASH 的 0x14000 开始的地方。于是我从 dumpdemo.bin 的 0x14000 处开始与 demo.bin 文件比较，发现后面内容完全相同。
　　这样问题就清楚了。如果要通过 SWD 将在线 IDE 编译得来的 .bin 文件烧写进 MCU (K64)，那么要写到 FLASH 的 0x14000 地址。在 JLink Commander里面命令就是 loadbin xxxx.bin 14000 ，而前面这 80kB 的 FLASH 空间是留给 bootloader 用的，bootloader 负责 USB 烧写方式。

　　那么，如果是自己本地编译的工程呢，该烧写到哪个地址？这里也要分情况，要看程序的执行地址是多少。例如我编译的这个（用的常规的K64 linker script），从 objdump 打印出的信息看，代码是从 0 地址开始存放的：

　　因此，这种情况下就必须写到 FLASH 的 0 地址了，原先的bootloader也被清除，以后也只能用SWD方式烧写。