Hallo. Ich programmiere (als Anfänger im 32bit Bereich) einen STM32F411VE auf einem selbst designten Board, dass auf dem Schaltplan des NucleoF411RE basiert. Dafür habe ich ein Programm, dass auf dem NucleoF411RE läuft, modifizeriert, sprich in den Projekteinstellungen den Controllertyp und den Debugger geändert. Für das NucleoF411RE nutze ich zum Flashen den integrierten ST-Link, auf dem eigenen Board den J-Link von Segger. Wenn ich das Programm auf den STM32F411VE schreibe und debugge ist soweit alles ok. Beende ich das Debuggen läuft das Programm weiter, alles gut. Schalte ich aber die Power ab und wieder an, läuft der Prozessor nicht an. Die Power bekommt er über eine USB-Leitung, über die auch serielle Daten laufen. Der Reset-Pin geht beim Einschalten auf high. Mit dem NucleoF411RE-Board läuft das Programm auch ohne den Debugger. Hat vielleicht jemand eine Idee, was ein solches Verhalten hervorrufen kann? Gruß. Nachtrag: Ich habe diesen Eintrag noch gefunden, der ein ähnliches Problem beschreibt: Beitrag "Olimex STM32-H103 startet nach Spannungsverlust nicht mehr" Leider ist mir die Lösung nicht ersichtlich. Kann mir dazu jemand was sagen?
:
Verschoben durch User
Birgit P. schrieb: > Hat vielleicht jemand eine Idee, was ein solches Verhalten hervorrufen > kann? Du hast auf deinem selbst designten Board etwas falsch gemacht. Entweder den Schaltplan nicht ausreichend 1:1 kopiert oder das Layout versemmelt. Details kann es erst geben wenn du mehr von dir preisgibst. Ansonsten ist R42 schuld, sagt die Glaskugel.
Ich weiss nicht, ob das das gleiche Problem ist: Ich hatte es auch bei einem STM32F407 Discovery Board. Es war dort notwendig, entweder eine alte oder eine ganz neue Firmware auf den integrierten ST-Link aufzuspielen.
Fehler Möglichkeiten: 1. Er landed im Internen Bootloader 2. Auswahl vom Programm Speicher ist falsch Das läuft über die 2 Boot Pins! 3. Program läuft unter dem Debugger im RAM und ist somit nach den Ausschalten weg. Das sollte aber alles schnell zu klären sein.
Einfach mal die Einstellungen (locater) prüfen. Läuft dein Code vielleicht im RAM? Würde beim Deguggen durchaus Sinn machen.
Das war es bei mir: https://electronics.stackexchange.com/questions/221895/stm32f407g-disc1-not-working-if-not-connected-to-pc
Birgit P. schrieb: > Ich programmiere (als Anfänger im 32bit Bereich) einen STM32F411VE auf > einem selbst designten Board, Hast du denn eine Programmiermöglichkeit per Bootlader wenigstens vorgesehen also vom 1. UART RxD+TxD sowie /Reset und BOOT(s) an irgendeinen Pfosten geführt? Dann könntest du ja das Ding mal per Bootlader brennen, oder wenigstens gucken, ob dir der Bootlader Hallo sagen kann - OHNE daß da ein SWD-Adapter seine Finger mit drin hat. Obendrein wäre es in solchem Falle sinnvoll, eine Art "lowest-Level" Debugger vorzusehen, indem du während des Startvorganges ein Signal an einem Portpin ausgibst (1x lang+1x kurz vor dem Taktaufsetzen, dann 1x lang+2x kurz danach und so weiter). Das kann man dann oszillografieren. Vermutlich hast du deine Firmware auch per irgend einer IDE gemacht, so daß du uns nicht sagen kannst, ob die für den RAM oder für den Flash gelinkt ist. Weiters mag es sein, daß du irgendwelche Interrupts freigegeben hast und deine CPU in irgend einem Nicht-Handler festhängt. Es gibt so viele Möglichkeiten, die dazu führen können, daß sich der Chip nicht wie erwünscht benimmt. W.S.
Ich finde den Tipp mit der blinkenden LED sehr gut. Bei AVR Mikrocontrollern kombiniere ich das mit serieller Ausgabe von Debug Meldungen (nach der Initialisierung). Dann kann ich einfach meinen USB-UART oder Logic Analyzer an die LED Klemmen und sehen, was los ist. Bei Arm Controllern kann man alternativ die TRACESWO Leitung mit einer LED kombinieren. So hat man eine LED, an der auch ein Laie (Kunde) ganz grob etwas ablesen kann und den Entwickler bekommt am selben Pin detailliertere Ausgaben zum Debuggen. In beiden Fällen wird das Geblinke der LED natürlich die serielle Kommunikation stören, aber das ist mir egal. Mit ein paar wirren Zeichen zwischen den echten Debug Meldungen kann ich leben. Mein Motorrad benutzt übrigens auch eine LED mit einer Art Morsecode, um Fehlermeldungen auszugeben. Dazu muss ich nur an der Motorsteuerung eine Brücke abstecken, und schon blinkt die LED. Die Fachleute würden anstelle der Brücke irgendein Diagnosegerät anstecken, dass ich als Laie aber nicht zur Verfügung habe.
Guten Morgen. Vielen Dank an alle die konstruktiven Hinweise und Anregungen gegeben haben. Die Hinweise auf die Boot-Pins haben mir geholfen. Da war im Layout bei Boot0 tatsächlich ein Pullup statt eines Pulldowns drin. Nachdem das geändert wurde lief es. Danke für die Hilfe! Gruß.
Den Boot-Pin kann man auch abschalten. In die Falle bin ich auch kürzlich rein gelaufen.
Ich mache, wenn ich an die Pins herran muss, immer einen Pullup und einen Pulldown ins Layout. Die Bestückung entscheidet dann was Sache ist.
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.