stm32f4 bootloader will nicht.

Uli schrieb:
> MAX232

Wirklich? Der braucht aber doch 5V, oder?

Die 3v3 Variante ist logischerweise drauf.

Uli schrieb:
> Gibt es ein TOOL (Windows/ DOS) was zuverlässig abreitet?

..so wie die glorreichen 7 ?

Also, meine Erfahrung ist, daß der Bootlader beim Löschen des Flash ein 
paarmal den Chip in den Reset steuert (wegen Disable Read Protect, 
Disable Write Protect und so) und daß dies erstens immer wieder ein 
neues Synchronisieren erfordert ($7F und dann auf $79 warten) UND daß 
das nicht wirklich immer ordntlich funktioniert, so daß man besser dran 
täte, den Chip per nRST selber zurückzusetzen.

Ich hab mir grad sowas mal selber geschrieben, weil ich mit dem Zeugs, 
was ST da anbietet unzufrieden bin. Ich häng es mal hier dran, obwohl es 
noch in einem recht lausigen Zustand ist. Geschrieben mit Delphi 6 und 
weil die Exe bei Win7 und vergrößerten Fonts lausig aussieht, nochmal 
kurz durch Delphi 10 geleiert. Ist unverschämt viel dicker bei 
identischem Nutzinhalt.

Also probier's aus wenn du willst.

W.S.

Deine Erklärung zum Bootloader ist recht interessant und würde vieles 
erklären.

Das Programm sieht wirklich schön aus und ich denke das es auch geht.
Aber leider ist meine Hardware nicht dafür geeignet.
Ich komme einfach nicht mehr an die Steuerleitungen ran.

VG, Uli

Uli schrieb:
> Ich komme einfach nicht mehr an die Steuerleitungen ran.

Tja, beim Fußball würde man dazu "Arschkarte" sagen. Aber da du ja 
selber dein Projekt gemacht hast, mußt du dir wohl selber die Schuld 
geben dafür, daß du dir ganz am Anfang nicht genug Gedanken gemacht 
hast.

Also Redesign... oder andere Zielsetzung.

Apropos Programm: Ich hab es jetzt ein bissl erweitert und benutze es 
recht intensiv. Ein Automatik-Knopf ist jetzt dabei und ein 
Terminalfenster, so daß man mit der ja ohnehin vorhandenen seriellen 
Verindung gegebenenfalls mit seiner frisch einprogrammierten Firmware 
kommunizieren kann, ohne irgend was umstecken zu müssen. Mal sehen, 
vielleicht stelle ich es bei Projects&Code ein.

W.S.

Das der Bootloader so schlecht ist konnte ich ja nicht ahnen.
Das ist auch das einzige was ich nicht vor dem Layouten getestet hatte.
Bin einfach davon ausgegangen das der schon sauber arbeiten wird.
Aber welches alternative Programm hätte ich denn vor ca. 2 Jahren 
gehabt?

Die Leitungen sind normal am STM32 dran, benutze sie aber zur Zeit 
nicht.
Aber wie gesagt ich komme an die Leitungen nur schwer ran (4 Lagig und 
liegen innen).

Kann man in deinem Programm nicht den original Modus einbauen, also ohne 
die Steuerleitungen?
Wenn ich dann 2 Versuche brauche ist das immer noch besser wie jetzt.


Da der Bootloader nicht geht spiele ich zur Zeit das Programm mit dem 
Debugger rein. Ist zwar nicht so schön aber solange es nicht anders geht 
muss ich halt jedes mal das Gehäuse auf schrauben.

VG, Uli

Uli schrieb:
> Das der Bootloader so schlecht ist konnte ich ja nicht ahnen.

Der Bootlader ist nicht wirklich schlecht, sowas kann man wirklich nicht 
sagen. Aber er muß ja beim Löschen der Options offenbar einen Reset 
erzwingen (oder man macht das von außen), damit die Hardware, die das 
Auslesen oder Beschreiben verhindern soll, entsprechend den (dann 
gelöschten) Option-Bits zurückgesetzt wird. Das ist Schutz-Hardware und 
die kann auch von einem residenten Bootlader nicht umgangen werden.

Aber so ganz kann ich deine Ausführungen nicht verstehen: Es sind ja 
neben den seriellen Signalen RxD und TxD nur noch Reset und BOOT, die du 
brauchst. Die können doch nicht überall auf innenliegenden Layern 
liegen, irgendwann müssen die ja mal an einen Hochzieh-R oder 
Runterzieh-R geführt sein - und der liegt immer außen.

