Guten Tag Ich habe eine Frage, die mir etwas peinlich ist, da ich wirklich gerade ein wenig auf dem Schlauch stehe. Ich arbeite mit einem Nucleo Board STM32G071 und versuche mit einem kleinen Übungsprogramm schlicht ein Relais hin und her zu schalten. Bzw toggle ich zwei Pins der CPU. Das Nucleo Board speise ich über die USB-Schnittstelle mithilfe des integrierten ST-Link. So weit so gut, nun aber folgendes: Wenn ich die Spannungsversorgung trenne und nachher wieder herstelle, ist das Programm weg, heisst also ich muss das Programm wieder über die Entwicklungsumgebung laufen lassen. So lange die Versorgung nicht unterbrochen wird funktioniert alles, sobald ich aber trenne und neu connecte, müsste das Programm ja automatisch wieder anlaufen, ohne dass ich es über die Entwicklungsumgebung starte, oder sehe ich das falsch?
Kann es ein, daß du nicht ins Flash programmierst, sondern aus dem RAM startest?
Das könnte sein. Gibt es eine Möglichkeit das über den Compiler einzustellen oder muss das softwaremässig geschehen?
Ob Flash oder RAM wird normalerweise per Hardware Pins ausgewählt. Es kann aber auch sein, dass das Programm nicht an der Flash Adresse liegt, an der der Controller beim Start sucht. (Wenn man per Debugger startet springt der Controller an die richtige Adresse) Das sind dann alles Einstellungen des Links bzw. allgemein der Toolchain.
Dretox schrieb: > Das könnte sein. Gibt es eine Möglichkeit das über den Compiler > einzustellen oder muss das softwaremässig geschehen? Welcher Speicherbereich für dein Programm verwendet wird hängt davon ab, was im verwendeten Linker-File (*.ld) steht. Dort gibt es die verfügbaren Speicherbereiche (Flash, RAM, ...) sowie die Anweisung welche Sektionen wohin gelinkt werden sollen, also bspw möchtest du .text nach FLASH haben, genauso wie die ganzen Konstanten und Library-Sachen. Vielleicht gibt es in Deinem Projekt ja Linker-Files für FLASH und für RAM? Ansonsten halte ich das Schauen nach den BOOT0/BOOT1 Pins für lohnenswert: Mike R. schrieb: > Ob Flash oder RAM wird normalerweise per Hardware Pins ausgewählt. Die Entwicklungsumgebung kann nämlich beim Debuggen die hardwareseitige Einstellung umgehen und den Program Counter auf dein Programm zeigen lassen.
Phantomix X. schrieb: > also bspw möchtest du > .text nach FLASH haben, genauso wie die ganzen Konstanten und > Library-Sachen. Das scheint auch so zu klappen. Phantomix X. schrieb: > Ansonsten halte ich das Schauen nach den BOOT0/BOOT1 Pins für > lohnenswert: Möglicherweise ist hier der Wurm drin. Wenn ich das Programm per Breakpoint stoppe, sehe ich im Flash Register, dass BOOT0 und BOOT1 beide auf 1 sind. Laut Reference Manual ist die selected boot area in diesem Fall nicht das Flash sondern das System Memory (also das RAM?) Um vom Flash zu booten, müsste der Pin BOOT0 low sein. Das kann ich allerdings nicht einfach so machen, da dieser die alternate function SWCLK hat...
Dretox schrieb: > Um vom Flash zu booten, müsste der Pin BOOT0 low sein. Das kann ich > allerdings nicht einfach so machen, da dieser die alternate function > SWCLK hat... Mach einen Pull-Down Widerstand dran. Nachdem der µC gestartet hat, darf er jeden beliebigen Pegel haben.
Das habe ich versucht, leider ohne Erfolg. Wenn ich im Programm stoppe wird BOOT0 weiterhin als 1 angezeigt. Allerdings habe ich im Reference Manual nochmal nachgesehen. Wenn BOOT0 und BOOT_SEL beide 1 sind, was der Fall ist, hat BOOT1 keinen Einfluss und die CPU bootet vom Main Flash Memory. Also auch hier dürfte alles richtig funktionieren..
schau mal mit deinem Debugger an Adresse 0x08000000. steht da was?
Ich habe mit dem CubeProgrammer einen Flash Erase durchgeführt und das Flash dann überprüft. An der Adresse 0x08000000 Steht dann FF, wenn ich dann mit dem CubeProgrammer mein Hex File aufspiele, steht da zwar was, aber das Programm läuft halt trotzdem nicht ab. Das Flash wird also definitiv beschrieben und ich kann mir auch nicht vorstellen, dass die CPU nicht vom Flash bootet. Ich vermute nach wie vor ein Problem mit der Einstellung des Compilers. Ich nutze CrossStudio, evtl. kennt sich da jemand aus?
werden evtl. Ausgaben über Semihosting gemacht? Müsste in den Linker oder Debugeinstellungen zu sehen sein ob es aktiviert ist. Dann hängt das Programm wenn Ausgaben gemacht werden sollen und kein Debugger vorhanden ist.
Mittlerweile konnte ich heute das Problem nun lösen. Einerseits habe ich firmeninterne Projekteinstellungen übernommen. Üblicherweise wird an der Flashadresse 0x08000000 ein Bootloader aufgespielt und die Hauptapplikation bei 0x08002000. Da ich keinen Bootloader verwende, galt es das in den Linkeroptions anzupassen. Das ist aber noch nicht alles. Beim generieren des Projekts wird ein STM32_Startup.s File erzeugt. Dort sind über die Preprocessor Definitions mehrere Optionen auswählbar, wie sich die CPU beim Aufstarten oder nach einem Reset zu verhalten hat. Entscheidend war hier folgender Codeblock:
1 | #ifndef STARTUP_FROM_RESET |
2 | .thumb_func |
3 | reset_wait: |
4 | 1: b 1b /* endless loop */ |
5 | #endif |
Also habe ich in den Preprocessor Definitions "STARTUP_FROM_RESET" definiert und nun funktioniert das Programm auch nach einem Neustart der CPU.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.