Eigenständiges Flashen von STM32

Ich entwickle ein Vorrichtungstool zum Testen einer benutzerdefinierten Leiterplatte mit ST Bluenrg1 (STM32 M0-Kern + Bluetooth).

Dieses Fixture-Tool verfügt über eine eigene MCU, die mit 5 V arbeitet.

Ich würde gerne zuerst automatisch flashen, um die Pins der Platine zu testen, aber ich suche nach einer besten Lösung, um dies zu tun, ohne 600 EURO in einen "Flasher ARM" auszugeben (der eigenständiges Flashen per Handshake-Protokoll ermöglicht ).

Die Idee ist, die MCU des Testtools zu verwenden, um den Flasher aufzufordern, das Hochladen der Firmware zu starten, und dem Testtool zu antworten, ob es korrekt durchgeführt wurde oder nicht.

Ich überprüfe Optionen mit Himbeere + OpenODC, Himbeere + USB STlinkv2, suche nach Flashern mit Standalone-Modus ... aber ich bin ein bisschen verwirrt mit der besten Option (beste Option mit relativ niedrigen Kosten).

Welche Lösungen verwenden Sie, wenn Sie Ihre MCUs ohne Computer programmieren möchten?

AKTUALISIERT: Ich verwende das SWD-Protokoll, um es mit einem Computer und einem STLINKv2-Programmierer zu programmieren. Ich mache es von Hand, bevor ich die Verbindungen im Testvorrichtungstool teste. Ich möchte diesen Programmierschritt in das Testing Fixture Tool einbauen und es so einfach wie möglich machen, da dies im Lager von anderen Leuten gemacht wird (die Idee ist, das Testing Tool zuerst den Code hochzuladen und wenn alles in Ordnung ist , testen Sie die Verbindungen)

Das Testvorrichtungstool sieht so aus

Jede MCU hat ihre eigene(n) Lösung(en), also wählen Sie aus diesen aus. ein cortex-m0-kern bedeutet, dass swd sicherlich verfügbar ist und es dort verschiedene sehr kostengünstige lösungen gibt. einschließlich manchmal eingebauter Bootloader mit eigenen Protokollen. Ein ftdi Breakout Board mit mpsse kann mit der richtigen Software jedes dieser Protokolle programmieren, die keine unterschiedlichen Spannungspegel beinhalten. und diese sind für 15 US-Dollar im Einzelhandel erhältlich. Es gibt keinen Grund, mehr für die Programmierung/Entwicklung auf einem Cortex-M zu zahlen. die stlinks sind $10. jlink klont $5 und so weiter.
"das Beste" gibt es nicht, es ist alles relativ. Mein Bestes, sein Bestes, ihr Bestes ist vielleicht nicht das Beste für dich. Hängt von Ihrem Setup ab, für dessen Beschreibung hier nicht genügend Platz ist. Sie lesen das Datenblatt / die Dokumentation für das betreffende Teil und wählen die Option, wenn nur eine oder eine der Optionen, wenn mehr als eine. Oder ein anderes Teil verwenden.
Ich entwerfe mit diesem Gedanken st.com/en/development-tools/st-link-v2.html
Pi gpio zu SWD funktioniert mit openocd, ist möglicherweise nicht elektrisch robust, aber Ersatzteile sind billig. Jedes eingebettete Linux-System könnte in der Regel ein USB-SWD hosten, stellen Sie jedoch sicher (mit einem Bereich), dass es tatsächlich NRST steuern kann. Sie möchten nicht, dass Ihr Tool nur auf einer MCU basiert, da der andere Teil davon normalerweise die Aufzeichnung ist.
Ihre Bearbeitung wiederholt nur, was bereits wahr war: Die Komponenten sind die gleichen wie bei Ihrem aktuellen PC-Setup. Sie müssen ein kleineres System finden, das die Arbeit des PCs erledigen kann, und ihm eine einfache Benutzeroberfläche wie einen kleinen Monitor oder eine Taste geben zu pushen, einen Gut/Schlecht-Indikator zu erstellen, einen beliebigen Seriennummernaufkleber / ein einzigartiges signiertes Zertifikat / eine allgemeine Ausgabe zu generieren usw. - dies ist wirklich keine MCU-Aufgabe, obwohl Sie möglicherweise eine MCU als Delegierten benötigen, um eine bestimmte Aufgabe zu erledigen im Auftrag eines größeren Systems.

