在 Cortex-M3 CPU 上通过 printf 进行输出调试，在 BKPT 指令处停止 + 关于 JTAG 和 sw 端口的混淆 [英] Output debug via printf on a Cortex-M3 CPU, stalls at BKPT instruction + confusion about JTAG and sw ports

问题描述

我的板上的 JTAG 连接器上有一个 Keil ULINK2 USB 仿真器盒，它与板载 Cortex-M3 CPU(TI/Stellaris/LuminaryMicro LM3S 系列)配合良好.似乎 JTAG 和 SWJ-DP 端口在这些 CPU 上共享相同的引脚(以及板上的连接器).一个似乎没有 ITM (printf) 功能，另一个则有.

I have a Keil ULINK2 USB emulator box attached to the JTAG connector on my board, which is working fine with the Cortex-M3 CPU onboard (TI/Stellaris/LuminaryMicro LM3S series). It seems that both a JTAG and a SWJ-DP port share the same pins (and thus connector on your board) on these CPUs. One appears not to have ITM (printf) capability, the other does.

以前的固件人一直使用 stdio 转 UART(串口)，但我需要释放串口，以便调试消息不会干扰发送/接收到/从串口的其他数据，因此我需要用于跟踪消息到其他地方.可悲的是，我在这块板上只有一个串行端口.我认为这个 CPU 中的 ITM(跟踪)功能意味着我可以将调试 printf 消息直接发送到我的调试器/IDE(Keil uVision).TI/Stellaris CPU 文档将此功能称为串行线 JTAG 调试端口 (SWJ-DP)"，据我所知，对它的支持绝对是 Keil uVision IDE 中实现的一个功能.

The previous firmware people have always used stdio to UART (serial port), but I need the serial port freed up so that debug messages do not interfere with other data being sent/received to/from the serial port, thus I need for trace messages to go elsewhere. Sadly I only have one serial port on this board. I thought that the ITM (Trace) feature in this CPU meant that I could send debug printf messages directly to my debugger/IDE (Keil uVision). The TI/Stellaris CPU documentation call this feature 'Serial Wire JTAG Debug Port (SWJ-DP)', support for which, I have read, is definitely a feature implemented in the Keil uVision IDE.

在我的代码中添加 printf 消息会导致我的代码在我开始调试时锁定.锁定似乎在链接到我的应用程序的 RTL 库中，在函数 _sys_open 中的 BKPT 指令中:

Adding a printf message to my code causes my code to lock up when I start debugging. The lockup seems to be here in the RTL libraries which are linked into my application, in the function _sys_open, at the BKPT instruction:

                 _sys_open:
  0x00009D7A B50E      PUSH     {r1-r3,lr}
  0x00009D7C E9CD0100  STRD     r0,r1,[sp,#0]
  0x00009D80 F7FFFC0F  BL.W     strlen (0x000095A2)
  0x00009D84 9002      STR      r0,[sp,#0x08]
  0x00009D86 4669      MOV      r1,sp
  0x00009D88 2001      MOVS     r0,#0x01
>>0x00009D8A BEAB      BKPT     0xAB
  0x00009D8C BD0E      POP      {r1-r3,pc}

上面似乎是 __rt_lib_init_stdio_1 调用的代码的一部分.

The above appears to be part of code called by __rt_lib_init_stdio_1.

发生了什么事?我不知道 BKPT 是做什么的.我认为它会引发一个软件断点，然后应该由调试器处理?Keil/ARM ULINK2 软件和硬件不应该已经为此配置了吗?是否有一些技巧可以使 debug printf 与 Keil JTAG/sw 端口一起工作?

What is going on? I don't know what BKPT does. I assume it raises a software breakpoint which should then be handled by the debugger? Shouldn't the Keil/ARM ULINK2 software and hardware already be configured for this? Is there some trick to making debug printf work with Keil JTAG/sw ports?

我不确定 sw 和 JTAG 端口之间的区别是什么.sw 到底是什么意思，我相信它指的是板上 JTAG 物理连接器的两种可能模式之一，其中 JTAG 是一种经典但更受限制的模式，没有跟踪支持，而 sw 模式在不向 JTAG 添加任何引脚的情况下增加了跟踪支持连接器布局?但这是嵌入式系统，神秘是常态.我是 Cortex-M3 开发的新手，自从旧的 ARM7TDMI 时代以来，很多这些东西对我来说都是新的.但是 Keil uVision 会打印出以下消息:ITM 仅适用于 SW 端口，不适用于 JTAG".SW 是您必须在板上设计的不同物理端口吗?(我使用的是定制设计的应用板，而不是开发入门板.)

I am unsure what the difference between an sw and JTAG port is. sw means what exactly, I believe it refers to one of two possible modes for the JTAG physical connector on a board, where JTAG is a classic but more limited mode without trace support, and sw mode adds trace support without adding any pins to the JTAG connector layout? But this is embedded systems, where being cryptic is the norm. I am new to Cortex-M3 development, and a lot of this stuff is new to me since the old ARM7TDMI days. But the Keil uVision prints this message out: "ITM works only with SW port, not with JTAG". Is SW a different physical port that you have to design on your board? (I am using a custom designed application board, not a development starter board.)

[谷歌搜索让我了解到 _sys_open 和一些 pragma __use_no_semihosting_swi 和其他一些东西与这个难题密切相关，ROM 中的 BRKPT 指令可能是一些 ARMSWI('软件中断')ARM指令的变体.]

[Googling around lets me in on the fact that _sys_open and some pragma __use_no_semihosting_swi and something else are intimately involved in this puzzle, BRKPT instructions in ROM might be some ARM variant on the SWI ('software-interrupt') ARM instruction.]

推荐答案

这是我的一个失误，我没有理解 stdio 没有实现，而是你必须提供自己的实现，通常在一个名为retarget"的文件中完成.C".文件名是纯粹的约定，但在 Keil 的 uVision/RTLIB 文档中有很好的记录(事实证明)

This one was a failure on my part to understand that stdio is not implemented, but rather you must provide your own implementation, usually done inside a file called "retarget.c". The filename is pure convention, but is well documented (as it turns out) inside Keil's uVision/RTLIB documentation

这篇关于在 Cortex-M3 CPU 上通过 printf 进行输出调试，在 BKPT 指令处停止 + 关于 JTAG 和 sw 端口的混淆的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！