J-Link detekt moeglich?

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.

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

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.

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

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.

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

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

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.

Super, es funktioniert damit:

1

  while (CoreDebug->DHCSR & CoreDebug_DHCSR_C_DEBUGEN_Msk)

2

    {

3

      led_green_on();

4

      delay(250);

5

      led_green_off();

6

      delay(250);

7

    }

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

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.

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.

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".

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.

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