通过 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

问题描述

我有一个 Keil ULINK2 USB 仿真器盒连接到我板上的 JTAG 连接器，它与板载 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 软件和硬件不应该已经为此配置了吗?是否有一些技巧可以使调试 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 和一些编译指示 __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屋！