Ich habe kürzlich versucht, einen benutzerdefinierten App-Flasher (basierend auf dem Python-Modul stm32loader) für STM32L073xx-Mikrocontroller zu entwickeln, bin aber an einem Punkt hängen geblieben.
Diese Bibliothek versucht, die Flash-Größe vom Mikro zu erhalten, da wir für dieselbe Chip-UID (0x447 - STM32L07x/L08x/L010) unterschiedliche Flash-Größen haben können. Die Bibliothek sendet einen Befehl zum Lesen des Speichers (cmd 0x11 0xEE) und hier beginnt mein Problem:
Wenn ich versuche, die Flash-Größe von dieser Adresse zu lesen, erhalte ich die Antwort 0x1F (NACK) und kann den Vorgang nicht fortsetzen.
Natürlich könnte ich das Flash-Größenbyte irgendwo in den RAM kopieren, bevor ich zum System-Bootloader springe, oder eine gewisse Flash-Größe annehmen, aber dann ist die Anwendung nicht für alle Chips robust.
Wie sollte damit richtig umgegangen werden? Gibt es eine andere Adresse, wo die Flash-Größe gespeichert ist?
Jetzt kann ich den gesamten Flash-Inhalt lesen, aber es gibt eine neue Herausforderung. Ich habe versucht, eine Massenlöschung durchzuführen, um den Flash für das Schreiben neuer Inhalte und Überraschungen vorzubereiten ... der Bootloader gibt NACK für jede Art von Massenlöschung zurück!
Meine Kommunikation sieht so aus:
Nun habe ich folgendes versucht:
Keiner von ihnen funktioniert ... irgendwelche Vorschläge?
Es ist unklar, warum das Lesen der Adresse 0x1FF8007C nicht funktioniert, ich bekomme den gleichen Fehler.
Das Experimentieren mit einem Nucleo-L073RZ zeigt jedoch, dass es möglich ist, 128 Bytes zu lesen, beginnend bei Adresse 0x1FF80000, die den gesuchten Flash-Größenwert als vorletztes 16-Bit-Wort enthält.
Da ich dachte, dass es sich um ein Offset-Problem handeln könnte, habe ich versucht, Lesevorgänge bei 0x1FF80000 + [0x70, 0x60, 0x40] auszuführen, von denen keines funktionierte. Umgekehrt funktioniert das Lesen bei 0x800007c, daher sind Offsets im Allgemeinen erlaubt. Und da die Lesegröße nach dem Punkt gesendet wird, an dem die Adresse NAK ist, ist es kein Problem, wenn ein 32- oder 16-Bit-Lesevorgang erforderlich ist.
Wie auch immer, das Auslesen eines 128-Byte-Blocks sollte Ihr Problem lösen.
Eine andere Idee wäre, an einer Adresse nahe der Spitze der größten Flash-Größe zu beginnen und nach unten zu lesen, bis Sie keinen Fehler mehr bekommen. Oder Sie könnten einen kleinen Stub in den RAM laden und ihn ausführen. Aber es scheint, als wäre das Auslesen von 128 Bytes Ihre einfachste Lösung.
Abgesehen davon habe ich unter Verwendung von https://github.com/florisla/stm32loader (was anscheinend auf pypi zu finden ist, Sie haben nicht gesagt, was Sie verwendet haben) festgestellt, dass ich den Chip jedes Mal zurücksetzen musste, wenn ich den aufgerufen habe Programm, also verlässt es den Bootloader anscheinend nicht im richtigen Zustand. Trotzdem ist das eine Verbesserung gegenüber einem anderen Tool, das ich vor ein paar Monaten ausprobiert hatte und das sich überhaupt weigerte, mit dem L07x-Bootloader zu kommunizieren, obwohl es mit dem L05x-Bootloader in Ordnung war ...
Wenn man wirklich einen Nachmittag damit verbringen möchte, in ein Kaninchenloch hinabzusteigen, wäre es wahrscheinlich möglich, vor dem Senden des Adress-CRC-Bytes einen Haltepunkt zu setzen und die Bootloader-Operation auf die Logik zu verfolgen, die das ACK oder NAK generiert, aber da es sich im ROM befindet alles Sie würde wahrscheinlich erfahren, was genau ist oder (offenbar fälschlicherweise) nicht erlaubt ist.
Chris Stratton
Voldi
Lundin
Voldi
Chris Stratton