Antworten (2)

Du suchst einen Bootloader. Glücklicherweise wird die Bluenrg-Serie mit einem von ST entwickelten Bootloader geliefert. Einzelheiten finden Sie unter AN4872 .

Aus dem Dokument

Der BlueNRG-1- und BlueNRG-2-Bootloader wird durch Hardware aktiviert, die beim Zurücksetzen des Geräts einen hohen DIO7 erzwingt.

Achten Sie darauf, dass der Bluenrg eine 3,3-V-MCU ist (wenn ich mich richtig erinnere), müssen Sie möglicherweise zusätzliche Hardwareänderungen vornehmen.

Sie können auch einen Produktionsprogrammierer bekommen, der den Code in sich selbst speichert, anstatt eine Verbindung zu einem PC herstellen zu müssen, aber $$$
Nein. Dies ist ein Ort für SWD, wie die Frage stellt, kein Bootloader
@ChrisStratton Ich bin anderer Meinung, die Frage bezieht sich nicht auf SWD. Soweit ich weiß, ist ein Bootloader perfekt für die Bedürfnisse von OP geeignet.
Ich würde behaupten, dass ein Bootloader auch perfekt geeignet ist. Sie könnten die gesamte Anwendung möglicherweise im Speicher einer "flashenden" MCU speichern, die sie nur mit dem ST-Bootloader bereitstellt, und das Ergebnis mit der Bootloader-Prüfsummenoption überprüfen. Die Bootloader von ST sind sehr leicht und ziemlich einfach zu implementieren.
Bootloader ist hier der richtige Weg, verdammt noch mal, es ist der Lehrbuch-Anwendungsfall, um ein Gerät im Feld zu programmieren. Ja, die Himbeer-Pi-Lösung macht Spaß, aber eine MCU, die mit den Bootloadern einer anderen MCU spricht und ihr die neue Firmware über uart/spi usw. sendet, ist meiner Meinung nach der schnellere, sauberere Weg.

Ich mache auch dasselbe, verwende eine Himbeere (aber PC-Linux funktioniert auch), einen st-link v2-Klon und ein Bash-Skript:

Übergeben Sie die bin-Datei an das Skript, es lädt die zu programmierende Firmware von einem Server herunter, dann:

  1. Verwenden Sie st-info, um festzustellen, ob eine Ziel-MCU angeschlossen ist, falls dies der Fall ist
  2. versuchen zu programmieren (ggf. mit Massenlöschung)
  3. sichern Sie das Gerät
  4. Verwenden Sie st-info, um zu erfahren, wann die Ziel-MCU getrennt ist

Es verwendet einen Summer (mit Oszillator), der mit dem Himbeer-GPIO verbunden ist, um Fehlerwarnungen auszugeben oder die erfolgreiche Programmierung zu melden.

Das Skript kann kostenlos von https://docs.creasol.it/progstm32 heruntergeladen werden

Was nicht funktioniert, ist das Zurücksetzen: Am Ende der Gerätesicherung sendet der st-link v2-Klon einen Hardware-Reset (über NRST), gefolgt von einigen SWD-Befehlen, die das Starten der Firmware nicht zulassen (zum automatischen Testen nach der Programmierung). . Dies sollte ein Problem des st-link v2-Dongles sein.

Wenn "Firmware-Start nach der Programmierung" nicht benötigt wird, funktioniert diese Lösung sehr gut, insbesondere weil sie automatisch die neue Version der zu programmierenden Firmware herunterlädt (sehr nützlich für die Montagefabrik).