Output-Debug über printf auf einer Cortex-M3-CPU, blockiert bei BKPT-Anweisung + Verwirrung über JTAG- und SW-Ports

Ich habe eine Keil ULINK2 USB-Emulatorbox an der JTAG -Anschluss auf meinem Board, der mit der integrierten Cortex-M3-CPU (TI / Stellaris / LuminaryMicro LM3S-Serie) problemlos funktioniert. Es scheint, dass sowohl ein JTAG- als auch ein SWJ-DP-Port die gleichen Pins (und damit den gleichen Anschluss auf Ihrer Platine) auf diesen CPUs haben. Einer scheint nicht ITM-fähig (printf) zu sein, der andere jedoch.

Die vorherigen Firmware-Benutzer haben immer stdio für UART (serielle Schnittstelle) verwendet, aber ich muss die serielle Schnittstelle freigeben, damit Debug-Meldungen andere Daten, die an die serielle Schnittstelle gesendet / von dieser empfangen werden, nicht beeinträchtigen. Daher benötige ich eine Ablaufverfolgung Nachrichten an einen anderen Ort zu gehen. Leider habe ich nur eine serielle Schnittstelle auf diesem Board. Ich dachte, dass die ITM (Trace) -Funktion in dieser CPU bedeutet, dass ich Debug-PrintF-Nachrichten direkt an meinen Debugger / IDE (Keil uVision) senden kann. In der Dokumentation zur TI / Stellaris-CPU wird diese Funktion als "Serial Wire JTAG-Debug-Port (SWJ-DP)" bezeichnet. Ich habe gelesen, dass diese Funktion definitiv in der Keil uVision IDE implementiert ist.

Das Hinzufügen einer printf-Nachricht zu meinem Code führt dazu, dass mein Code abstürzt, wenn ich mit dem Debuggen beginne. Die Überbrückung scheint hier in den RTL-Bibliotheken zu sein, die in meiner Anwendung in der Funktion _sys_open bei der BKPT-Anweisung verlinkt sind:

                 _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}

Das obige scheint Teil des von @ aufgerufenen Codes zu sei__rt_lib_init_stdio_1.

Was ist los? Ich weiß nicht, was BKPT macht. Ich gehe davon aus, dass es einen Software-Haltepunkt auslöst, der dann vom Debugger behandelt werden soll. Sollte die Keil / ARM ULINK2-Software und -Hardware nicht bereits dafür konfiguriert sein? Gibt es einen Trick, um das Debuggen von printf mit Keil JTAG / sw-Ports zu ermöglichen?

Ich bin mir nicht sicher, was der Unterschied zwischen einem SW- und einem JTAG-Port ist. sw bedeutet was genau, ich glaube, es bezieht sich auf einen von zwei möglichen Modi für den physischen JTAG-Anschluss auf einer Platine, wobei JTAG ein klassischer, aber eingeschränkter Modus ohne Trace-Unterstützung ist und der sw-Modus Trace-Unterstützung hinzufügt, ohne dem JTAG Pins hinzuzufügen Anschlussbelegung? Dies sind jedoch eingebettete Systeme, bei denen Kryptografie die Norm ist. Ich bin neu in der Cortex-M3-Entwicklung, und vieles davon ist mir seit den alten ARM7TDMI-Tagen neu. Das Keil uVision druckt jedoch diese Meldung aus: "ITM funktioniert nur mit SW-Port, nicht mit JTAG". Ist SW ein anderer physischer Port, den Sie auf Ihrem Board entwerfen müssen? (Ich verwende eine benutzerdefinierte Anwendungsplatine, keine Entwicklungsstartplatine.)

[Googeln lässt mich auf die Tatsache, dass_sys_open und etwas Pragma__use_no_semihosting_swi und etwas anderes ist eng mit diesem Rätsel verbunden. BRKPT-Anweisungen im ROM können eine ARM-Variante der SWI-ARM-Anweisung ("Software-Interrupt") sein.]

Antworten auf die Frage(8)

Ihre Antwort auf die Frage