Ausgabe über debug printf auf einem Cortex-M3-CPU, Stände auf BKPT Anweisung + Verwirrung über die JTAG-und sw-Anschlüsse

Habe ich einen Keil ULINK2-USB-emulator-box an das JTAG Anschluss auf meinem board, das ist in Ordnung, die mit der Cortex-M3-CPU onboard (TI/Stellaris/LuminaryMicro LM3S Serie). Es scheint, dass sowohl eine JTAG und eine SWJ-DP-Anschluss teilen sich die gleichen pins (und damit der connector auf dem board) auf diesen CPUs. Scheint man nicht zu haben (ITM printf-Funktion, die andere nicht.

Den vorherigen firmware-Menschen haben immer verwendet stdio to UART (serial port), aber ich muss die serielle Schnittstelle freigegeben, so dass debug-Nachrichten, die nicht stören, mit anderen Daten gesendet/empfangen zum/vom seriellen port, so brauche ich für die trace-Meldungen an anderer Stelle zu gehen. Leider habe ich nur eine serielle Schnittstelle auf diesem board. Ich dachte, dass die ITM (Trace) - Funktion in diesem CPU-bedeutete, dass ich könnte senden Sie die debug-printf-Nachrichten direkt auf mein debugger/IDE (Keil µvision). Die TI/Stellaris CPU-Dokumentation nennen diese Funktion " Serial-Wire-JTAG-Debug-Port (SWJ-DP)', für die die Unterstützung, die ich gelesen haben, ist definitiv ein feature implementiert, in der Keil µvision IDE.

Hinzufügen eines printf-Nachricht auf mein code bewirkt, dass mein code zu sperren, wenn ich debugging starten. Die lockup zu sein scheint, hier in der RTL-Bibliotheken, die verbunden sind in meiner Anwendung, in der Funktion _sys_open, an der BKPT-Anleitung:

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

Den oben erscheint ein Teil des Codes aufgerufen __rt_lib_init_stdio_1.

Was ist Los? Ich weiß nicht, was BKPT tut. Ich nehme an, es löst einen software-breakpoint, die sollte dann behandelt werden, indem Sie den debugger? Sollte das nicht der Keil/ARM-ULINK2-software und-hardware bereits konfiguriert werden? Gibt es irgendein trick, debug printf Arbeit mit Keil-JTAG/sw-ports?

Ich bin nicht sicher, was der Unterschied zwischen einem sw und der JTAG-port ist. sw bedeutet was genau, ich glaube, es bezieht sich auf eine von zwei möglichen Modi für die JTAG physischen Anschluss auf einem board, auf dem JTAG ist ein Klassiker, aber eingeschränkter Modus ohne trace-Unterstützung, sw-Modus fügt trace-Unterstützung, ohne die pins der JTAG-connector layout? Aber dies ist bei eingebetteten Systemen, wo kryptisch ist die norm. Ich bin neu auf Cortex-M3-Entwicklung, und eine Menge von diesem Zeug ist mir neu, da die alten ARM7TDMI Tage. Aber der Keil uVision Drucke diese Nachricht aus: "ITM funktioniert nur mit SW-port, nicht mit JTAG". Ist SW eine andere physische Schnittstelle, die Sie für design auf Ihrem Bord? (Ich bin mit einem benutzerdefinierten entworfen, platine, nicht eine Entwicklung, starter-board.)

[Googeln um lässt mich auf die Tatsache, dass _sys_open und einige pragma __use_no_semihosting_swi - und etwas anderes sind eng eingebunden in dieses puzzle, BRKPT Anweisungen in ROM könnte einige ARM-Variante auf den SWI (software-interrupt') ARM-Instruktion.]

InformationsquelleAutor Warren P | 2010-07-11