Thonny Pico: Device is busy or does not respond

  • Hallo zusammen,

    ich wollte mal etwas mit dem Pico machen. Bin in Python + Pico neu.

    Habe LED per PWM angesteuert, läuft.

    Doch jetzt bekomme ich unter Thonny folgende Fehlermeldung:

    Device is busy or does not respond. Your options:

    - wait until it completes current work;

    - use Ctrl+C to interrupt current work;

    - use Stop/Restart to interrupt more and enter REPL.

    Ich habe schon alles probiert:

    Natürlich CTRL + C gedrückt

    Thonny neu installiert

    Firmware neu aufgespielt

    Ich weiß nicht mehr weiter.

    Kann mir jemand helfen?


  • Moin xxxyyyzzz,

    du meinst, das die Led nun dauernd leuchtet und du nicht mehr an den Pico ran kommst?

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Hallo,

    wenn du den Pico anschließt dann wird die 'main.py' ausgeführt. Solange die ausgeführt wird kannst du sie mit Thonny nicht öffnen, daher die Meldung, dass das Gerät beschäftigt ist. Wenn du Thonny offen hast, den Pico angeschlossen hast und die Meldung erhälst, dann drücke mal den roten Stopp-Button in der Thonny Bedienoberfläche. Danach solltest du wieder Zugriff auf die Dateien haben.

    Ich gehe davon aus, dass der richtige Interpreter eingestellt ist.

    Grüße

    Dennis

    🎧 With the music execution and the talk of revolution, it bleeds in me and it goes 🎧

  • Hallo Welt (im Allgemeinen) und natürlich alle Raspifans im Speziellen, mein erster Post hier :)

    Ich glaube, mir ist das gleiche passiert, ich hatte mein erstes Programm unter dem Namen main.py abgespeichert und mich damit selbst ausgesperrt. Man muss dann den Pico mit einer speziellen Firmware flashen, die main.py umbenennt (das Flashen mit der regulären Firmware überschreibt main.py nicht, daher hilft das auch nicht).

    Hier ist das beschrieben und dort ist auch der Downloadlink der benötigten Firmwaredatei MicroPython_RenameMainDotPy.uf2 zu finden. Also einfach den Pico mit der Rename-Firmware flashen, wie vorher mit der regulären, das benennt main.py um und danach wieder die normale Firmware drauf ziehen, dann sollte Thonny wieder funzen. Ich mache seitdem einen grossen Bogen um den Dateinamen main.py :)

  • Hallo,

    bevor ich so ein "rumgeflashe" machen würde, versucht mal das was ich beschrieben habe. Das funktioniert bei Microkontroller wie ESP32 oderESP8266 einwandfrei. Ich sehe gerade nicht, wieso der Pico sich da anders verhalten soll?

    Wenn das Programm dann fertig ist, nennst du es wieder in 'main.py' um und wenn du was ändern willst, geht das wieder von vorne los?

    Grüße

    Dennis

    🎧 With the music execution and the talk of revolution, it bleeds in me and it goes 🎧

  • Hallo,

    ich habe vergessen zu schreiben, dass ich den Stoppbutton natürlich schon gedrückt hatte, aber leider ohne Erfolg.

    Und ja, die LED geht die ganze Zeit an und aus, also läuft auch das Programm.

    Ich habe gerade mal probiert, das Programm auf dem Pico erneut zu speichern, um die Main.py zu löschen. Aber es kommt eine Fehlermeldung:

    "Device is busy -- can´t perform this action now.

    Please wait or cancel current work and try again!"

    Wahrscheinlich muss ich dann wohl JustinCase Vorschlag ausprobieren. Wenn ich aber Denis89s Einwand lese habe ich etwas Angst um meinen Pico .

    Ich wollte ihn nicht schon jetzt in die ewigen Jagdgründe schicken. Man kann im Moment leider keinen neuen kaufen....

    Deswegen vielleicht nochmal die Frage, ob es noch eine andere Idee gibt, oder ob schon einige das Flashen wie JustinCase erfolgreich geschafft haben?

  • Hm also im Netz findet man das von dir beschriebene Verhalten wieder.

    Im Get Started with MicroPython on Raspberry Pi Pico steht davon allerdings nichts. Allerdings ist da die Rede von einer Tastenkobination, siehe Seite 113 ff.

    Ich habe leider keinen Pico und kann das von daher nicht nachstellen. Von anderen Microkontroller kenne ich das Problem nicht.

    Bin auch gespannt ob es noch mehrer mit diesem Problem gibt.

    Wünsch dir viel Erfolg.

    Grüße

    Dennis

    🎧 With the music execution and the talk of revolution, it bleeds in me and it goes 🎧

  • Moin xxxyyyzzz,

    dieser Thread wird wohl lange laufen...

    Was passiert den wenn du Bootsel, auf den Pico, drückst und dann die USB-Verbindung herstellst??

    Meiner hält dann an und meldet sich als Laufwerk.

    73 de Bernd

    //EDIT: Bleib das nächste Mal länger online, sonst ziiieeehhht es sich

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Hi Bernd666,

    dann habe ich auch ein zusätzliches Laufwerk, aber dort ist keine Datei main.py

    Was dann...


    Dennis89

    ich habe mir das durchgelesen und versucht, aber ich bekomme ja die Fehlermeldung:

    "Device is busy -- can´t perform this action now.

    Please wait or cancel current work and try again!"

    wenn ich auf "nach Pico" speichern klicke.

  • Moin xxxyyyzzz,

    dann kannst du wieder auf den Pico zugreifen.

    Ich weiß ja nicht was du erwartest?

    Ein Mikrokontroller soll sein Programm, nachdem er Spannung bekommen hat, starten und laufen lassen.

    Und das macht er. Es sei du hast ein Ende einprogrammiert.

    dann habe ich auch ein zusätzliches Laufwerk, aber dort ist keine Datei main.py

    Doch sie ist schon da, aber nicht für dich lesbar.

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Über den virtuellen Seriellen Port wird dem MicroPython-Interpreter der Payload-Code (Python Quellcode) gesendet, der dann als Programm abläuft und Befehle von der IDE entgegennimmt. Das funktioniert aber nicht, wenn der Interpreter gerade in einer Endlosschleife läuft. Eingaben haben dann keinen Effekt.

    Dafür gibt es den Stop-Button in der Thonny IDE, um das Programm mit einem ETX (CTRL+C, hex-code 0x3) zu killen.

    Letztendlich wird ein KeyboardInterrupt ausgelöst, was dann dazu führt, dass die Endlosschleife abgebrochen wird.

    Dann ist die IDE auch in der Lage, den Payload an den Interpreter zu senden.

    Ziemlich plump, aber das funktioniert.

    Hier kann man z.B. sehen, was rshell macht, wenn das Objekt initialisiert wird. \x03 ist das Zeichen für CTRL-C. Damit soll verhindert werden, dass im Buffer befindlicher Code nicht ausgeführt wird und ein laufendes Programm beendet wird.

  • Hi xxxyyyzzz, bei mir (auch Anfänger) hat das Umbenennen problemlos funktioniert, du hast dann nur vorübergehend die Spezialfirmware auf dem Pico (die main.py umbenennt), danach ziehst du wieder die reguläre Micropython-Firmware auf den Pico - dabei werden nicht mal die Programme gelöscht, die bereits auf dem Pico gespeichert sind.

    Der einzige Grund für das Problem (Pico ist nicht mehr erreichbar) scheint tatsächlich rein in der Existenz der Datei mit dem Namen "main.py" auf dem Pico zu sein. Offensichtlich geht die mit diesem Programmnamen verbundene Autorun-Funktionalität damit einher, dass man den Zugriff auf den Pico verliert. Auf der oben von mir verlinkten Seite wird das imho auch so bestätigt:

    Um ein Programm auf dem Raspberry Pi Pico automatisch starten zu lassen, muss das Programm auf dem Pico mit dem Dateinamen „main.py“ gespeichert werden. Leider ist der Pico dann blockiert, weshalb er sich dann nicht mehr programmieren lässt.

    Das Vorgehen ist wie beim normalen Flashen: Du hälst die Bootsel-Taste auf dem Pico gedrückt, während du dessen USB-Kabel an den PC anschliesst. Der Pico erscheint nun als Laufwerk auf deinem PC und du ziehst nun per drag+drop die Spezialfirmware (MicroPython_RenameMainDotPy.uf2) auf das Laufwerksymbol vom Pico. Danach das gleiche nochmal mit der normalen Micropython-Firmware.

    "main.py" sollte man also entsprechend nur benutzen, wenn alle Programmierarbeiten abgeschlossen sind und der Pico als eigenständiges Gerät arbeitet - just my 0,50€ :)



  • Moin!

    @DeaD_EyE Wenn ich einen Code auf den Pico schicke und run/start drücke, dann rennt der Code im Interpreter?

    Wenn der Pico nur Spannung bekommt, dann passiert nichts?

    Ist das soweit richtig?

    Wenn ich meinen Code in main.py umbenenne und lade, dann ist der Code als permanent anzusehen?

    Kann der dann trotzdem durch CTRL-C unterbrochen werden?

    Ich habe mir noch einen Pico bestellt. Der wird dann mit MicroPython gefüllt. Nur, damit ich mitreden kann...

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Bernd666

    Schade das sie nicht lesbar ist.

    Ich habe schon ein anderes Kabel genommen, gleicher Effekt.


    @DeaD_EyE

    Deine Erklärung habe ich glaube ich so einigermaßen verstanden.

    Aber das mit dem Quellcode gar nicht...

    Der Stopp-Button funktioniert aber nicht.

    Was hat das ETX in deiner Erklärung zu sagen?

    Einen externen CTRL erzeugen?

    Der scheint dann ja nicht zu funktionieren...

  • Bernd666

    Zitat

    Wenn ich einen Code auf den Pico schicke und run/start drücke, dann rennt der Code im Interpreter?

    Wenn der Pico nur Spannung bekommt, dann passiert nichts?

    Ist das soweit richtig?

    Wenn ich meinen Code in main.py umbenenne und lade, dann ist der Code als permanent anzusehen?

    Genauso läuft es, außer das ich jetzt kein anderes Programm drauf kriege, weil die Fehlermeldung kommt....

  • Abend Bernd666

    ja so läuft es ab. Wenn der Pico Strom bekommt, wird als erstes die 'boot.py' geladen. Die ist schon drauf und darin kannst du verschiedene Optionen festlegen. Beim ESp32 Netzwerk zum Beispiel. Danach wird die 'main.py' gestartet.

    Die 'main.py' läuft dann bis sie fertig ist oder halt in Dauerschleife, je nach dem was eben drin steht. Das kann aber unterbrochen werden, zumindest hat es bei mir immer funktioniert und @DeaD_EyE hat hat ja auch den Code gezeigt, der dafür sorgt, dass der Code unterbrochen wird.

    Kann es sein dass der Pico da eine Eigenheit hat?

    Grüße

    Dennis

    🎧 With the music execution and the talk of revolution, it bleeds in me and it goes 🎧

  • Wenn ich einen Code auf den Pico schicke und run/start drücke, dann rennt der Code im Interpreter?

    Ja. Stell dir vor, dass der Interpreter das einzige Programm ist, dass auf dem RPI Pico läuft. Natürlich erst, nachdem die Firmware auf den Controller geflasht worden ist. Der RPi Pico meldet sich das erste Mal als Massenspeicher. Wenn man dann diese udf2 Datei überträgt, wird diese zum Flashen verwendet und damit wird dann nach dem Neustart der Interpreter geladen.

    Wenn der Pico nur Spannung bekommt, dann passiert nichts?

    Es passiert ziemlich viel.

    • Mikrocontroller wird initialisiert
    • Interpreter wird geladen
    • es wird nach boot.py auf dem Flash speicher gesucht
      Das nutze ich z.B. um mich mit WLAN zu verbinden (nicht auf dem Pico)
    • Die main.py wird ausgeführt.
      Falls nicht vorhanden, kommt die REPL.
    • Wenn der Code in main.py abgearbeitet ist, kommt wieder die REPL. Das trifft natürlich nicht zu, wenn das Programm sich gerade in einer Endlosschleife befindet. Da ist auch das eigentliche, was man will (Programm läuft endlos weiter).

    Das ist beim Linux Kernel ähnlich. Der kann nur ein Programm starten und das ist der init-Prozess. Ab da hören die Gemeinsamkeiten aber zum größten Teil schon auf.

    Wenn ich meinen Code in main.py umbenenne und lade, dann ist der Code als permanent anzusehen?

    Ja, dann befindet es sich als Quellcode auf dem internen Flash-Speicher. Du kannst dein Programm auch Module aufteilen. Libs kommen z.B. nach /libs. Den Quellcode kann man auch mit mpy-cross kompilieren. Das witzige ist, dass man dem MicroPython-Interpreter einen Parser und ByteCode Compiler spendiert hat. D.h. der Quelltext wird zur Laufzeit in ByteCode übersetzt und der ByteCode wird dann vom Interpreter ausgeführt.

    Kann der dann trotzdem durch CTRL-C unterbrochen werden?

    In den meisten Fällen ja. Wenn man aber z.B. Code ziemlich schnell ausführt und nirgendwo ein sleep dazwischen hat, kann das dazu führen, dass das Signal niemals ankommt. Das ist natürlich doof, wenn man debuggen will.

    Ein sleep von einer Sekunde ist aber auch für den MicroPython Interpreter eine halbe Ewigkeit.


    Was hat das ETX in deiner Erklärung zu sagen?

    Einen externen CTRL erzeugen?


    Der scheint dann ja nicht zu funktionieren...

    ETX ist die kurze Bezeichnung aus der ASCII Tabelle und ist ein Steuerzeichen. Im Terminal führt ein CTRL+C (auf deutschen Layout STRG+C) zu diesem Steuerzeichen und Prozesse, die gerade im Vordergrund laufen, empfangen dann das Signal SIGINT (Signal Interrupt). Der Python-Interpreter wertet dieses Signal über die serielle Verbindung aus und löst dann den Exception Handler aus. Der dann wiederum, falls er nicht ignoriert oder abgefangen wird, laufende Operationen im Interpreter beendet, um dann die Exception auszugeben. Danach ist die REPL bereit, weitere Eingaben zu akzeptieren. Ein Python-Interpreter auf dem PC würde dann beendet werden, es seiden der Interpreter ist im interaktiven Modus aufgerufen worden.

    Code
    python3 -i programm.py

    Wenn programm.py beendet ist, kommt die REPL.

    Wenn es nicht beendet ist und man STRG+C drückt, wird

    die Exception KeyboardInterrupt ausgelöst und programm.py wird dort abgebrochen, wo es sich gerade befindet (Threads ignorieren wir mal).

    Dann kommt wieder die REPL


    Dieses Prinzip, dass man die REPL (Read-Evaluate-Print-Loop) nutzen kann, wenn kein Programm als Argrument angegeben wird, bzw. das Programm beendet ist, hat man auf MicroPython übertragen.

    Ich werd morgen meinen RP2040 mal anschließen und schauen, ob es irgendwelche Probleme mit Thony gibt.

  • Mit welchem Betriebssystem arbeitest du?

    Möglicherweise ist es ein Berechtigungsproblem. So ein Problem sollte aber eigentlich eine andere Fehlermeldung auslösen (FilePermissionError).


    Raspberry PI OS müsste das für den User pi schon alles gesetzt haben und wenn ich mich nicht irre ist es die Gruppe dialout, die auf die tty zugreifen darf (lesen/schreiben).


    Hier mal die Berechtigung des Geräts auf meinem Desktop:

    Code
    [andre@andre-Fujitsu-i5 ~]$ ls -l /dev/ttyACM0
    crw-rw---- 1 root uucp 166, 0  2. Mär 13:12 /dev/ttyACM0

    Root darf lesen und schreiben.

    Die Gruppe uucp darf auch lesen und schreiben.

    Alle anderen dürfen gar nichts.

    Beim RPi sieht das dann etwas anders aus.

    Dort sollte anstatt uucp dialout stehen. Nagelt mich nicht darauf fest.

    Damit der RP2040, wenn er angeschlossen wird, auch diese Berechtigung zugewiesen bekommt, wird eine UDEV-Regel benötigt.

    Die Regel ist auch bei Arch-Linux standardmäßig eingerichtet. Bei RPi OS auch.

    Code
    [andre@andre-Fujitsu-i5 ~]$ grep -R uucp /lib/udev/rules.d/
    /lib/udev/rules.d/50-udev-default.rules:KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="uucp"

    GROUP="uucp" legt fest, dass Geräte, die in diese Kategorie fallen, der Gruppe uucp zugewiesen werden.

    Mit dem Befehl id kann man nachsehen, in welchen Gruppen man ist:

    Code
    [andre@andre-Fujitsu-i5 ~]$ id
    uid=1000(andre) gid=1000(andre) Gruppen=1000(andre),96(scanner),150(wireshark),960(pico),961(docker),971(brlapi),986(uucp),991(lp),992(kvm),998(wheel)

    In meinem Fall ist die Hauptgruppe andre mit der GID 1000, also der erste Nutzer auf diesem System.

    Zusätzlich sind noch andere Gruppen dem Account zugewiesen, unter anderem uucp.

    Um jetzt z.B. einen User zu einer Gruppe hinzuzufügen, muss man den Befehl usermod verwenden.

    Code
    # Benutzer: andre
    # Gewünschte zusätzliche Gruppe: dialout
    
    sudo usermod -a -G dialout andre
    # sudo, da nur der User root die Benutzeraccounts (in /etc/passwd, /etc/shaddow, /etc/group) verändern darf.
    # -a um Gruppoen anzuhängen
    # -G Gruppenmitgliedschaften getrennt durch ein Komma
    # als letztes Argument den Benutzernamen

    Dann am besten einmal neu starten, falls der User PI nicht in der Gruppe war und nicht die Berechtigungen hatte.

    Aber das ist unwahrscheinlich.


    Eine weitere Möglichkeit zum debuggen, wäre die Verwendung von screen. Das Programm screeen ist ein Terminal-Multiplexer, kann sich aber auch mit seriellen Ports verbinden:

    Code
    sudo apt-get install screen
    
    
    # bei mir erscheint der Pico als ttyACM0
    screen /dev/ttyACM0 115200
    # zu ttyACM0 mit 115200 Baud verbinden
    
    # Dann STRG+C, auch ein paar mal hintereinander
    # Wenn dann immer noch nichts passiert, dann 1 x STRG+B

    Mit STRG+a und danach AltGr+\ kann man screen killen.

    Mit STRG+D (End Of File) löst man einen Soft-Reboot aus und das Programm main.py wird wieder geladen und ausgeführt.

    Falls der Cursor oben links hängt und selbst nach mehrmals drücken von STRG+C nichts passiert, dann einmal STRG+B drücken.

    STRG+B bringt die normale REPL zurück.

    Hier mal eine Übersicht der Control-Codes:


    CTRL-A - enter REPL mode
    CTRL-B - enter normal REPL mode
    CTRL-C - interrupt a running program
    CTRL-D - soft reset
    CTRL-E - paste mode

    In dem Thread wird das auch noch etwas genauer erklärt.

    Wenn gar nichts geht, dann beim Anschließen des RP2040 den Taster BOOTSEL halten. Dann meldet der sich ja als Wechseldatenträger und man kann die uf2 Datei auf den Datenträger kopieren (oha, Microsoft hat das Format uf2 entwickelt).

  • @DeaD_EyE

    Hammer deine Ausführungen, sind interessante Infos dabei, aber das gilt ja nur für Linux.

    Ich arbeite unter Windows 10.

    Ich habe die xxx.uf2-Datei erneut runtergeladen und nach dem booten auf das Laufwerk kopiert. Aber mein Programm läuft immer noch :wallbash:

  • Hi xxxyyyzzz, ich habe das oben bereits 2 mal gepostet, wie du deinen Pico zurücksetzt, machen musst du das allerdings schon selber :)

    Folge dem Link aus meinem ersten Beitrag, dort findest du den Download zur Rename-Datei, ohne die kommst du nicht weiter.

    Zwecks Ursachenforschung: ich hab mich nochmal dran gesetzt und probiert, ob das Problem an der While True Endlosschleife (im Code von xxxyyyzzz) liegt und einen kleines LED-Programm OHNE ENDLOSSCHLEIFE geschrieben und als main.py auf dem Pico gespeichert:

    Python
    from machine import Pin
    from utime import sleep
    
    led_onboard = Pin(25, Pin.OUT)
    
    for count in range(1, 25):
        led_onboard.on()
        sleep(1/count)
        led_onboard.off()
        sleep(1/count)

    Tatsächlich ist der Grund wohl die ursprünglicheEndlosschleife in main.py , die den Pico nicht mehr auf Strg-c bzw. den Stop-Button reagieren liess. Dieses Script dagegen bleibt weiterhin von Thonny aus erreichbar, auch nach zwischenzeitlichem Abtrennen des Picos und Neustart von Thonny.

    Noch einen schönen Sonntag :)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!