Commandlineflashing laesst Rechner abstuerzen.

Hallo zusammen,

ich habe nach langer Zeit mal wieder versucht einen Doppelmasterbrick (2* Masterbrick HW 2.0) zu flashen. Dabei hat sich 2 mal der Rechner weggehaengt. Warum? :gruebel:

Zuerst Erase+Reset gedrueckt. Serielles Device /dev/ttyACM0 dann vorhanden.

root: brick-flash-cmd -p /dev/ttyACM0 -f brick_master_firmware_latest.bin"
Writing firmware: 100 % (Bis 100% wird langsam (passend) hochgezaeht. ok)
Verifying written firmware:  96 % (96% erscheint sofort und nach ein paar Sekunden ist der Rechner nicht mehr richtig ansprechbar).
Ein Abbruch mit CTRL-C ist nicht moeglich

Das es ein Doppelstack (2* FW 2.1.2) war messe ich erstmal keine Bewandtnis zu.

Der Masterbrick startet durch. (und startet immer wieder durch, wohl dadurch, dass der obere Masterbrick noch die alte FW hat) Als weitermachen.

Anschliessend USB auf 2. Masterbrick umgesteckt. Rechner rebootet. 2. Masterbrick geflashed. Gleiches Phaenomen/Problem. 

Nach dem naechsten reboot arbeitet der Doppelstack einwandfrei mit FW 2.3.0. Das flashen an sich hat also funktioniert.

Ist das Commandolinetool mit der aktuellen "Debian/Python Version" nicht mehr kompatibel?

# dpkg -l |grep brick
ii  brick-flash-cmd                    1.0.0                              all          Flash firmware onto Bricks from a terminal
ii  brickd                             2.2.0                              i386         Tinkerforge Brick Daemon
# dpkg -l |grep -i python
ii  python                             2.7.3-4+deb7u1                     all          interactive high-level object-oriented language (default version)
ii  python-argparse                    1.2.1-2                            all          optparse-inspired command-line parsing library
ii  python-minimal                     2.7.3-4+deb7u1                     all          minimal subset of the Python language (default version)
ii  python-serial                      2.5-2.1                            all          pyserial - module encapsulating access for the serial port
ii  python2.6                          2.6.8-1.1                          i386         Interactive high-level object-oriented language (version 2.6)
ii  python2.6-minimal                  2.6.8-1.1                          i386         Minimal subset of the Python language (version 2.6)
ii  python2.7                          2.7.3-6+deb7u2                     i386         Interactive high-level object-oriented language (version 2.7)
ii  python2.7-minimal                  2.7.3-6+deb7u2                     i386         Minimal subset of the Python language (version 2.7)
# uname -r
3.2.0-4-486
# cat /etc/debian_version
7.7

Noch ein paar Hinweise/Fragen:

Die "Platte" ist ein USB-Stick. Davon wird natuerlich gebootet.

Der Tinkerforgestack haengt natuerlich ebenfalls am USB.

Kann sich bitte jemand mal die /var/messages Ausgabe ansehen und ggf. mir einen Tipp geben woran es lag.

Warum wird beim "Verify" sofort auf 96% gesprungen und nicht langsam hochgezaehlt?

Danke

Der Loetkolben

8.1.2015_cmd_flash_error.txt

Okay, in /var/messages sehe ich dass Master Brick 6JKUui zwischen 22:08 und 22:15 19mal an USB gefunden wurde. Bei dreien davon kommt wenige Sekunden danach ein Calltrace in dem der cdc_acm Treiber vorkommt, der erzeugt das /dev/ttyACMx Device für den Brick. Das riecht als ob das mit deinem Problem zusammenhängt, aber was mir das wirklich sagen will weiss ich nicht, dafür bin ich zuwenig Kernel Entwickler.

Ich weiss nicht so recht was ich die da raten, soll bin etwas überfragt, sorry.

Das es ein Doppelstack (2* FW 2.1.2) war messe ich erstmal keine Bewandtnis zu.

Der Masterbrick startet durch. (und startet immer wieder durch, wohl dadurch, dass der obere Masterbrick noch die alte FW hat) Als weitermachen.

Versteh ich das Richtig?

2 Master, beide als ein Stack (zusammen)

Und der Untere hat sich immer wieder neu gestartet?

Tritt das Problem auch auf wen du nur einen einzelnen Master flashst?

Das es ein Doppelstack (2* FW 2.1.2) war messe ich erstmal keine Bewandtnis zu.

