ARM Cortex M3 und SWD Debug

[Markus M. (mmax)]

Hi,

Um Debugmeldungen (einfachen Text) via SWD auszugeben, bin ich auf das 
Tool stlink-trace [1] gestoßen.

Mein erstes Testprogramm lässt eine LED blinken und gibt mir einen Text 
aus, den ich auch in der Konsole sehe. Also passt ja alles.

Das Problem ist nur dass mein Programm am MC offensichtlich nicht mehr 
läuft/startet wenn ich stlink-trace nicht starte. Also nach einem Reset 
blinkt keine LED, erst wenn ich stlink-trace anwerfe. Scheint so als ob 
der MC (STM32F103) in einem "Debug Modus" steht und auf Meldungen via 
SWD wartet.

Im stlink-trace.c Source werden ab der Zeile 394 auch direkt einige ARM 
Register beschrieben, die laut "ARMv7-M Architecture Reference Manual" 
zum "System Control Space" gehören.

Kann es sein dass das Tool nicht mehr sauber aufräumt und deshalb nichts 
mehr geht?
Hat jemand eine Idee wie ich da wieder raus komme? (wenns überhaupt 
daran liegt)

[1] https://github.com/xor-gate/stlink-trace
[2] 
http://www.pjrc.com/teensy/beta/DDI0403D_arm_architecture_v7m_reference_manual.pdf

Herzlichen Dank,
Max

[Markus M. (mmax)]

Hat niemand eine Idee?

[Felix F. (wiesel8)]

Wenn du im Debug Modus bist, wird gewöhnlich an der Startadresse oder 
bei der Main ein Breakpoint gesetzt, der die Ausführung stoppt und durch 
ein Event die Debug Probe benachrichtigt. Die Debug Probe cleared 
daraufhin die Pipe und lädt den nächsten korrekten PC, damit das 
Programm weiter laufen kann.

Tl;dr:
Keine Debug Probe -> ewig im Breakpoint gefangen.

Kann im Detail bei dir natürlich abweichen, aber das ist das grobe 
Prinzip dahinter.

mfg

[Jim M. (turboj)]

Felix F. schrieb:
> Wenn du im Debug Modus bist, wird gewöhnlich an der Startadresse oder
> bei der Main ein Breakpoint gesetzt,

Ja, aber  üblicherweise nicht im Flash sondern in der Debug Hardware, 
also ist der spätestens nach Power-On weg.

ARM CMSIS enthält eine analoge Funktion:

/** \brief  ITM Send Character

    This function transmits a character via the ITM channel 0.
    It just returns when no debugger is connected that has booked the output.
    It is blocking when a debugger is connected, but the previous character send is not transmitted.

    \param [in]     ch  Character to transmit
    \return             Character to transmit
 */
static __INLINE uint32_t ITM_SendChar (uint32_t ch)
{
  if ((CoreDebug->DEMCR & CoreDebug_DEMCR_TRCENA_Msk)  &&      /* Trace enabled */
      (ITM->TCR & ITM_TCR_ITMENA_Msk)                  &&      /* ITM enabled */
      (ITM->TER & (1UL << 0)        )                    )     /* ITM Port #0 enabled */
  {
    while (ITM->PORT[0].u32 == 0);
    ITM->PORT[0].u8 = (uint8_t) ch;
  }
  return (ch);
}

Im Gegensatz zu oben verlinktem Code wird da vorher geschaut ob ITM 
überhaupt AN ist. Ohne die ersten drei Zeilen (ab Trace enabled) würde 
er sich im

while (ITM->PORT[0].u32 == 0);

aufhängen. Was Dein Code wohl tut.

[Markus M. (mmax)]

Ich will aber meinen MCU natürlich auch ohne Debug Probe (st-link v2) 
benutzen.

Ich kann mich auch via st-util und gdb auf den MC hängen und dort mit 
continue das Programm laufen lassen, das funktioniert auch.

Mit "info break" bekomm ich vom gdb die Meldung - "No breakpoints or 
watchpoints." Gibts noch andere, spezielle Breakpoints die ich via gdb 
einsehen/setzen/löschen kann?

Danke,
Max

[Markus M. (mmax)]

@turboj:
Jop, das ... das Problem war dass ITM_SendChar hängt, wenn kein SWD 
device verbunden ist. Nehme ich die Ausgabe raus, läuft mein Programm 
wieder. Danke für den Tip!

Werd auch gleich deine ITM_SendChar routine versuchen.

Danke,
Max

[Felix F. (wiesel8)]

Jim M. schrieb:
> Ja, aber  üblicherweise nicht im Flash sondern in der Debug Hardware,
> also ist der spätestens nach Power-On weg.

Da aber der Standarduser nur billige Hardware mit minimalen Kapazitäten 
hat, stehen solche Informationen zu 99% im Flash (Hexfile wird vor dem 
flashen manipuliert mit entsprechenden Op codes) genauso wie es auch 
beim OP ist. Sein Code wartet auf die Anwesenheit einer Probe, welche 
nicht vorhanden ist.
Ob es jetzt Breakpoints oder was anderes ist, bleibt dabei 
unerheblich...

mfg

[Jim M. (turboj)]

Felix F. schrieb:
> Ob es jetzt Breakpoints oder was anderes ist, bleibt dabei
> unerheblich...

In dem Falle war es alles andere als unerheblich, denn den Source Code 
kann er korrigieren.