Siehe deine eigenen Worte:

Uli schrieb:
> Einen Jumper für den Bootmodus gibt es auch.

Siehste. Dann fehlt dir nur noch der Reset - und der ist mit Sicherheit 
an irgend einem Widerstand abgreifbar.

Apropos: ich hab mein Programm grad in den letzten Tagen recht intensiv 
genutzt und mir dabei auch noch ein kleines Terminal eingebaut. Macht 
sich. Ich werd's wohl bei den Projekten mal einstellen.

W.S.

Gut vielleicht ist auch nur alles an getesteter Software dafür nicht so 
gut.
Ich kenne halt andere Bootloader (Prozessoren) und die arbeiten perfekt.

Klar kommt man irgendwie an die RESET Leitungen und wenn man direkt an 
den Pin ran gehen würde. Wenn der Pin nicht benutzt würden wäre es schon 
mal einfacher.
Das grösste Problem ist mehr das ich ja zum Kunden komme und da nicht 
unbedingt den Lötkolben raus holen will. Das öffnen vom Deckel geht 
gerade noch!

Was übrigens komplett gegen Deine Methode spricht ist das ich keinen 
Einfluss habe was der Kunde an Rechner dran hängt. Und damit habe ich 
auch keinen Einfluss auf die Steuerleitungen. Wäre echt blöd wenn der PC 
das System einfach in den Reset jagen kann.
Bei einer neu Entwicklung kann man ja das alles berücksichtigen und 
absichern.

Ich habe auch nur eine der Steuerleitung auf dem MAX die andere müsste 
ich mir übrigens erst dran basteln, was beim Kunde nicht so gut kommt.

An einen eigenen Bootloader hatte ich auch schon mal gedacht, aber 
mangels dringlichkeit noch nicht nach einem gesucht

VG, Uli

Marcus H. schrieb:
> Allerdings habe ich im Kundenauftrag schon verschiedene Varianten
> STM32-Bootloader geschrieben.

Hast Du den Bootloader in C programmiert?

Uli schrieb:
> Was übrigens komplett gegen Deine Methode spricht...

bringen wir's mal auf den Punkt:

Wenn du eine geordnete Updatemöglichkeit beim Kunden und durch den 
Kunden haben willst, dann mußt du das von Anfang an eben vorsehen. Jede 
JTAG/SWD-Updaterei schließt sich da von selbst aus, weil zu kompliziert 
für Kunden.

Ein Updaten per eingebautem Bootlader geht, denn dieser Bootlader idt 
erstens resident, kann also nicht flöten gehen - und er hat im 
Allgemeinen genug Intelligenz, um bei Formatfehlern usw. keinen groben 
Blödsinn zu machen. Aber: du mußt für sowas eben eine ordentliche Buchse 
vorsehen, die verpol- und versteck-sicher ausgelegt ist. Und du mußt 
dann auch ein narrensicheres PC-Programm nebst konfektionierter 
Schnittstelle vorhalten.

Es geht eben nur so.

W.S.

Also wie gesagt habe ich einen Software Bootloader noch nicht gesucht.
Das der dann in einem eigenen Bereich sitzen müsste und so weiter ist 
doch wohl selbstverständlich.

Ich denke das man sich über eine Möglichkeit zum Updaten Gedanken machen 
sollte ist klar.
Aber auf einer frei zugänglichen Schnittstelle, wo sogar ein PC vom 
Kunden immer dran sein kann weil darüber im normalen Betrieb Daten 
ausgetauscht werden, eine RESET Leitung dran zu hängen finde ich grob 
fahrlässig.
Bei einer gesicherten Service Schnittstelle ist das wieder was ganz 
anderes.
Aber das habe ich nicht.

Ich würde hier doch auch nicht fragen wenn alle getesteten Programme 
nicht total versagt hätten. Was einem auch zeigt das der interne 
Debugger anscheinend halt doch nicht so gut ist bzw alle Programme diese 
internen Probleme nicht ausbügeln können.

W.S. hat es doch selber klar gesagt der interne Bootloader braucht um 
stabil zulaufen einen externen Reset. Was ich ehrlich gesagt schade 
finde.

Bei mir kommt man an die Debugleitungen zum Glück recht gut dran.
Deckel aufschrauben und debugger einstecken. Der Anschluss wurde 
absichtlich gleich so gelegt das ich beim Testen nicht immer alles 
zerlegen musste.

VG, Uli