Der Masterbrick startet durch. (und startet immer wieder durch, wohl dadurch, dass der obere Masterbrick noch die alte FW hat) Als weitermachen.

 

Versteh ich das Richtig?

2 Master, beide als ein Stack (zusammen)

Und der Untere hat sich immer wieder neu gestartet?

 

Tritt das Problem auch auf wen du nur einen einzelnen Master flashst?

Hallo Novae,

alleine konnte ich den Brick nicht flashen, da sie zusammengebaut und verbaut sind. Ich gehe davon aus, dass es normal war, dass der untere immer wieder durchgestartet ist, WEIL der obere Brick noch die (sehr) alte Firmware hatte und die beiden Versionen nicht miteinander funktionieren.

Nachdem ich auch den oberen Brick geflasht hatte, haben beide nur EINMAL durchgestartet und gut war es.

Da sich der Rechner aber sowohl beim flashen des unteren Bricks (der dann immer wieder rebootete) aufgehaengt, als auch beim flashen des oberen Bricks, gehe ich davon aus, dass es nicht damit zusammenhaengt, dass 2 Bricks zusammen sind. 100% ausschliessen kann ich es aber nicht.

Ich werde mal auf einer aehnlichen HW einen einzelnen Brick flashen.

@photron:

Danke dass du mal einen Blick auf das Logfile geworfen hast.

Kannst du mir denn sagen warum die "Verifyanzeige" so schnell auf 96% springt und dann verharrt? Ist da bei 96% irgendein Sprung im Quellcode? (Denke wohl nicht).

Hast du noch einen Tipp in welcher Richtung ich weitersuchen kann?

RAM? (Es sind nur 64 MB + 32 MB Swap vorhanden, und im Idle nur 44 MB benutzt)

USB Resetsequenz im cmd-line Tool?

Der Loetkolben

Kannst du mir denn sagen warum die "Verifyanzeige" so schnell auf 96% springt und dann verharrt? Ist da bei 96% irgendein Sprung im Quellcode? (Denke wohl nicht).

Keine Idee was da passiert. Wenn du den Fehler einfach reproduzieren kannst kannst du mal in /usr/bin/brick-flash-cmd diese Zeile

print('\r{0}: {1:>3} %'.format(self.message, int(100.0 * self.value / self.maximum)))

durch diese

print('{0}: {1} / {2}'.format(self.message, self.value, self.maximum))

ersetzen. Dann wird nicht mehr eine Zeile mit dem Prozentwert überschrieben sondern die Flash Page Nummer mit History ausgegeben, die dann in +1 Schritten hochzählt. Wenn die Flash Page Nummer springt ist irgendwas richtig faul.

Hast du noch einen Tipp in welcher Richtung ich weitersuchen kann?

RAM? (Es sind nur 64 MB + 32 MB Swap vorhanden, und im Idle nur 44 MB benutzt)

USB Resetsequenz im cmd-line Tool?

RAM sollte eigentlich kein Problem sein.

Der Bootloader des Bricks ist über eine serielle Schnittstelle über USB (CDC ACM) erreichbar. Darüber spricht brick-flash-cmd mit dem Brick das SAM-BA Protokoll. Der Reset am Ende wird durch Setzen eine speziellen Registers des Mikrocontrollers ausgelöst. USB an sich ist da nie direkt involviert.

Heute mal ein Update bei den beiden Masterbricks auf Masterfirmware 2.3.1 versucht. Die Aenderungen an "/usr/bin/brick-flash-cmd" (s.o.) habe ich nicht gemacht gehabt.

Er ist wieder bei Verify 96% haengengeblieben nach dem flashen des ersten Masterbricks haengengeblieben. :-(

Der Rechner ist erstmal nicht abgestuerzt. Ich konnte mich weiter darauf umsehen (ls, etc.)

Interesanterweise waren dann aber 2! ACM Devices vorhanden. (Vor dem Flaschen war definitiv nur ein Device da!). Kann das damit was zu tun haben, dass eben 2 Masterbricks im Stack sind oder das der Reset des ersten Masters nach dem flaschen nicht sauber im System war? Woher kommt ACM1?

# ls -la /dev|grep -i ACM
crw-rw---T  1 root dialout 166,   0 Mär 15 15:58 ttyACM0
crw-rw---T  1 root dialout 166,   1 Mär 15 15:58 ttyACM1

ABER:

Als ich dann ein "ps -ef" gemacht habe ist die Ausgabe haengengebleiben, so als ob das ps Kommando auf die Rueckmeldung eines Prozesses wartete. Ein Einloggen oder andere Kommandos waren nicht mehr moeglich. :-) Also nur ein Hardreset.

