Programmierung von STM32: JTAG/SWD vs. Bootloader

Ich mache eine Platine für ein persönliches Projekt mit dem Mikrocontroller STM32L031K6T7. Es sieht so aus, als hätte dieser uC einen Bootloader, mit dem der Flash-Programmspeicher über UART oder SPI neu programmiert werden kann. Es hat auch SWD-Pins.

Bedeutet das also, dass ich zwei völlig separate, aber gleichermaßen gültige Methoden habe, um dieses uC zu programmieren, wenn ich möchte? Ich verstehe, dass ich mit meinem J-Link-Debugger eine Schnittstelle zu SWD herstellen kann, aber wie würde ich eine Schnittstelle zur Bootloader-Methode herstellen?

Ich vermute, dass ich ein Gerät als Schnittstelle zwischen dem USB meines Computers und dem UART- oder SPI-Bus des uC benötigen würde, aber ich bin mir nicht 100% sicher. Und dann frage ich mich, ob ich mir Sorgen machen muss, was passieren würde, wenn ich den SPI-Bus mit anderen Geräten bestückt hätte und dann die Bootloader-Methode ausprobiert habe, um ihn zu programmieren. Müsste das Programmiergerät nicht der SPI-Master sein, um die Kommunikation mit dem uC als Slave zu starten?

Sie könnten beginnen mit: AN2606 STM32-Mikrocontroller-Systemspeicher-Startmodus . Siehe Seite 15 für "Verwandte Dokumente".
Ah. Das macht viel mehr Sinn. Sieht so aus, als ob der Bootloader in diesem Modus als SPI-Slave fungiert. Ich denke, ich kann andere Geräte am SPI-Bus haben, da ich den Select-Pin des Bootloaders nur dann aktiviere, wenn ich ihn brauche. Und es scheint definitiv so, als würde ich ein Gerät als Schnittstelle zwischen USB und SPI benötigen.

Antworten (3)

Ja. Viele STM32-Geräte verfügen über einen integrierten Bootloader. Siehe die Dokumentation zum Auslösen. Dies geschieht oft durch Hochbinden eines Pins während des Einschaltens.

Sie müssen auch das Datenblatt zur Verwendung von SPI und UART im Bootloader-Modus lesen.

Also ja, Sie können das Gerät entweder mit dem Bootloader oder mit SWD programmieren.

SWD wird auch zum Debuggen des Geräts verwendet (z. B. Einzelschritt durch Code, Speicher untersuchen), während der Bootloader nur zum Laden eines Programms dient.

Fantastisch. Danke für die Bestätigung dessen, was ich dachte, ich habe es verstanden! Es sieht also so aus, als hätten einige Mikrocontroller Bootloader-Speicher, der sauber ist, wenn Sie ihn bekommen, also schreiben sie ihren eigenen Bootloader, um den Flash zu programmieren?
Das ist richtig. Zum Beispiel haben alle Microchip PICs (soweit ich weiß) keinen eingebauten Bootloader; es muss beim ersten Mal mit einem programmiert werden. Denken Sie daran, dass sie Dienste haben, die Ihnen vorprogrammierte ICs mit Ihrer benutzerdefinierten .hex-Datei liefern. Dies ist sehr nützlich für die Massenproduktion.

SWD ist eine 4-Draht-JTAG-Schnittstelle ohne Hardware-Reset. JTAG hat mehr Drähte, aber auch eine Reset-Leitung, um den Prozessor über eine Hardware-Leitung zurückzusetzen (der Prozessor könnte in einen Modus geraten, in dem Sie den Prozessor möglicherweise nicht mit einem Software-Debug-Befehl zurücksetzen können, an diesem Punkt müssten Sie ihn aus- und wieder einschalten ) Die JTAG-Schnittstelle kann auch in einem SWD-Modus betrieben werden, in dem Sie nur 2 Drähte für die Kommunikation verwenden.

Es gibt mehrere Möglichkeiten, einen STM32 zu programmieren (externer Flash, USB, externes ROM), aber sie erfordern, dass Code auf dem Prozessor ausgeführt wird, sodass Sie zunächst einen Bootloader und Programmierung benötigen. Sie benötigen sowieso das SWD oder JTAG zum Debuggen.

Was meinen Sie, wenn Sie sagen, dass es mehrere Möglichkeiten gibt, den STM32 zu programmieren, für die Code auf dem Prozessor ausgeführt werden muss? Ich hatte den Eindruck, dass JTAG/SWD zum Programmieren des uC verwendet werden könnte, unabhängig davon, welches Programm gerade im Flash geladen ist? Und dann wird für die Bootloader-Option nicht einmal das Programm im Flash ausgeführt – stattdessen wird der Bootloader-Code im Systemspeicher ausgeführt. Ich bin mir also nicht sicher, was Sie meinen, wenn Sie sagen, ich brauche "Bootloader und Programmierung". Danke!
Ein Bootloader erfordert die Programmierung des Onboard-Flash auf dem STM32, es kann ein einmaliges Programm sein und Sie können Ihr Programm dann von einer beliebigen Quelle laden, aber um den Bootloader zu laden, benötigen Sie ein JTAG\SWD
Ohh, okay, ich glaube, ich verstehe jetzt, was du meinst. In diesem Fall kommt der STM32-Chip, den ich mir anschaue, mit einem vorprogrammierten Bootloader (glaube ich). Ich schätze, das lässt mich dann das Flash-Mem des Programms mit beiden Methoden programmieren.