Uli schrieb:
> um stabil zulaufen einen externen Reset

Vielleicht solltest du das mal verstehen:

Uli schrieb:
> Aber auf einer frei zugänglichen Schnittstelle, wo sogar ein PC vom
> Kunden immer dran sein kann weil darüber im normalen Betrieb Daten
> ausgetauscht werden, eine RESET Leitung dran zu hängen finde ich grob
> fahrlässig.

Das ist es bei Weitem nicht, wenn man Vorkehrungen trifft. Entweder wird 
für's Update eine separate Buchse benutzt, die eben NICHT für den 
Normalbetrieb dient oder man führt die beiden Signale über Jumper, die 
zum Programmieren umgesteckt werden müssen... und zum Normalbetrieb eben 
wieder zurückgesteckt werden müssen. Das ist zwar nicht so bequem wie 
"lall" sagen, aber es geht - und zwar sicher. Reset und Boot ohne alles 
an die Normalbuchse würde wohl niemand machen. Aber für alles sowas muß 
man sich eben ganz früh beim Entwurf bereits Gedanken machen.

W.S.

Das ich versäumt hatte den Bootloader zu testen hatte ich doch schon 
zugegeben. Das man vieles in einem neuen Design besser machen kann ist 
doch auch klar, aber das System muss jetzt erstmal die nächsten 10-20 
Jahre laufen.
Alle System die draussen sind laufen noch mit Version 1.0 und werden es 
so wie es aussieht auch bis zum Ende. Es gibt nur 34 System bei denen es 
sonder Wünsche gab und die wurden vor Ort eingespielt.

Bei einem aktuellen Projekt an dem ich gerade sitzt gibt es eine Service 
USB Buchse, da muss ich die Tage mal testen ob darüber ein Update geht. 
Was bei diesem System aber nicht wichtig wäre da das Teil immer 
eingeschickt werden muss wenn was nicht geht.

VG, Uli

Das jedes mal bei egal welcher PC Software der bootloader abgebrochen 
hat und ich nach einer Funkionierenden Version gefragt hatte.

Wenn ich dann eine Bestätigung bekomme das der besser läuft mit einem 
externen Reset sagt das doch schon mal viel über die Qualität.

Vg, Uli

Hallo Leute,

für meine STM32F4, STM32Lx Projekte benutze ich einen selber 
geschriebenen.

Mein Problem ist: im eingebauten Zusatnd komme ich nicht an den BootPin 
ran.

Meine Bootloader Firmware ist logischerweise bei Offset 0.
Die Applikation beginnt bei 64kByte.
Ich muss in der Applikation StartAddresse und Interrupt-Vektoren 
veschieben.

Der Bootloader checkt sowas wie eine Signatur und überprüft das Firmware 
Image auf CRC.

HTH, Adib.
--

Uli schrieb:
> Wenn ich dann eine Bestätigung bekomme das der besser läuft mit einem
> externen Reset sagt das doch schon mal viel über die Qualität.

Wessen Qualität?
Also, mein Eindruck ist, daß es hier nicht vorangeht - allen Tips und 
Hinweisen zum Trotz.

W.S.

W.s. den Eindruck habe ich schon lange. Du selber hast bestätigt das der 
interne bootloader besser mit einen ext. Reset arbeitet. Also mit deiner 
und meiner Erfahrung zusammen kann man doch wohl sagen das der interne 
bootloader einem Probleme bereitet kann.

Was man an der Hardware falsch machen kann? Nichts! Jumper an den 
bootpin rx tx nach draußen und eine Versorgung .
 Auf dem PC eines von den freien Tools starten und ab gehts.
wenn dann alle Programme auf mehrern PCs an mehreren Modulen nicht 
laufen kann man halt annehmen das irgendwas faul ist.
Uli

Uli schrieb:
> Auf dem PC eines von den freien Tools starten und ab gehts.
> wenn dann alle Programme auf mehrern PCs an mehreren Modulen nicht
> laufen kann man halt annehmen das irgendwas faul ist.

Du hast ne seltsame Sicht auf die Dinge. Bei all diesen "freien Tools" 
muß man bedenken, daß diese in aller Regel von Privatleuten für deren 
eigenen Bedarf geschrieben wurden und dort auch zur Zufriedenheit 
fuktioniert haben. Sei also froh, wenn so einer in der Annahme, daß sein 
Zeug vielleicht auch anderen nützlich sein könnte, selbiges zum Download 
anbietet. Das ist eine grundsätzlich andere Sache als Software, die von 
Firmen zum Kauf angeboten wird.