So, in Teil 2 wird der andere Masterbrick geflasht mit der Aenderung in " /usr/bin/brick-flash-cmd"

Der Loetkolben

So, tut wieder nicht. Wie erwartet ist das flashen an sich fertig und der Verify auch. Der Verify ist ca. 6 mal schneller als der Flash durchgelaufen, aber ohne irgendwelche Auffaelligkeiten.

# brick-flash-cmd -p /dev/ttyACM0 -f brick_master_firmware_2_3_1.bin
Writing firmware: 0 / 544
Writing firmware: 1 / 544
...
Writing firmware: 542 / 544
Writing firmware: 543 / 544
Writing firmware: 544 / 544

Verifying written firmware: 0 / 544
Verifying written firmware: 1 / 544
Verifying written firmware: 2 / 544
Verifying written firmware: 3 / 544
...
Verifying written firmware: 542 / 544
Verifying written firmware: 543 / 544
Verifying written firmware: 544 / 544
_   <- Cursor, aber kein Shellprompt.

Hier die Infos aus einem 2. Fenster in dem ich die ACM Devices geprueft habe.

## VOR dem flaschen!
# ls -la /dev | grep ACM
crw-rw---T  1 root dialout 166,   0 Mär 15 16:19 ttyACM0

## Waehrend des flashens
# ls -la /dev | grep ACM
crw-rw---T  1 root dialout 166,   0 Mär 15 16:21 ttyACM0

## NACH dem flashen.
# ls -la /dev | grep ACM
crw-rw---T  1 root dialout 166,   0 Mär 15 16:22 ttyACM0
crw-rw---T  1 root dialout 166,   1 Mär 15 16:22 ttyACM1

Also:

Warum gibt es nach dem Flash 2 ACM Devices?

Warum kommt das Flash Programm nicht in den Promt zurueck? (CTRL-C nicht moeglich).

Warum kann ich "ls" Kommandos absetzen, aber kein "ps" mehr?

Wie kann man alternativ eine Prozessliste ausgeben um den haengengebliebenen Flash-Prozess zu killen?

Hat das doch was mit der "USB-Platte" zu tun, dass die iergendwie "abgehaengt" wird?

Ein "reboot" wird zwar noch angenommen, aber es passiert nichts. Keine Reboot.

Ein "reboot -f" ging dann "doch" noch.  :'(

Ich brauche Hilfe! 

Der Loetkolben

Dass das Verify so viel schneller ist kann normal sein. Die Geschwindigkeit des Flashens variiert hier bei uns auch zwischen verschiedenen Rechner.

Es sieht so aus als ob der Write und Verify Schritt durch sind bevor das Problem auftritt. Nach Write und Verify wird noch das Boot Flag Register des Mikrocontrollers von "Boot Loader" auf "Flash" gesetzt. Als Letztes wir der Brick über das Reset Register neugestartet.

Ich vermute jetzt mal ins Blaue hinein, dass einer dieser beiden letzten Schritte das Problem verursacht, oder vielleicht auch das Verify. Warum und weshalb das passiert und ob das dann fixbar ist steht auf einem anderen Blatt.

Um das Testen zu können habe ich dir eine erweitere Version vom brick-flash-cmd angehängt. Diese Version hat vier weitere Optionen. In diesem Beispiel werden all vier Schritte ausgelassen:

./brick-flash-cmd-loetkolben -p /dev/ttyACM0 -f brick_master_firmware_2_3_1.bin --no-write --no-verify --no-flag --no-restart

Damit kannst du jetzt gezielt Schritte auslassen, um so vielleicht herauszufinden wo das Problem steckt.

brick-flash-cmd-loetkolben

Hallo photron,

danke fuer die Anpassung. Ich vermute, dass es weder am Write noch am Verify liegt, sondern mit der Resetsequenz in Bezug auf USB zu tun hat. (Glaskugeloutput)

Ich werde es testen und mich wieder melden. 

Danke.

Der Loetkolben

Kurzer Feedbackbericht:

# ./brick-flash-cmd-loetkolben -p /dev/ttyACM0 -f brick_master_firmware_2_3_1.bin --no-restart
step: write...
Writing firmware: 0 / 544
Writing firmware: 1 / 544
Writing firmware: 2 / 544
Writing firmware: 3 / 544
...
Writing firmware: 542 / 544
Writing firmware: 543 / 544
Writing firmware: 544 / 544
step: verify...