Ich weiß, es ist alt, aber ich sehe Dinge, die einen Neuling verwirren können.

Die „Bibel“ für den Umgang mit den verschiedenen STM32-Embedded-Bootloadern ist ST-Micros AN-2606, „STM32-Mikrocontroller-Systemspeicher-Bootmodus“, es wird aktualisiert, wenn eine neue Serie veröffentlicht wird. Zum Zeitpunkt dieses Schreibens wurde es zuletzt im Oktober 2019 (d. h. im letzten Monat) aktualisiert.

Als nächstes haben ALLE STM32-Chips mindestens einen eingebetteten seriellen Bootloader. Es ist ein Werks-ROM und kann nicht gelöscht werden. Das bedeutet, dass eine externe Schnittstelle (JTAG/SWD) zum Programmieren eines STM32at in den meisten Fällen nicht erforderlich ist. Achten Sie auf mögliche Spannungsabweichungen.

AN-2605 beschreibt die verschiedenen Methoden zum Aufrufen eines System-Bootloaders. Die Anzahl der verfügbaren Schnittstellen reicht von einer einzelnen USART-Schnittstelle in einigen der frühen STM32F1-Serien bis hin zu den H7, die Monster sind, mit insgesamt 12 Schnittstellen, 3 USART, 3 I2C, 4 SPI, 1 USB (DFU) und 1 FDCAN .

Sie können das alles natürlich ignorieren und einen JTAG/SWD-Adapter verwenden, um die MCU zu programmieren. Diese haben den zusätzlichen Vorteil, dass Sie Ihre Arbeit auch debuggen können.

Man müsste EXTREM Platz haben, um zu rechtfertigen, dass die SWD-Pins nicht an mindestens winzigen Testpunkten oder Durchkontaktierungen herausgeführt werden. Andererseits ist es auch ein Fehler, keinen UART für Debug-Meldungen herauszubringen, außer bei den kleinsten Designs. Ja, Nachrichten über SWD sind theoretisch möglich; in der Praxis ist ein UART normalerweise besser.
Nun, der Hauptstoß der vorherigen Antworten und des OP betraf Bootloader mit einigen Dingen, die ich hier und da für etwas schuppig hielt. Ich habe mit verschiedenen Bootloadern gespielt, aber in 99% der Fälle, in denen ich SWD für meine Programmierung und das Debugging verwende und SWO und/oder seriell zum Abrufen von Statusinformationen verwende, drucke ich lieber von einem Thread mit niedriger Priorität an SWO. Einer der Gründe, warum ich die Verwendung der Cortex-M0/M0+ für die Entwicklung vermeide, ist ihr Mangel an SWO-Ausgang.
Keine Notwendigkeit, die M0 zu vermeiden - es gibt einen UART, der einem der SWD-Pins zugeordnet ist, vorausgesetzt, Sie haben das Zurücksetzen herausgebracht und haben einen nicht gefälschten SWD-Adapter, der die Reset-Leitung tatsächlich ansteuern kann. Warten Sie dann einfach ein oder zwei Sekunden nach dem Zurücksetzen Ordnen Sie den SWD-Pin UART TX zu und starten Sie das Dumping von Daten.
Da ich für alles eine Black Magic Probe verwende, ist es einfach, sowohl seriell als auch SWO an einen der VCPs anzuschließen. Mit ein paar einfachen Patches versteht das BMP die SWO-Ausgabe ganz gut. Mit GDB in einem Fenster, Putty in einem anderen und meinem Lieblings-SWO-Reader in einem dritten, kann ich so ziemlich jede gewünschte Information bekommen.
Ich spreche von SWO, ein UART hat nicht die gleichen Fähigkeiten. SWO ist tief mit der integrierten Debug-Hardware verbunden, nicht annähernd gleich. Als Beispiel haben Sie die Wahl zwischen asynchroner oder Manchester-Ausgabe mit SWO.
Oh, der Horror, keinen bevorzugten Debug-Ausgangskanal zu haben und sich stattdessen mit einem perfekt geeigneten begnügen zu müssen. Und dann sagen Sie den Geschäftsleuten, dass Sie eine teurere MCU kaufen müssen?
Nun, wenn die Firmware die UARTs verwendet, bevorzuge ich es wirklich, keine Debug-Freigabe zu haben. Außerdem verwenden Schreibvorgänge über SWO nicht dieselben Pfade, was bedeutet, dass ich dort Daten ausgeben kann und sie sowieso nicht mit den UART-Modulen in Konflikt geraten. Außerdem ist die Hardware-Manchester-Codierung robuster in Bezug auf Timing-Probleme.
Was den Preis angeht, bekomme ich für 1,25 $ zusätzlich einen STM32F3 im Vergleich zu STM32L0 und ich bekomme Fließkomma und DSP als Bonus, nicht nur die volle Debug-Zelle ... Zum Glück für mich, ich beschäftige mich nicht genug mit Standardhardware Gegenstand.
Programmierung von STM32: JTAG/SWD vs. Bootloader
AntwortenHierDatenschutz-Bestimmungen1y, 0v