Probleme beim Programmieren des LPC1343-Mikrocontrollers in Ubuntu

Wenn ich eine Binärdatei, die auf einem lpc1343 funktioniert, auf das gemountete USB-Gerät kopiere, das den lpc1343-Flash darstellt, wird die Binärdatei geändert und funktioniert nicht. Wenn Sie dasselbe mit dem über USB unter Windows oder Mac OS bereitgestellten Flash tun, tritt nicht das gleiche Problem auf. Was könnte das Problem sein und wie kann es behoben werden?

Bearbeiten: Das Problem scheint die vfat-Implementierung in Linux zu sein, die der zu übertragenden Datei 0 voranzustellen scheint.

Bist du dir 100% sicher, dass es die gleiche Binärdatei ist? Wie genau kopiert man die Datei unter Ubuntu? Haben Sie verschiedene Kopiermethoden ausprobiert?
Ja, ich bin sicher. Ich habe das Problem gefunden. Es scheint die Art und Weise zu sein, wie Linux mit vfat umgeht. Es scheint 0 voranzustellen, bevor die Datei gesendet wird, die von vielen USB-Geräten ignoriert wird, aber immer noch nicht mit dem Standard kompatibel ist.
Wenn Sie sagen, dass vor dem Senden der Datei 0 vorangestellt werden, was meinen Sie damit? Woher weißt du das? Kopieren Sie eine funktionierende Binärdatei (die Sie auf einem Windows/Mac zum Laufen bringen können) oder kopieren Sie eine Binärdatei, die auf Ihrem Ubuntu-Computer erstellt wurde? Welche Schritte durchlaufen Sie, um die Binärdatei zu kopieren? Welche Einstellungen hast du in der fstab für das USB-Gerät? Machst du es als root oder als nicht privilegierter Benutzer? Klicken und ziehen Sie oder kopieren Sie an der Befehlszeile? Wenn es ein Problem mit Ubuntu, ausführbaren Dateien und vfat-Geräten gibt, warum ist es nicht allgemein bekannter? Glaubst du, es gibt einen veröffentlichten Standard für vfat?
Wir haben die gleiche Binärdatei von einem Windows-, einem Mac-OS- und mehreren Linux-Rechnern gesendet. Wir haben von der Befehlszeile kopiert, im Dateibrowser kopiert und eingefügt sowie per Drag & Drop. Der Grund, warum es nicht allgemeiner bekannt ist, ist, dass die meisten USB-Geräte diese 0s tolerieren (ich denke, sie werden einfach weggelassen), das auf dem lpc1343 implementierte vfat jedoch nicht (was dem Standard entspricht). Wenn Sie mcopy von mtools in Unix auf dem Blockgerät verwenden, wird die Datei korrekt übertragen, anstatt das vfat zu mounten.
Meinen Sie damit, dass die Binärdatei am Anfang mit einer unbestimmten Anzahl von 0 s aufgefüllt wird? Sie scheinen eine funktionierende Lösung für dieses Problem zu haben, warum nicht unten eine detailliertere Antwort posten, damit andere dieses Wissen leichter teilen können. Wenn ich dem Link in Ihrem Profil folge, sehe ich, dass Sie über 10.000 Wiederholungspunkte von verschiedenen SE-Sites haben, sodass Sie die Übung inzwischen kennen.
Ich glaube, es ist mit 1024 0s aufgefüllt. Zumindest wurde mir das gesagt. Ich werde hier eine Antwort mit der Lösung schreiben, wenn ich Zeit habe.
habe Zeit? :PI wäre sehr an der Lösung interessiert. Danke.
Ich glaube nicht, dass Linux irgendetwas tut, was außerhalb der USB-Massenspeicherspezifikation liegt; es ist wirklich die Schuld des simplen Bootloaders des Chips. Zumindest war ich zu diesem Schluss gekommen, als ich mich vor ein oder zwei Jahren mit demselben Problem beschäftigte.

Antworten (2)

Sie können dies lösen, indem Sie mtools(Userspace Fat Utilities) verwenden:

mdel -i /dev/sdf ::/firmware.bin
mcopy -i /dev/sdf new_firmware.bin ::/
So habe ich es immer gemacht. Es ist eine gute Lösung für einen schlecht geschriebenen Bootloader.
Was bewirken die Optionen -i und ::?
"Der Laufwerksbuchstabe : (Doppelpunkt) hat eine besondere Bedeutung. Er wird verwendet, um auf Bilddateien zuzugreifen, die direkt auf der Befehlszeile mit den Optionen -i angegeben werden." Sie können darüber im Handbuch hier nachlesen .

Eine andere Lösung ist die Verwendung des Simpleflash-Python-Skripts aus dem r0ket[1]-Git-Repository. Es schreibt direkt auf das Gerät, anstatt "cp" zu verwenden. Ich musste die Größe in Zeile 20 von 32 auf 64 ändern, um mit einem LPC1347-Testboard zu arbeiten ...

Das Skript finden Sie hier .

[1] LPC1343-Platine