Verifying written firmware: 0 / 544
Verifying written firmware: 1 / 544
Verifying written firmware: 2 / 544
...
Verifying written firmware: 542 / 544
Verifying written firmware: 543 / 544
Verifying written firmware: 544 / 544
step: flag...1
step: flag...2
step: flag...3
step: flag...done
skipped step: restart

Firmware successfully written, Brick should restart automatically   (<- Falscher Text. Ist aber klar warum.)
#

Tut! 

Brick musste per USB-ab-an-stoepseln neu gestartet werden. Also wie erwartet. Alles gut! Brick laeuft, Rechner haengt nicht. Tip-top.

Ich bin zufrieden, aber warum?    Soll heissen, ich wuerde gerne noch die Ursache finden.

Lohnt sich der Aufwand das herauszufinden oder koennt ihr einfach die Programmparameter einschliesslich der der Pakethochzaehlanzeige mit in das Programm einbauen und in ein neues *.deb Paket verpacken. (Wenn denn mal Zeit ist.)

Edit: Was ich nicht probiert habe ist ein Programmdurchlauf ohne alle Parameter mit der neuen Programmversion, da ich wieder "Angst" hatte, dass sich der Rechner weghaengt.

Mein Tip aus dem Kaffeesatz ist immer noch, dass durch den Reset an Ende des Programms auch die "USB-Boot-Platte" kurzfristig mit abgehaengt wird.

Danke!

Der Loetkolben

Das Script resettet den Brick auf die gleiche Weise wie die Reset() Funktion aller Bricks in den API Bindings. Meine Frage hier wäre: Wenn du den Brick über die API Bindings resettest tritt das Problem dann auch auf? Meine Erwartung ist, dass ein Reset per Software funktioniert und dass das Problem nicht durch den Reset an sich ausgelöst wird.

Ich habe dir eine weiter Version angehängt. Diese hat jetzt ein --restart-delay Argument:

./brick-flash-cmd-loetkolben -p /dev/ttyACM0 -f brick_master_firmware_2_3_1.bin --restart-delay 500

Damit wird vor dem Restart 500 Millisekunden gewartet. Meine Erwartung ist, dass das einen Unterschied macht, da ich vermute, dass das Problem durch die engen zeitliche Abfolge der einzelnen Schritte entsteht. Dabei setzte ich voraus, dass nicht schon ein Neustart per API Reset() Funktion das Problem erzeugt

Wenn es dir zu heikel ist das zu testen, dann können wir auch hier stoppen und uns mit der Erkenntnis begnügen, dass das Problem ohne Reset am Ende nicht auftritt. Dann würde ich einfach dem Script in der nächsten Version die --no-restart Option mitgeben und der Brick muss dann nach dem Flashen manuelle resettet werden.

brick-flash-cmd-loetkolben2

Meine Frage hier wäre: Wenn du den Brick über die API Bindings resettest tritt das Problem dann auch auf?

ICH? API?    Ich frage den Stack per TCP aus der Ferne ab und nutze die API der Bindings nicht.    Daher kann ich das so nicht nachstellen.

Meine Erwartung ist, dass ein Reset per Software funktioniert und dass das Problem nicht durch den Reset an sich ausgelöst wird.

Ok, verstanden. Das wuerde auch  dazu passen, dass der Verify in der Ursprungsversion nur bis 96% anzeigt, obwohl er wohl durchgelaufen ist. Der Rechner ist wirklich klein und ein wenig langsam.

Ich habe dir eine weiter Version angehängt. Diese hat jetzt ein --restart-delay Argument:

 

./brick-flash-cmd-loetkolben -p /dev/ttyACM0 -f brick_master_firmware_2_3_1.bin --restart-delay 500

 

Damit wird vor dem Restart 500 Millisekunden gewartet. Meine Erwartung ist, dass das einen Unterschied macht, da ich vermute, dass das Problem durch die engen zeitliche Abfolge der einzelnen Schritte entsteht. Dabei setzte ich voraus, dass nicht schon ein Neustart per API Reset() Funktion das Problem erzeugt

Auch verstanden.

Wenn es dir zu heikel ist das zu testen, dann können wir auch hier stoppen und uns mit der Erkenntnis begnügen, dass das Problem ohne Reset am Ende nicht auftritt. Dann würde ich einfach dem Script in der nächsten Version die --no-restart Option mitgeben und der Brick muss dann nach dem Flashen manuelle resettet werden.

