J-Link detekt moeglich?

[Vanye R. (vanye_rijan)]

Moin Leute,

Hat jemand eine brilliante Idee wie man in einem STM32L451 nach dem 
Reset erkennen kann ob ein Segger angeschlossen ist?

Hintergrund: Ich hab eine auf Stromsparen optimierte Schaltung wo der 
Controller nur sehr kurz was macht und dann sofort den Controller in den 
deepest Sleep schickt. Da hat der Segger keine Chance das Teil unter 
Kontrolle zu bekommen und ich muss den erst jedesmal mit JLinkSTM32Exe 
ein brainwashing verpassen.
Es waere eigentlich cooler wenn der Controller das merken wuerde und 
dann nicht entschlummert.
Klar, ich koennte irgendwo einen Pin abfragen, aber vielleicht gibt es 
noch eine elegantere Loesung?

Vanye

[Hans W. (hanswieland)]

Füge am Anfang des Programms ein 5s Delay ein, bevor er in den Sleep 
geht. Dann jann sich der Debugger vorher verbinden und auch verhindern, 
dass der CPU Takt beim Schlafen deaktiviert wird.

[Vanye R. (vanye_rijan)]

> Füge am Anfang des Programms ein 5s Delay ein, bevor er in den Sleep
> geht.

Das ist natuerlich meine aktuelle Loesung, aber nicht akzeptabel weil 
ich nicht 5s lang kostbare Energie verbraten will. Der Strom kommt ja 
nicht aus der Steckdose. .-)

Vanye

[Hans W. (hanswieland)]

Vanye R. schrieb:
> weil ich nicht 5s lang kostbare Energie verbraten will.

Muss dein Dingsbums denn immer mit Reset neu starten? Aus dem Sleep 
Modus kann man doch ohne Reset Aufwachen, si dass das Programm nicht neu 
starten muss. Die 5s würden nur den ersten Start nach dem Einschalten 
(und Reset) betreffen.

[Dieter S. (ds1)]

Dafür gibt es z.B. die ARM Core Debug Register. Und wenn die 
Suchmaschine nicht kaputt ist findet man u.a. das hier ("Lifehack: 
detecting debugger connection for Cortex-M0 & Ozone"):

https://m0agx.eu/detecting-debugger-connection-on-cortex-m0.html

[Hans W. (hanswieland)]

Dieter S. schrieb:
> Dafür gibt es z.B. die ARM Core Debug Register.

Geht das DEBUGEN Bit denn schon auf High, bevor der Debugger die 
logische Verbindung aufgebaut hat? Sonst nützt das nichts.

[Frank K. (fchk)]

Ghet es um Debuggen oder nur neu Flashen? Flashen kannst Du auch mit dem 
internen ROM-Bootloader, der mit BOOT0 aktiviert wird. Und zum Debuggen 
wirst Du sicher einen extra Build mit -O0 und -g und -DDEBUG haben.

fchk

[Vanye R. (vanye_rijan)]

> Dafür gibt es z.B. die ARM Core Debug Register.

Ah..super Hinweis. Das werde ich nachher mal ausprobieren...


> Ghet es um Debuggen oder nur neu Flashen?

Natuerlich letztlich um beides.

> Flashen kannst Du auch mit dem
> internen ROM-Bootloader, der mit BOOT0 aktiviert wird.

Du meinst mit Boot0 den internen Bootloader aktivieren und dann mit dem 
J-Link die Kontrolle uebernehmen? Hm..klingt technisch machbar. Bedeutet 
aber letztlich auch einen Jumper an einen Pin. Das koennte ich ja dann 
auch mit einem beliebigen anderen Pin machen. Letzeres haette noch den 
Vorteil das ich dann huebsch blinken koennte damit ich weiss das die 
Hardware nun bereit zur uebername durch den J-Link ist.

> Detecting the debugger is as simple as doing CoreDebug->DHCSR &
> CoreDebug_DHCSR_C_DEBUGEN_Msk.

Das hier klingt einfach viel eleganter. :)

BTW: Mir faellt da gerade noch eine weitere Anwendung ein:

if (CoreDebug->DHCSR & CoreDebug_DHCSR_C_DEBUGEN_Msk) 
delete_secret_keys();

Ist halt die Frage wieviel Zeit man hat...

Vanye

[Dieter S. (ds1)]

Und wenn man den angeschlossenen, aber noch nicht aktiven Debugger 
erkennen will geht das vermutlich auch sehr einfach: Bei vielen STM32 
kann man die SWD Pins als GPIO konfigurieren. Dann als Eingang mit 
eingeschaltetem Pullup und ein zweites mal mit eingeschaltetem Pulldown 
die Pegel bestimmen. Ein Debugger wird vermutlich mindestens einen der 
SWD Pins auf einem definierten Pegel halten, auch wenn der Debugger noch 
nicht aktiv ist. Wenn man damit fertig ist die ursprüngliche 
Konfiguration wiederherstellen.