Was da faul ist, kann ich dir sagen: Es ist die begrenzte 
Informationsmenge, die man als privater Bastler zur Verfügung hat. 
Deswegen sind Mißverständnisse angesagt oder Algorithmen, die wackelig 
sind, weil sie auf zu dürftigen oder gar im Detail falschen 
Informationen des Chipherstellers beruhen. Hab davon in den letzten 
Tagen auch so einiges erleben müssen. Ach ja, ein Update ist jetzt 
eingestellt. Vielleicht kommst du damit klar.

Und nochwas: Jedes Stück HW oder SW bereitet einem Probleme, solange man 
es noch nicht im Griff hat. Binsenweisheit. Ich sehe aber keinerlei 
Anlaß, sich davon entmutigen zu lassen, also jammere nicht. Zumindest 
ist es aus meiner Sicht dramatisch einfacher, mit meinem Progrämmle zu 
Potte zu kommen als mit sowas wie OpenOCD oder dem Download aus uVision 
über nen Segger EDU. Letzteres ist ein Oberkrampf, sobald man seinen 
eigenen Startupcode verwenden will oder CMSIS nicht verwenden will. Dann 
müßte man nämlich die Aufrufparameter der eigentlichen Tools selbst 
festlegen - und genau DAGEGEN wehrt sich dieses uVision nach Kräften und 
verkorkst dabei auch den Download per eingebautem Debugger. Aber das nur 
nebenbei, es ist mir inzwischen ganz und gar unwichtig geworden.

W.S.

uVision Kenne ich nicht!!!!
Gut besser benutze ich nicht.

EM::Blocks reicht damit kann ich alles machen was ich will.
Sogar an der Arbeit wird für alle Systeme nur der GCC benutzt und das 
hat nichts mit Geld zu tun.
Mit der ganzen Tool-Kette hatte ich eigentlich keine grösseren Probleme.
SEGGER Vollversion, EDU und ST-Link2 arbeiten Perfekt.

Bei mir arbeitet nicht mal das TOOL von STM sauber und das ist nicht von 
einem Hobbyprogrammierer für den eigen bedarf geschrieben.

Dein Tool (neueste Version) muss ich noch testen.
Hast Du vor davon auch eine Shell fähige Version zu machen?
Dann könnte man das so schön in eine Batch Datei rein packen.
Also Übergabe Parameter dem Programm mitgeben, so mache ich es immer 
wenn was quasi automatisch ablaufen soll.

VG, Uli

Nun, wir leben ganz gewiß in zwei völlig verschiedenen Welten. Ich hab 
in der Firma den Keil angeschafft und habe mich mit dem GCC nur bei der 
Lernbetty herumgeschlagen. Das war grauenhaft und extrem umständlich aus 
meiner Sicht, es sind so viele kleine und große Mistigkeiten damit.

Zu meinem Programm: man kann ihm eine Konfig-Datei oder eine Hexdatei 
als Kommandozeilenparameter geben.
Ich denke mal, das reicht.
Schließlich ist das Programmieren eine interaktive Angelegenheit.
Ich habe vielmehr den Schwerpunkt auf die tatsächliche Nützlichkeit 
gelegt. Zum einen gibt es einige Testfunktionen, mit denen man sein 
Programmiergeschirre einrichten und testen kann - was ich für extrem 
wichtig halte.
Zum anderen ist auch ein kleines Terminalfenster drin, was zumindest 
mir außerordentlich wichtig ist. Ich arbeite µC-intern eigentlich 
immer ereignisgsteuert und damit mit einem Event-System. Das hat sich 
seit gefühlten 100 Jahren so richtig gut bewährt. Obendrein hab ich auch 
immer einen genz kleinen Kommandointerpreter mit drin - jedenfalls wenn 
der Chip ohnehin eine Serielle hat. Das sind bei mir mittlerweile meine 
eigenen Standard-Moduln - und sie arbeiten im Gegensatz zu eine Debugger 
eben nichtintrusiv.