Heikel ist das falsche Wort, aber bei jedem Hardreset eine PC, und das noch in der Ferne, laueft einem Gaensehaut ueber den Ruecken, zumal es sich in diesem Fall noch um ein Flashmedium handelt. Das System braucht mit zweimaligem Reboot und Filecheck gerne 10 Minuten bis die Pings wieder beantwortet werden. Das ist eine seeeeeeehr lange Zeit wenn man darauf wartet. Das System ist aber nicht lebensnotwendig und so werden wir es mal antesten.

Eine Antwort kommt also.

Danke.

Der Loetkolben

Meine Frage hier wäre: Wenn du den Brick über die API Bindings resettest tritt das Problem dann auch auf?

 

ICH? API?    Ich frage den Stack per TCP aus der Ferne ab und nutze die API der Bindings nicht.    Daher kann ich das so nicht nachstellen.

Doch, doch, auch du nutzt die API, wenn auch nicht über Bindings

Ich spreche von Function ID 243 im TCP/IP Protokoll. Die API Bindings machen ja nichts weiter als Pakete zu erzeugen und diese zu senden und empfangen. Genau das tust du ja auch, aber von Hand. Sprich auch du kannst den Brick per API mittels Function ID 243 resetten.

Die Art und Weise wie im Mikrocontroller des Bricks der Reset ausgelöst wird ist immer gleich, egal ob du im Brick Viewer den Reset Button klickst oder per API Bindings die Reset() Funktion aufrufst oder manuell ein TCP/IP Paket mit Function ID 243 schickst oder brick-flash-cmd nach dem Flashen den Brick per Registerzugriff neustartet.

Daher die Hypothese: Wenn ein Reset per Software funktioniert, dann kann der Reset an sich nicht das Problem sein.

Wenn es dir zu heikel ist das zu testen, dann können wir auch hier stoppen und uns mit der Erkenntnis begnügen, dass das Problem ohne Reset am Ende nicht auftritt. Dann würde ich einfach dem Script in der nächsten Version die --no-restart Option mitgeben und der Brick muss dann nach dem Flashen manuelle resettet werden.

 

Heikel ist das falsche Wort, aber bei jedem Hardreset eine PC, und das noch in der Ferne, laueft einem Gaensehaut ueber den Ruecken, zumal es sich in diesem Fall noch um ein Flashmedium handelt. Das System braucht mit zweimaligem Reboot und Filecheck gerne 10 Minuten bis die Pings wieder beantwortet werden. Das ist eine seeeeeeehr lange Zeit wenn man darauf wartet. Das System ist aber nicht lebensnotwendig und so werden wir es mal antesten.

Bei solchen Wartezeiten macht das keinen Spaß, das ist verständlich.

Hallo photron,

hier die Antworten. Es sieht schlecht aus! 

(Obiger Teil sieht wie bekannt aus.)
Verifying written firmware: 542 / 544
Verifying written firmware: 543 / 544
Verifying written firmware: 544 / 544
step: flag...1

Setting Boot-from-Flash bit: 0 / 0
step: flag...2
step: flag...3
step: flag...done
option: delay restart by 500 msec
step: restart

Triggering Brick restart: 0 / 0
_ (<- Das ist der Cursor. Nix passiert mehr. Wo sollten denn die 500ms Pause gemacht werden?)

Der Rechner hat sich wieder weggehaengt.    Der Code ist bis zu der Stelle ohne 500ms Pause durchgelaufen. Sagen wir es so: Mir ist keine Pause aufgefallen. Ich werde dann mit 5000ms (5 Sekunden nochmals wiederholen)

if args.restart:
            if args.restart_delay > 0:
                print "option: delay restart by {0} msec".format(args.restart_delay)
                import time
                time.sleep(args.restart_delay / 1000.0)

            print "step: restart"
            # Boot
            try:
                self.reset()
            except SAMBAException as e:
                raise SAMBARebootError(str(e))
        else:
            print "skipped step: restart"

Das Brick hat nach dem flashen durchgestartet und ist wieder aktiv. Im offenene 2. Terminalfenster konnte ich noch "ps -ef" absetzen, was aber mittendrin stehenbleibt s.o..  Ein CTRL-C hilft weder hier noch beim "brick-flash-cmd-loetkolben2" um es zu beenden.

Hilft nur noch Power-Off - Power-On. ... und dann kommt das bange Warten.  :'(