[Vanye R. (vanye_rijan)]

Super, es funktioniert damit:

  while (CoreDebug->DHCSR & CoreDebug_DHCSR_C_DEBUGEN_Msk)
    {
      led_green_on();
      delay(250);
      led_green_off();
      delay(250);
    }

Wobei es nicht so ist als ob man die gruene LED gross blinken sieht. 
Aber der Debugger connectet zuverlaessig, flasht den Source und danach 
geht er vom Bus und der Controller laeuft mit der neuen Software und ich 
brauche keine bloede Wartezeit in meinem Programm. Das laeuft bei mir so 
50ms bis es in den DeepSleep  geht.

Vanye

[Hans W. (hanswieland)]

Dieter S. schrieb:
> Ein Debugger wird vermutlich mindestens einen der SWD Pins auf einem
> definierten Pegel halten

Nein. Im Ruhezustand und nach Ende/Abbruch der Verbindung wird der 
Debugger hochohmig.

[Niklas G. (erlkoenig)]

Wenn du beim Debugger das Connect Under Reset nutzt ("RSetType 3"), 
funktioniert das Verbinden immer, weil die Software eben gar nicht läuft 
und den Standby betreten kann sondern der Controller im Reset ist. Dann 
kannst du auch problemlos flashen. Nur zum Debuggen ist es ein Problem, 
weil wenn der Controller in den Sleepmode geht die Debugger Verbindung 
wegfliegt.

Die Standby Modi (STOP2) kann man dann diverser Errata sowieso nicht 
vernünftig debuggen leider...

Vanye R. schrieb:
> und danach geht er vom Bus und der Controller laeuft mit der neuen
> Software

Aber nicht realitätsnah; wenn der Debugger einmal dran war bleibt das 
C_DEBUGEN an auch nach einem Reset. Breakpoints bleiben ggf. Ebenfalls 
bestehen! Nach einem Flashen muss man einen vollen Power Cycle + 
Kaltstart machen um die Software korrekt inkl Low Power Modes zu testen.

[Dieter S. (ds1)]

Hans W. schrieb:
>
> Nein. Im Ruhezustand und nach Ende/Abbruch der Verbindung wird der
> Debugger hochohmig.

Falsch. Wenn mein J-Link einmal auf SWD konfiguriert wurde ist der SWCLK 
Pin "Low", auch wenn kein Target an den SWD Pins angeschlossen ist. Die 
beiden SWD Pins sind nur direkt nach dem Anstecken an den USB Port als 
"Input" konfiguriert und haben keinen Pegel, sobald die Host Software 
den J-Link anspricht ändert sich das. Siehe auch die SWD Doku, SWCLK ist 
"Output" am Debugger, SWDIO "Input/Output".

[Dieter S. (ds1)]

Niklas G. schrieb:
>
> Aber nicht realitätsnah; wenn der Debugger einmal dran war bleibt das
> C_DEBUGEN an auch nach einem Reset. Breakpoints bleiben ggf. Ebenfalls
> bestehen! Nach einem Flashen muss man einen vollen Power Cycle +
> Kaltstart machen um die Software korrekt inkl Low Power Modes zu testen.

Wenn man so Dinge wie "Low Power" realistisch testen will sollte doch 
auch kein Debugger angesteckt sein (ändert eventuell die Stromaufnahme). 
Damit hat man den Power Cycle eigentlich bereits, zumindest wenn man den 
Debugger nicht unter Spannung abstecken will.

[Vanye R. (vanye_rijan)]

> Wenn man so Dinge wie "Low Power" realistisch testen will sollte doch
> auch kein Debugger angesteckt sein (ändert eventuell die Stromaufnahme).

Es ist noch schlimmer. Wenn der Debugger einmal genutzt wurde dann ist 
die Macrozelle fuers Debugen aktiv. Das macht jede Messung zur 
Energieaufnahme kaputt. Da ist also ein kompletter Powercycle schon 
wichtig.

> Damit hat man den Power Cycle eigentlich bereits, zumindest wenn man den
> Debugger nicht unter Spannung abstecken will.

Pfft. :-) Das mach ich oefter mal. Hat noch nie geschadet und in aller 
Regel laeuft die Firmware bei an/abstecken auch ohne Reset einfach so 
weiter. Koennte mir aber vorstellen das dies etwas vom Controller 
abhaengt.

Vanye