|
【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方式烧写。
|
|