Natuerlich nutze ich die API, aber eben die HW-API und nicht die SW-API der Bindings. Ich weiss ja nicht was fuer Wunderdinge in den Softwarebindings passieren. 

Das mit dem API Reboot (per TCP Paket) kann ich im Moment nicht testen. Aber vielleicht kommt man auf diesem Weg der Loesung noch ein Stueck naeher.

Ich melde mich nach der 5 Sekunden Pause.

Der Loetkolben

Hallo photron.

500ms sind wohl fuer mich zu schnell. 

Also die 5000ms Pause habe ich prima sehen koennen und wurden an der richtigen Stelle gemacht. Danach ist der Masterbrick gestartet worden und der Rechner hat noch den "Triggering Brick restart: 0 / 0" geschrieben. Dann kam wieder der Absturz.

Verifying written firmware: 542 / 544
Verifying written firmware: 543 / 544
Verifying written firmware: 544 / 544
step: flag...1

Setting Boot-from-Flash bit: 0 / 0
step: flag...2
step: flag...3
step: flag...done
option: delay restart by 5000 msec (<- Hier wurden artig 5 Sekunden Pause gemacht)
step: restart

Triggering Brick restart: 0 / 0
_ (<- Cursor. Keine weiteren Ausgaben)

Ich werde gleich mal (wenn der Rechner sich hoffentlich wieder meldet) einen Reset mit dem Brickviewer machen. Mal sehen was passiert.

Ein Reset mit einem Remote-Brickviewer ist kein Problem. Der Stack macht einen Reset, meldet sich kurz danach wieder beim Brickviewer und der Rechner stuerzt nicht ab.

Darf ich noch den Hinweis geben, dass sowohl die USB-Flash-Stick "Platte" als auch der Tinkerforgestack am internen USB1.1 Anschluss haengen. Aber ob 1.1. oder 2.0 sollte doch diesbezueglich egal sein!?

Der Loetkolben

Da gehen mir langsam die Ideen aus

Es funktioniert, wenn brick-flash-cmd am Ende den automatischen Reset weglässt und der Brick dann extern (z.B. durch USB ab- und anstecken) neugestartet wird.

Es funktioniert nicht, wenn brick-flash-cmd am Ende den automatischen Reset macht, auch dann nicht wenn davor 5 Sekunden gewartet wird. Der Brick startet zwar neu (das Reset Kommando ist angekommen), aber der PC hat es nicht überlebt.

Aber ein Reset aus Brick Viewer heraus funktioniert. Ich denke daher, dass das Problem eher PC seitig als Brick seitig ist. Ich denke es hat auch nichts damit zu tun, wie der Brick an USB angeschlossen ist, oder was sonst noch so an USB hängt.

Meine Hoffnung war, dass das ein Timing Problem wäre und ein kurzes Sleep helfen würde. Dem ist wohl nicht so.

Ein Unterschied zwischen Brick Viewer Reset und brick-flash-cmd Reset ist folgender: Wenn Brick Viewer den Reset auslöst ist der Brick nicht im Bootloader und die Kommunikation läuft über eine vendorspecific USB Device. Wenn brick-flash-cmd den Reset auslöst ist der Brick im Bootloader und die Kommunikation läuft über ein CDC ACM USB Device.

In beiden Fällen führt ein Reset dazu, dass das jeweilige USB Device verschwindet während es gerade für Kommunikation geöffnet ist. Ich könnte da jetzt nach Strohhalmen greifen, einen Kernel Bug herbeireden und behaupten, dass im CDC ACM Fall sich der Kernel beim Verschwinden des USB Devices auf die Nase legt und den Rest des Systems mitnimmt.

Von welcher Kernel Version reden wir hier überhaupt? Hast du mal in die Kernel Logs geschaut, ob da irgendwas hierzu drin steht?

Was du auch noch ausprobieren kannst ist den Brick per brick-flash-cmd und --no-restart zu flashen und den Reset danach ohne brick-flash-cmd zu triggern, damit Python, pySerial usw. aus der Gleichung raus sind.

Solange der Brick im Bootloader ist kannst du einen Reset auslösen indem du an das /dev/ttyACM0 Device folgenden String sendest:

N#W400E1408,A5000A09#W400E1400,A500000D#

Wie gesagt mir gehen die Ideen aus. Daher ist das hier auch nur ein weiterer Strohhalm

Als Variation kannst du auch testen den Brick direkt zu resetten, ohne ihn zuvor zu flashen.