Sowas wie dieses EM-Blocks oder so kenne ich nicht aus eigener 
Anschauung. Hatte ich mir mal runtergeladen, aber noch nie installiert 
aus Mangel an Interesse daran. Ich arbeite lieber mit einem ganz 
gewöhnlichen Editor, einer Batchdatei für's Projekt und einem separaten 
Brennprogamm - und in manchen Fällen mit dem Oszillografen. Da ist es 
außerordentlich hilfreich, im Brennprogramm gleich ein Terminalfenster 
zu haben. Einen Bedarf an einer Verwendung als Kommandozeilentool sehe 
ich hingegen nicht. Wozu sollte es auch gut sein, eine ohnehin schon 
gestartete und auf dem Bildschirm sichtbare Anwendung noch einmal zu 
starten? Andererseits wenn man mal zwei oder mehr Chips brennen will, 
wozu sollte man dafür die gesamte Übersetzungskette neu durchziehen? Die 
zutreffende Hexdatei ist ja ohnehin vorhanden, also wozu neu übersetzen? 
Ich halte diese Skript/Batch & Tool-Idee an dieser Stelle für unsinnig.

W.S.

Das wir unterschiedlich an Probleme ran gegen und andere Tools 
bevorzugen ist doch normal.
Ich arbeite nun seit vielen  Jahren im Programmier Zirkus und kenne 
schon recht viele Tools, Compiler und IDEs.
Am ende bleibt man halt bei dem was einem am besten gefällt.
Interne Abläufe kann man so oder anders lösen, ist doch immer eine frage 
von der Anforderung.
Wer in einen Programm Update script ein neu kompilieren drin hat würde 
bei uns wegen unfähigkeit gefeuert.
Vg Uli

Uli schrieb:
> Wer in einen Programm Update script ein neu kompilieren drin hat würde
> bei uns wegen unfähigkeit gefeuert.

O ha!
Da frag ich mich, was ihr wohl mit jemandem macht, der die Hardware 
für's Update versemmelt hat... teeren+federn? oder so wie im alten Rom 
ab ins Kolosseum vor die Löwen?

Aber mal im Ernst, ein Update-Skript? make update und das von Hand per 
Kommandozeile? Anstatt einfach das Brennprogramm mit nem simplen 
Mausklick zu starten?

Aber laß mal, heut ist der Tag des Grillens und endlich das Märzen 
austrinken...

W.S.

Letztendlich ist es immer so das man irgendwas startet, nur ich 
bevorzuge halt das Prinzip starten, Finger weg und warten aufs ende. Da 
geht seltener was schief.

Die Schnittstelle geht ja, nur das Update nicht. Dein System teste ich 
endlich am Montag.
Wenn es geht dann kann endlich auch ein Servicetechniker das machen wenn 
es mal nötig wäre.

So jetzt ist alk abbauen angesagt.
Vg Uli

Uli schrieb:
> Die Schnittstelle geht ja, nur das Update nicht.

Hör mal, du hast da was ganz Grundsätzlichen NICHT verstanden: Eine 
Schnittstelle ist nur das Medium, nur der Transportkanal.

Aber was hier - wie immer bei solchen Aktionen - wichtig ist, ist das 
Zusammenspiel zweier voneinander unabhängiger Systeme. In diesem Falle 
PC und µC. Das bedarf eines Protokolles, was beide Seiten (jaja, BEIDE) 
einzuhalten haben, sonst geht es schief. Und zum Protokoll gehört eben 
auch, daß sich beide abstimmen - egal, ob der eine aus triftigen 
internen Gründen zwischendurch mal in den Sack hauen (sprich resetten) 
muß oder nicht.

Normalerweise verkneife ich mir, mit automobilen Vergleichen zu kommen, 
aber hier versuche ich das mal: Wenn du ne Straße hast und Autos, die 
drauf fahren können, dann hast du noch lange keinen geordneten Verkehr 
und du kannst nicht sicher sein, unbeschädigt von Berlin nach Zürich zu 
kommen. Was du brauchst, ist eine Straßenverkehrsordnung, an die sich 
alle halten, sonst kracht es und du landest nicht in Zürich, sondern im 
Hospital: "Die Straße geht ja, aber nicht die Fahrt nach Zürich".

W.S.

Ich habe das schon verstanden.
Nur um bei deinen Beispiel zubleiben.
Du Strasse habe ich gebaut und getestet, die regeln und alles andere 
haben andere gemacht.
also was kann ich dafür das hier jemand falsch fährt.

Für mich bedeutet das halt das was nicht ankommt und ich nicht weiter 
komme.
Vg, Uli

Uli schrieb:
> also was kann ich dafür das hier jemand falsch fährt.

Nun, du hast keine Ampeln (Reset) und Wegweiser (Boot) aufgestellt - 
aber laß mal, Autovergleiche waren schon immer eher schräg...

W.S.