jicheng0622

【原创】飞思卡尔Kinetis结合Segger独立调试工具链J-Link debugger的使用方法

3
阅读(4189) 评论(7)

        前段时间在Segger官网闲逛的时候,发现Segger很低调地发布了一款独立的调试工具链J-Link Debugger,在看完其功能介绍之后,顿时欣喜不已如获至宝(被俺发现“新大陆”了,快成为Segger粉了),赶紧拿起手里的开发板试用了一番,结论是真的好用、非常好用、相当好用,咳咳,重要事情要强调三遍啊有木有,让俺欲罢不能,现在已经成为我调试Kinetis系列的选配工具了。当然这么好用的东西照样不能独享,遂思虑片刻乃分享之,这片刻主要是在考虑要不要找Segger要点广告费啊,这哥们儿太低调了,搞的我这么主动,哎,多不好,哈哈(这段纯属调侃扯淡,毕竟人家都推出好用的工具提升大家开发效率,我们谢人家都来不及,就像其引以为傲的被国人盗版成灾的J-Link,个人认为目前最好用的ARM调试器,无出其右者)。

        好了,扯淡闲聊完毕该整硬菜进主题了。具体J-Link debugger功能介绍,本篇文章就不多做介绍了,大家可以移步Segger官网的J-Link Debugger主页查看并下载,其链接为https://www.segger.com/j-link-debugger.html。本文继续以飞思卡尔Kinetis系列为平台介绍该debugger的使用方法(木办法,俺资深飞粉一枚,不过其他家MCU平台的开发者可以作为参考),当前J-Link Debugger只是独立的调试工具链,我们需要先用飞思卡尔自己的(Codewarrior或者KDS)或者第三方编译器(IAR,Keil等)将码好的项目工程编译好,J-Link Debugger支持加载这些编译器生成的带调试信息文件(比如Codewarrior或者KDS的.elf文件,IAR的.out文件和Keil的.axf文件)或者通用的.bin及S19文件,不过我推荐加载使用带调试信息的文件,这样的话再进入调试模式的话会把相应的源文件加载到调试窗口(与IDE开发环境自带的Debugger功能一个道理),否则加载.bin或S19文件的话只会跟踪一条条的汇编指令,想想应该头很大。本文这里以飞思卡尔免费的KDS为例(有人吐槽KDS自带的GDB调试工具链不大好用,所以直接上J-Link Debugger会是一个没得选的选择,呵呵),下面我先给出测试环境然后详细介绍其具体使用步骤:

测试MCU平台:飞思卡尔基于ARM Cortex-M4内核的Kinetis K22

测试IDE环境:Kinetis Design Studio(KDS)

测试工程:Kinetis SDK1.2(KSDK_1.2.0\examples\frdmk22f\driver_examples\gpio\kds)

(1)先到Segger官网下载最新的J-Link Debugger软件包(上文已给出链接),安装完毕后打开该软件,每次打开软件都会弹出新建项目向导如下,我们首先需要选择好要调试的目标芯片MK22FN512xxx12(FRDM-K22板载芯片型号),然后第二个选择比较有意思即“Peripherals”,这是可选配的,选这个文件的意义在于我们在调试的时候可以在线查看芯片内部所有寄存器内容,而这个文件为.svd文件,即芯片内部的寄存器地址映射表(我提到这里想必大家已经明白为啥需要这个文件才能查看寄存器内容吧,呵呵),不过可惜的是J-Link Debugger没有提供所有芯片厂商的.svd文件(只提供了ARM内核的.svd文件,也就是说只可以查看ARM内核的几个寄存器,估计这也是为啥他为选配的原因吧),不过你这个难不倒咱,它没有但是Keil有,IAR也有啊,哈哈,毕竟他们的debugger也是需要svd文件的啊,这样问题就迎刃而解了,果然是天无绝人之路,如果电脑中安装了Keil或者IAR的话就可以正常选择相应芯片的.svd文件了,如下图所示,我选择的是Keil下的MK22F51212.svd文件,IAR下为.svd.xml文件,里面内容是一样的,都是基于xml语言描述的,且兼容CMSIS标准(不知道吧,svd也是CMSIS标准的组件之一);

image

(2)上述选择完毕之后进入下一步,选择好调试端口,这一步我就不多说了,这个大家都懂的,多说无益;

image

(3)很快来到下一步,这一步是关键的,即我上述提到的需要加载编译器编译生成的带调试信息的文件或者纯image文件,这里我加载的是KDS编译生成的带调试信息的.elf文件,最后点击“finish”即可完成调试工程的创建;

image

(4)上述步骤配置完之后即可看到完整的J-Link Debugger界面了(初始的源文件窗口自动跳到包含main的文件中),如下图所示,我列出了几个基本的窗口,更多的窗口可以通过菜单栏的“View”选择,我们可以看到J-Link Debugger界面虽然不算简洁但是的确是把再调试时该用到的辅助工具都加进来了,大大的方便了我们平时的调试工作,我们码农屌丝的福音啊有木有,哈哈。

image

(6)界面效果我们看过瘾了该进入到最后一步了,得把程序下到单片机中了(汗,原来搞了半天程序还没下进去呢),所有工作准备就绪,我们点击J-Link Debugger界面上方的绿色电源按钮如下图1所示选择“download & Reset Program”即可把源代码下载到单片机中了(通过elf文件的image信息),然后程序默认是调到main入口的,以后具体怎么调试就不用俺继续教了吧,呵呵。不过说的这里,估计会有人提出疑问,难道我们在调试时每次在编译器中修改了代码编译之后都需要重新一步步的加载elf文件吗,呵呵,这个还是放心的,Segger还是考虑周全的(俺比较相信Segger的实力,老外的作风也不太会虎头蛇尾),举一个真正的调试实例来讲,我们在使用J-Link Debugger调试代码时发现了某处bug需要修改fix掉,只需要回到编译器窗口做相应修改然后重新编译工程,待转回到J-Link debugger窗口时其会自动检查elf文件的改动并弹出如下图2的窗口即提示数据文件已改动是否需要重新load,我们只需要点击Yes即可触发Jlink重新把新的image下载到芯片中并跳到main,整个过程你不需要暂停MCU或者退出调试状态,只需要在编译窗口和调试窗口之间切换即可(这点比一些IDE都好用些,毕竟其他IDE在修改代码并重新编译时都需要先退出调试环境然后再重新点击调试才行,而J-link Debugger+编译器的分离模式则的确省掉不少麻烦)。

image

image

        呼呼,终于搞完了,这篇内容写的有点啰嗦了(以后俺老了有话唠的趋势),估计是时隔多日又在高铁上写作的缘故吧,实话说在高铁上码文的确效率超高,京沪线300公里时速貌似把俺的灵感也带动了,老是刹不住车啊,呵呵。今儿就到这了,收拾行囊准备下车,貌似每次都是上车开始码文,到站了也差不多搞定了,虽然辛苦却别有一番滋味,呵呵,有点自娱自乐略表安慰吧,哎,好了,老话,未完待续~

  1. @jicheng0622   

    现在已经叫NXP了。

    现在已经叫搞通了。。哈哈哈哈。。

  2. ***此内容已被管理员屏蔽***

  3. 学习了,谢谢~

  4. @solomon_jiao   

    现在还有飞思卡尔么?

    现在已经叫NXP了。

  5. 实用  继续跟进

  6. 现在还有飞思卡尔么?

  7. 隔一段时间来看看师兄的博客都会有惊喜 可惜我最近用的这个arm9这个debugger并不能识别设备