So Leute, hier kommt ein kleines Programmier-Tool, das ich mir zum Brennen der STM32Fxxx Controller über deren eingebauten Bootlader geschrieben habe. Es ist noch recht frisch, ich hab's erst seit ein paar Tagen in Benutzung. Eine kleine Beschreibung als PDF ist dabei, es sollte also keine wirklichen Probleme damit geben. Der Hintergrund ist ganz einfach, daß man als J-Link-Edu Besitzer ja leider auf J-Flash verzichten muß und das Gehampel mit dem Debugger via IDE mir nicht schmecken will - UND: daß die originale Bootlader-PC-Software von ST mir mißfällt. Viel Spaß beim Basteln W.S.
Windows-App versus Kommandozeilen-Tool. Überleg dir selbst, was du lieber magst. W.S.
W.S. schrieb: > Windows-App versus Kommandozeilen-Tool. > Überleg dir selbst, was du lieber magst. Ich bin mir ganz ganz sicher daß ich das Kommandozeilentool bevorzuge. Denn das kann ich ganz simpel in meinen make-Prozess integrieren und bei Bedarf einfachst fernsteuern. Die Klickerei kann ich dagegen nicht automatisieren und muss sie immer von Hand machen.
So, es gibt ein Update. Ich hab ein bissel am Programm gefeilt. Es ist jetzt etwas schneller, aber man kann keine Wunder erwarten. Auch das Synchronisieren mit dem Bootlader geht jetzt deutlich schneller, man kann das Read- und Write-Entsperren jetzt übergehen, spart auch Zeit. Testeshalber hab ich mal bis zu 160 kBaud mit einem STM32F302 ausprobiert. Es geht, aber ohne spürbaren Geschwindigkeitszuwachs gegenüber 115 kBaud. W.S.
Danke, das du dich dem leidigen Problem des Bootloaders beim STM32 annimmst! Bei dem von dir vorgestellten Programm komme ich leider auchnur bis zum Chiptest(Chip-ID:3200). Die Verbindung über den virtuellen COM-Port kommt also zustande. Ein Löschen oder Programmieren scheitert mit "keine Verbindung zum Chip". Ich habe hier ein "Olimex E407-Board" mit einem ESP8266 wifi to serial an den Bootpins(TX,RX,GND) ohne zusätzliche DTR,RTS. Zum booten habe ich B0-1/B0-0 gebrückt(selbe Vorgehensweise wie mit USB-seriell Adapter und da funktionierts mit dem Demo-Flasher von ST..)
Angehängte Dateien:
-
Commandline-Tool.jpg
110 KB
Mit dem Kommandline-Tool stmflasher komme ich zumindest soweit: s.o.
Ich geb's auf und bleibe bei: Beitrag "Stm32 flashen über ser. mit wifi-esp8266" Win7 erkennt plötzlich die stm32flasher.exe nichtmehr als gültige Anwendung..
e-d schrieb: > Hier noch ein Bild des Verbindungstests.. Wähle mal "entsperren und löschen". Vielleicht ist irgendwas in den Options gesetzt. Nebenbei: die Options sind bei meinem Programm erstmal außen vor. Als nächstes solltest du dir deinen Chip in die Liste (targets.cfi) aufnehmen. Ein Chip mit PID 3200 steht da noch nicht drin. Deshalb fehlen eigentlich alle Parameter, insbesondere Flash-Start und Länge. Also, probier noch mal und laß uns die Ergebnisse wissen. W.S.
Angehängte Dateien:
-
HW_VSP3.jpg
90 KB -
stm32flasher.jpg
72 KB
Der ESP-Wifi to ser.Port ist fest auf 115200 Bd eingestellt. Irgentwie liest dein Programm die PID falsch(richtig wäre 0x0413); Könnte default bei dir die hälfte sein? Beim virt.COMport ist unbedingt unter"settings" die "NVT enabled" rauszunehmen.(dazu login) Da der neue Flasher von ST o.B. funktioniert, bleibe ich zunächst dabei. Danke für dein Programm! Aber: "Never change a winning team .." So kann ich den STM32F407 drahtlos flashen.
So, wieder ein Update. Diesmal wegen des offensichtlichen Bedürfnisses, ohne BOOT und RESET auskommen zu wollen. Und da ich schon mal dabei war, hab ich auch noch bin und s19 als Dateiformate mit aufgenommen. Ich denk mal das war's bis auf weiteres. W.S.
Was bedeutet den beim löschen "no proc eex 00Fehler beim EraseMemExt" ? Ich benutze nicht die Leitungen für BOOT Mode und Chip Reset! Der Prozessor ist ein STM32f407 1024K. Habe zum Testen auch mal die Baudrate geändert, ohne Erfolg. Ich hätte ich da noch so ein paar kleine Wünsche. 1. Funktion sonst bringt mir das andere ja nichts 2. Eine Möglichkeit zum abbrechen beim leer test, das dauert ja ewig. 3. Entweder der GCC liefert mist oder etwas ist mit der HEX lese Routine nicht richtig Fehler"ausserhalb: 08000000" werde ich selber mal testen. VG, Uli
Uli schrieb: > Was bedeutet den beim löschen "no proc eex 00Fehler beim EraseMemExt" ? Daß das Kommando $43 also Extended Erase Memory zwar vom Bootlader akzeptiert und mit ACK (also $79) quittiert wurde, aber nach 5 Sekunden noch immer nicht vollzogen und mit einem zweiten ACK quittiert worden ist. Hätte dort das NAK ($1F anstelle 00) gestanden, dann hätte der Bootlader die Ausführung abgelehnt. Ist aber nicht. Der Bootlader braucht schlichtweg zu lange - und zwar SEHR zu lange. Normal ist eine Dauer für's extended Bulk-Erase von so etwa 40..60 ms, bei größeren Flashs vielleich auch etwas länger, aber nie und nimmer geschlagene 5 Sekunden. Wenn du hingegen 'no cmd eex ' gesehen hättest, dann würde das bedeuten, daß der µC das betreffende Kommando $43 nicht akzeptiert hätte. Ich hab bei diesem Programm erstmal ohne separate Threads gearbeitet, also mußt du dich beim Auslesen oder Leertest eben gedulden. Der Bootlader kennt nur memory read oder write aber kein compare oder nen Leertest. Also muß man zum Leertest alles erstmal lesen und auf $FF prüfen. Zu Hexfile-Inhalten außerhalb des Flashroms: Da gibt es eigentlich nur das Feld mit den Options und die sind einstweilen außen vor. Guck mal bei deinem Eintrag für ARM-NONE-EABI-OBJCOPY, was da so alles kopiert wird. Ich bin mir ziemlich sicher, daß du in deinem Projekt die Options mit irgend welchen Readout-Sperren gesetzt hast. Nimm das raus, es wird einstweilen nicht unterstützt. Steht auch so in der Beschreibung. Ob ich das Beschreiben der Options einbaue, weiß ich zZ noch nicht. Mal sehen, ob genug danach geschrieen wird... Ich selbst brauche sowas nicht. Nochwas: hast du auch deinen µC in der Liste eingetragen oder einen kompatiblen Typ ausgewählt? Die Lage und Größe des Flashes nimmt das Programm aus dieser Liste und wenn dort bunte Knete drinsteht, geht es nicht. Ach ja - ich habe "nur" 2 MB Puffer für den Flash vorgesehen. Und der Hex-Lader spuckt auch bei: Record 2 (Extended Segment Address Record) Record 3 ( CS:IP Address Record) weil die in so eine Firmware nicht hineingehören. Obendrein spuckt er auch bei Nichtvorhandensein von Record 1 (Ende-Record) Du brauchst also ein wirklich fehlerfreies Hexfile für und NUR FÜR den Flashrom. Mal sehen, vielleicht mach ich mal ne Liste der vorhandenen Fehlermeldungen. W.S.
Ich hatte einen Typ aus der liste genommen (05 07 ....). Also ist irgendwas zu langsam im / um dem stm. Nur was? Der 8 MHz Quarz sollte es doch nicht sein, zumal die Kommunikation ja läuft. Die gcc -> hex Ausgabe schaue ich mir morgen genauer an. War von der IDE angelegt worden, ist ja anscheinend fehlerhaft. Nunja bis zur Programmierung komme ich noch nicht wegen dem löschen. Aber das sollte zum Glück ja einfach zu finden sein. Vg, Uli
So, ich hab das Ganze jetzt mal mit einem Discovery nachvollzogen. Also ein älteres mit STM32F407VGT6 drauf, stammt von einer früheren Embedded. Anschluß geht nur über USART3, PB10+11. Der USART1 ist anderweitig verbraten und deshalb unbenutzbar. Der Bootlader weist sich als Rev. 3.1 aus, klingt soweit gut. Aber: beim Löschen akzeptiert er zwar das Kommando für's Bulk-Erase (Extended Erase Memory, Special case 0xFFFF, also "global mass erase"), aber er gibt anschließend KEINERLEI Mucks von sich. Ich habe mal die Wartezeit auf satte 15 Sekunden erhöht - ebenfalls nichts. Der Flash ist jedoch schon nach 1 Sekunde brav gelöscht. Zu bemerken war, daß der BL beim nächsten Reset und anschließendem Synchronisieren 2x nicht will und erst beim dritten Anlauf sich endlich meldet. Ob das ein Fehler im Bootlader ist oder eine häßliche Interferenz durch den auf dem Board befindlichen ST-Link, ist fraglich. Auf alle Fälle verhält sich dieser Bootlader nicht konform zum AN3155, dort Kap. 3.8. Er müßte in jedem Falle entweder ein ACK oder ein NAK von sich geben. Ich hab allerdings die diversen Errata noch nicht durchforstet. Der Rest geht eigentlich problemlos über die Bühne. Hab das Teil mit 160000 Baud betrieben und Auslesen, Programmieren, Verifizieren geht ohne Makel. Lediglich beim Bulkerase hapert es. W.S.
Ich bin also doch nicht zu blöd, Glück gehabt, Puh! Und der Bootloader will nicht richtig wie schon immer befürchtet. Habe mir das Hex File angesehen. :020000040800F2 :1000000000000220C54E0008D54F00081931000835 :10001000D94F0008DD4F0008E14F00080000000044 ... :045A500089010008C0 :04000005080001DC12 :00000001FF Der Inhalt könnte stimmen. Der Aufruf ist: arm-none-eabi-objcopy -O ihex test.elf test.hex Also auch irgendwie ganz normal. Kann es sein das Du mit dem "Extended Linear Address Record (Typ 04)" nicht klar kommst? Ich werde nachher mal das BIN Format testen. Mit "arm-none-eabi-objcopy -O binary test.elf test.bin" VG, Uli
Uli schrieb: > Kann es sein das Du mit dem "Extended Linear Address Record (Typ 04)" > nicht klar kommst? Ach wo, dieser Block wird benötigt, um über die 64K Grenze zu kommen und ist implementiert. Aber wo ich sowas lese: "ausserhalb: 08000000" kommt mir der Verdacht, daß du deine Firmware nicht auf 0 sondern auf 0x08000000 gelinkt hast. Das ist ein Fehler. Der Flash geht laut ST zwar ab 0x08000000 los, aber das gilt erstmal nur für's Flashen. Die eigentliche Abarbeitung findet normalerweise ab 0 statt, wohin der Flash gespiegelt wird. Wahrscheinlich kann man sich auch ne Abarbeitung ab 0x08000000 denken, denn SP und PC werden ja beim Reset aus den Vektoren geladen, aber das Normale bei einem ARM ist eben das Abarbeiten ab 0. Also linke dein Zeugs mal auf Null. W.S.
So, mal wieder ein Update. Ich habe nun ein sektorweises Löschen eingebaut. Wer also einen Chip hat, der sich nicht per Bulkerase löschen läßt, der kann es jetzt sektorweise tun. Ausprobiert habe ich das Ganze mit einem steinalten Discovery, das ich mal auf der Embedded in die Hand gedrückt bekam. Es geht, aber das sektorweise Löschen ist teilweise schnarchlangsam. W.S.
Hallo, danke für das Programm; ist nach einigem Frust mit dem STMFlashLoader genau das was ich suche ;) Ich habe gerade mal versucht, mit dem Programm einen STM32F100VB zu flashen. Das ist ein Chip der Klasse "STM32_Med-density-value_128K", ist in der targets.cfi also mit 128kB Flash angegeben. Wenn ich jetzt ein .bin File der Größe 131072 (also genau 128k) flashen will, sagt mir das Programm "Datei ist zu groß für diesen Chip". Es gibt von dem Chip mehrere Varianten, die dieselbe PID 420 haben; möglicherweise bringt das STM32Prog da was durcheinander... Grüße, Ulrich
Ich hab da ohnehin ein mentales Problem mit den aus dem ST-Zeugs maschinell (per Script) entnommenen Daten. Zum einen die verwirrenden Typbezeichnungen, zum anderen die mehrfach vergebenen PID's, dann die derzeit zwar unbenutzten aber dennoch fischigen Sektorlängen, die bei einigen Typen auch mal unterschedlich lang sind bis hin zu den nur teilweise vorhandenen Options. Mein Rat: schmeiß alles, was du nicht brauchst, aus der targets.cfi gnadenlos raus, gib dem verbleibenden Rest sinnvolle Namen (konkrete Typbezeichnungen) und probier einfach mal als "Schweinereiversuch", bei der Spalte "FLASH-END" anstelle 0801FFFF; eben 08020000; hinzuschreiben oder nen größeren Chip anzuwählen - vorausgesetzt, dein Chip beherrscht das Bulkerase. Ansonsten werde ich in den nächsten Tagen in die Quellen gucken, mal sehen, ob mir da was auffällt. So langsam nimmt das Ganze ungeahnten Umfang an. W.S.
OK, ich habe jetzt mal aus der targets.cfi alle Einträge außer dem Eintrag für STM32_Med-density-value_128K gelöscht; das Flash-End habe ich auf 0801ffff gelassen. Damit läßt sich das Binary einwandfrei flashen. :) Soweit also alles wunderbar. Das STM32Prog läuft in meinem Aufbau übrigens auch ohne den Chip-Reset wesentlich stabiler als der STMFlashLoader. Danach habe ich noch etwas mit Hexfiles experimentiert und da ist mir doch noch was aufgefallen: Meine GNU-Toolchain generiert im Hexfile offenbar Extended Segment Address Records und damit scheint das Programm nichts anfangen zu können. Fehlermeldung: "unerwarteter Record 2 auf Zeile 4097". Hier der Kontext:
1 | :10FFC000B81A00200048004080B582B000AF396008 |
2 | :10FFD0000146F971BA717B71FA7913461B019B1ABC |
3 | :10FFE0009B00664A1344184600213C2201F03FF969 |
4 | :10FFF000FB79012B28D0022B4DD0FA795F491346AB |
5 | :020000021000EC <-- Zeile 4097 |
6 | :100000001B019B1A9B000B445D4A5A60FA795B49BD |
7 | :1000100013461B019B1A9B000B445A4A1A60FA793B |
8 | :10002000564913461B019B1A9B000B443033202278 |
9 | :100030009A80FA79514913461B019B1A9B000B4485 |
10 | :10004000303310221A804DE0FA794C4913461B01D7 |
Grüße, Ulrich
Ups, habs gerade gesehen; das mit den Extended Segment Address Records wurde ja oben bereits erwähnt... Sorry, Ulrich
O manoman, das wird ja lustig..
Also
Record:
0 = Daten (benötigt)
1 = Enderecord (benötigt)
2 = Extended Segment Addr -> Fehler, da nur für I386
3 = Extended CS:IP -> Fehler, ebenso nur für I386
4 = Extended Linear Addr (benötigt)
5 = EIP unbenutzt
6..Rest = Fehler
Dein Fromelf sollte also nur die Records 0, 1 und 4 erzeugen.
Für den Record 2 gilt m.W. die alte Regel, daß die Segmentadressen sich
überlagern, also ein Segment 16 Bytes groß ist (vom 8086 herrührend).
Schema:
SSSSSSSS0000 Segmentadresse
AAAAAAAA Adresse
-------------
XXXXXXXXXXXX Summe
20 Bit Gesamtadresse (640K sollten nach B.Gates ausreichen..)
W.S.
Nachtrag:
Bei mir sieht sowas so aus
:020000040001F9
:02 Länge
0000 leer
04 Record 4
0001 High-Adressteil
F9 Psum
(hoffentlich hab ich mich hier nicht vertippt)
W.S.
Bin weitergekommen. srec_cat ersetzt die lästigen Extended Segment Addr durch Extended Linear Addr. Damit funktionierts dann.
1 | srec_cat.exe input.hex -Intel -Output output.hex -Intel --address_length=4 |
Ist für mich kein Zusatzaufwand, weil ich srec_cat ohnehin nutze um eine CRC an den Code anzuhängen. Grüße, Ulrich
Guck lieber nochmal in die Doku zu deinem "FromElf" (also dem GCC-Pendant dazu) wegen -Intel und so. Normalerweise überlappen sich bei CS:IP beide Register ja um 4 Bit. Nicht daß der Nächste sich dann wundert, daß bei seinem Projekt die Firmware wegen solcher Dinge nicht läuft. Aber ein bissel wundern muß ich mich schon darüber, daß das GCC-Zeugs solch einen Lapsus produziert - immer vorausgesetzt, daß da nicht doch noch ein finsterer Parameter falsch ist. Ich erinnere mich mit größtem Ärger daran, daß der GCC-Assembler bei Code, der mit .thumb assembliert wurde, die im Code enthaltenen Labels fröhlich als ARM-Labels in den Objektcode gepackt hat, anstelle die eben auch als .thumb auszuweisen. Das ließ sich erst mit zusätzlichem .thumbfunc oder so ähnlich ausmerzen. Und das Schärfste war, daß dieser fette Bug den GCC-Leuten seit langem bekannt war - sie haben ihn nicht ausgemerzt, sondern nen Workaround per .thumbfunc dazu erfunden. Naja, mich selbst hat's ja nicht wirklich getroffen, denn ich benutze den Keil und da kommt sowas nicht vor. W.S.
Also da gibt es leider keine Möglichkeit. GNU objcopy unterstützt mit -O ihex zwar die Ausgabe als Hexfile, aber weitergehende Optionen zur Steuerung des Ausgabeformats sind nicht implementiert... Grüße, Ulrich
Dann haben wir es mit nem Bug zu tun. Wieder mal... Abhilfe: das Ganze als Binärdatei ausgeben oder als Motorola S19. Ich glaub, das hieß -O mhex. W.S.
Ich würde nicht sagen, dass es ein Bug ist: :020000021000EC und :020000040001F9 sollten lt. Spezifikation des Intel-Hex Formats das gleiche bewirken, nämlich einen Offset von 0x10000 für die nachfolgenden Adressen. Ob das jetzt für einen I386 ist oder für einen ARM, spielt m.E. überhaupt keine Rolle auch wenn es auf letzterem keinen richtigen Sinn ergibt. Für Motorola Srecord muss objcopy mit "-O srec" aufgerufen werden. Jörg
Joerg W. schrieb: > sollten lt. Spezifikation des Intel-Hex Formats das gleiche bewirken, > nämlich einen Offset von 0x10000 für die nachfolgenden Adressen. Nein, eben nicht. Es ist stattdessen ne "extended Segment Addr", also für die Segment-Register des '86 gedacht. Für den linearen Adreßraum ist Record Nr. 4 gedacht. Der ist dafür da, die Bits 2^16 bis 2^31 zu setzen. Der Keil macht das genau richtig, da gibt's nichts zu meckern. Ich könnte jetzt zwar mein Programm entsprechend ändern, so daß es nen Workaround um den Fehler des Gnu-Dingens macht, indem es Record Nr. 2 genauso behandelt wie Record Nr. 4, aber eigentlich gehören Bugs an ihrer Wurzel beseitigt - anstelle eines Workarounds. Also, was nun? W.S.
Nachtrag (aus Wikipedia): "Extended Segment Address Record (Typ 02) Der Datensatz enthält die Basisadresse des Speichersegments. Er wird verwendet, wenn der Umfang eines 16-Bit-Adressraums (also 64 kByte) nicht ausreicht. Die im Datensatz enthaltene Adresse wird mit 16 (24) multipliziert und bei den folgenden data records (Typ 00) zu der dort enthaltenen 16-Bit-Adresse addiert." Merke: Die enthaltene Adresse wird mit 16 (sechzehn!) multipliziert und dazu der PC wert addiert. Also GENAU SO, wie ich das weiter oben skizziert habe. Fazit: Es IST ein Bug, hier den Record Nr. 2 zu verwenden. Leute, gebt euer Zeugs als binär oder Motorola aus und fertig ist die Laube. W.S.
Habe das Verhalten mal in den GCC-ARM-Embedded Bugtracker eingegeben. https://bugs.launchpad.net/gcc-arm-embedded/+bug/1595152 Viel verspreche ich mir davon aber nicht; die meisten Tools scheinen ja mit den Typ 2 Records klarzukommen. Das S-Record Format scheidet für mich als Alternative aus, da ich auch die Flashtools von ST verwende, z.B. das STM32 ST-LINK Utility.exe, und die können nur Binary und Intelhex. Ich denke, ich bleibe erst mal bei der Methode, das Hexfile nach dem Compilieren durch srec_cat zu jagen. Grüße, Ulrich
U.B. schrieb: > die meisten Tools scheinen ja > mit den Typ 2 Records klarzukommen. Mag ja sein. Ich könnte dafür nen Workaround einbauen, das wäre programmiertechnisch gar kein Problem. Aber es ist einfach eine fette Unsauberkeit, einen Bug mit einem weiteren Quasi-Bug zu umschiffen. Das ist der Punkt. Ich hab schon geschludert, als ich beim Synchronisieren ein korrektes NAK als ein Quasi-ACK umgedeutet habe, bloß weil manche partout kein Reset haben anschließen wollen. Mir ist unwohl dabei, denn sowas ist nicht der korrekte Weg. Wenn das so weitergeht, dann besteht das ganze Programm nur noch aus Workarounds, anstatt daß die Fehler an ihrer Wurzel beseitigt werden. Aber wo ist für dich das Problem, sowohl Hex als auch Bin oder Motorola ausgeben zu lassen? Dann hast du beides... W.S.
Nachtrag: Ich hab mir das aus deinem Bugreport mal näher angeschaut: :020000021000EC <-- Error also :02 Länge ___0000 leer _______02 Record 2 _________1000 Nutzinhalt _____________EC Psum Mit anderen Worten: 1000h * 16 --> 100000h Das ist genau die CS:IP Rechnung wie weiter oben beschrieben. Wenn man es wie der 8086 rechnet, dann kann man damit einen Adressraum von 1 MB überstreichen. (genauer gesagt 1 MB + 64K) wie zu MSDOS Zeiten. OK, das reicht für die meisten Bastelprojekte aus, obwohl es eigentlich für eine andere Architektur als ARM gedacht ist. Ich hätte da ne Bitte an dich: Erzeuge mal mit irgendwas eine Firmware, die mindestens etwas mehr als 512K groß ist und gelegentliche Lücken von einigen KB mittendrin hat. Würde mich interessieren, was für Record 2 Inhalte die Gnu-Toolchain dabei erzeugt. W.S.
W.S. schrieb: > Mag ja sein. Ich könnte dafür nen Workaround einbauen, das wäre > programmiertechnisch gar kein Problem. Aber es ist einfach eine fette > Unsauberkeit, einen Bug mit einem weiteren Quasi-Bug zu umschiffen. > > Das ist der Punkt. Du hast ja Recht, aber gibt Dir dennoch einen Ruck und mache es einfach. Es muß ja nicht jeder erneut auf die Nase fallen, nur weil er keine S-Records kann oder kennt.
Ich habe mal mit einem modifizierten Linkerfile getestet (Binutils 2.25.1). Solange das Ganze unter 1MB bleibt, werden Typ 02 Records erzeugt, darüber dann Typ 04. War auch nach dem bisher Gelesenen nicht anders zu erwarten und entspricht auch der Intel-Hex Spezifikation. Wenn ich z.B einen Block bei 0x0c0000 losgehen lasse und einen anderen bei 0x1c0000, dann erscheinen im Hexfile die folgenden Records: :02000002C0003C <Code 1. Teil> :020000020000FC :02000004001CDE <Code 2. Teil> Vor dem Extended Linear Address Record wird das Segment wieder auf 0 zurückgesetzt. Lt. Spezifikation wäre das nicht notwendig, schadet aber auch nicht. Da ich für die STM32 nach 0x08000000 linke bzw. S-Records verwende, ist mir das bisher gar nicht aufgefallen. Jörg
Joerg W. schrieb: > Ich habe mal mit einem modifizierten Linkerfile getestet (Binutils > 2.25.1). Solange das Ganze unter 1MB bleibt, werden Typ 02 Records > erzeugt, darüber dann Typ 04. Manchmal frag ich mich "warum bloß so ein Zinnober...?" Mit dem Record 4 kann man den gesamten 32 Bit Adresßraum erreichen und er trägt kein bißchen mehr auf als dieser knöselige Record 2, der ja eigentlich NUR für die i8086-Architektur vorgesehen ist, wo sich Segmentregister und IP überlappen - sowas gibt's nirgendwo sonst, erst recht nicht bei ARM. Was sind das bloß für kranke Hirne, die im selben Programm beides zwar können, aber feinsäuberlich einen Bug hineinprogrammieren, wenn die Adresse unter 1MB liegt... Mir ist sowas auch nicht vorher aufgefallen, schließlich macht Fromelf vom Keil die Sache richtig. Und jetzt soll ich an die verkehrt programmierte Gnu-Krücke noch eine zweite Gehhilfe dranbauen. Mittlerweile hab ich den Eindruck, daß ich bei jedem Kontakt mit Gnu-Zeugs irgendeine häßliche Stinkbombe unter die Nase kriege. Ging mir bei der Lernbetty schon so. Bislang hab ich den GCC bloß als zu verquaast empfunden, aber so langsam krieg ich ne GCC-Allergie. Na mal sehen. Aber heut ist es mir zu heiß dafür. W.S.
So, bevor es mir heute auch zu heiß wird, hab ich auf die Schnelle (!!) diesen elendigen Record 2 eingepflegt, neue Version anbei - und einiges Unwohlsein meinerseits angesichts dieses ***** dazu. ABER: Bitte umgehend mit euren Gnu-Tools ausprobieren, ob es wirklich so klappt. Ich hab zwar die olle Yagarto aus Lernbetty-Zeiten noch herumstehen, aber seitdem nie wieder benutzt. W.S.
Vielen Dank für das Update! Habs gerade ausprobiert und es funktioniert einwandfrei :) Grüße, Ulrich
So, nach langer Zeit ein kleines Update. Jetzt auch mit einer Lazarus-Version. W.S.
Hi, danke für das Programm. Hiermit konnte ich mein STM32 endlich programmieren. Schade, nur WIN10 - bin Linux Maker.
Kurt P. schrieb: > Schade, nur WIN10 - bin Linux Maker. Bist Du lediglich Linux User oder wirklich Unix Maker? Wenn Maker, dann make Dir ein Programm doch selbst unter Linux. Den STM32-Bootloader zu bedienen ist wirklich kein Hexenwerk.
Hi Frank. Maker, habe ich so nicht gemeint. Bin Linux User! Unter Linux habe ich selbstverständlich die entsprechenden Tools. Das h i e r erwähnte Programm unter Linux wäre schön gewesen.
Also wer denn nun: Kurt Pieper oder Kurt(Gast)? Ich habe es in der zugehörigen Dokumentation ja schon erwähnt: Wenn ein Linuxer ernsthaft das Programm nach Linux umsetzen will, kann er von mir die Quellen kriegen. Eine Lazarus-Version hab ich ja schon selber gepostet. Also sollte man das als interessierter Linuxer auch hinkriegen. W.S.
Kleine Anmerkungen zu deinem schönen Programm: - ein "About" sollte nicht fehlen auch wenn es nur ein Synonym ist (man merkt dass du als Person die Öffentlichkeit scheust). Gleiches gilt für das Doku-PDF. - Das Programm-Fenster positioniert sich bei mir immer unten rechts, das ist gelinde gesagt "gewöhnungsbedürftig". So einen grossen Bildschirm wie du habe ich offensichtlich nicht. Vielleicht andere auch .... Zwei Koordinaten (x, y) in einer Config-Datei und alles ist in Butter.
Hallo W.S, danke für die Info. Habe das Projekt STM32 in die Schublade gelegt. Ich entwickle zur Zeit mit ATMEL-Mikrocontroller Decoder (Licht + Signale) am CAN Bus für eine Märklin Eisenbahn. https://www.youtube.com/watch?v=pjQ7-ROPI28 STM32 war ein kleiner Ausflug! Viel Erfolg. Gruß Kurt und Gast
:
Bearbeitet durch User
So, dem zuvorigen Mosern folgend, gibt es hier ein Update. Inhaltlich hat sich NICHTS geändert, es ist nur Kosmetik dahingehend, daß das Programm sich jetzt seine Bildschirmposition merkt. Obendrein merkt es sich nun, ob man die COM-Ports scannen will oder nicht. Aber kein About-Button u.dgl. Wozu auch, zum Benutzen braucht man sowas nicht. Es ist nur die reine EXE, also ohne Dokumentation. W.S.
ich habe den gerade mal ausprobiert..bei STM32F373 gehts nicht.. Beu AUTO erkennt er STM32F3_7x_8x_256K, 128 Pages Wenn ich dann programmieren klicke kommt. außerhalb 08000000
Frank t- schrieb: > Wenn ich dann programmieren klicke kommt. außerhalb 08000000 Dann hast du Code im Bereich außerhalb der zulässigen Adreßbereiche. Ich selber linke meine Projekte immer ab Null, weil das der übliche Bereich für den Flash bei den Cortexen ist. Deshalb die eingebaute Regel: - Code, der im Bereich von 0 bis Codemax (hier wohl 256K) liegt, wird auf den Programmierbereich ab 0x0800:0000 bis 0x0800:0000 + Codemax transponiert. - Code im Programmierbereich ab 0x0800:0000 bis 0x0800:0000 + Codemax wird so wie ist programmiert - und alles, was außerhalb liegt, wird bemeckert. Mache aus deinem Hexfile mal ein Binärfile und brenne das. Wenn das auch nicht klappt, dann poste mal das Ergebnis hier. btw: du kannst mit dem Bootlader nicht die Codeprotect-Bits brennen. Die liegen außerhalb und du kannst sie nur aus deiner Firmware heraus setzen. Das braucht auch ein gewisses spezielles Procedere. W.S.
Nachtrag: Ich habe selber mit dem Brenner die STM32F302RBT6 gebrannt. Also mit dieser Reihe sollte es eigentlich gehen. Notfalls setze einen eigenen Eintrag in die targets.cfi hinein - falls dieser Chip ungewöhnlich sein sollte. W.S.
So, nochmal ein Update. Inhaltlich hat sich nichts geändert, lediglich werden jetzt beim Laden der Hexfiles die Anzahl geladener Bytes angezeigt und die erlaubten Bereiche sind jetzt eingeengt, aber variabel (wenn man die targets-Datei editiert). Also, der erlaubte Code darf jetzt in folgenden Bereichen liegen: von 0 bis Codegröße des Chips - oder vom in der targets-Datei angegebenen Bereichsanfang für das Flashen bis Bereichsanfang + Codegröße. W.S.
Hi, ich habe ein kleines Feedback zusammengeschrieben. kann man einen Adressoffset angeben? Wenn nicht (ich habs nicht gefunden), bitte die Möglichkeit den Adressbereich anzugeben hinzufügen. Ich arbeite mit dem SPWF01SA und das hat selbst noch einen Bootsektor ab 0x08000000. Wenn ich diesen Überschreibe funktioniert das Modul nicht mehr. Somit kann ich deine Software nicht zum Updaten verwenden. Die Software muss ich ab 0x08002800 flashen. Und bei Teste Verbindung+Chip findet wechselt das Programm immer meine Einstellung des Chips. Der Prozessor ist ein STM32 High destiny mit 512k und es wird immer nach dem Test Verbindung+Chip auf den mit 256k gewächselt. Beim Programmiervorgang hat sich das Programm dann aufgehängt. Nach einiger Zeit war es wieder da. Der Programmiervorgang hat aber funktioniert. Ansonst super Programm! Sg Simon
Simon schrieb: > kann man einen Adressoffset angeben? Nein, wieso und wofür? Sowohl in einer Hex Datei als auch in einer Motorola Datei stehen die absoluten Adressen drin. Das reicht doch aus, um jeglichen Code präzise zu positionieren. Allenfalls könnte ich mir sowas für eine reine Binärdatei vorstellen, wo ja keinerlei Adressierung enthalten ist. Hab sowas aber bislang nicht eingebaut. Ansonsten noch eine Anmerkung von mir: Warum bloß binden hier so viele Leute ihren Code auf 0x0800:0000 ? Das ist der Bereich, auf dem der Flash zum Programmieren erreichbar ist. Aber ein Cortex erwartet sein Zeugs ab Adresse 0 und deshalb kann man seinen ganzen Code ab Adresse 0 linken, denn der Bereich von 0x0800:0000 erscheint gleichermaßen im Adressbereich 0x0000:0000, von wo aus er ohne jegliche Probleme ausgeführt werden kann. Nochwas: Beim Testen von Verbindung und Chip sucht das Programm in seiner Liste der Chips nach der ID des Chips. Die ID's stammen von ST's "Demonstrator" und ich erinnere mich duster, an manchen Stellen schon Doppelbelegungen gesehen zu haben. Ich hatte nicht ohne Grund geschrieben, diese Liste zu editieren, und alles, was man nicht braucht einfach rauszuschmeißen. W.S.
W.S. schrieb: > Warum bloß binden hier so viele Leute ihren Code auf 0x0800:0000 ? Weil das in den Linkerscripten von ST auch schon so drinsteht Dies wiederum vermutlich, um die ganzen Anfragen zu ersparen, die entstünden, wenn man zwar ab Adresse 0 linkt, aber dieses Image dann ab 0x08000000 zu flashen ist. Zudem ist es auch denkbar, daß nicht alle Toolchains beim Hexfile-Export so gut klarkommen, wenn die Linkadresse eine andere als die Flashadresse ist.
Nop schrieb: > Zudem ist es auch denkbar, daß nicht alle Toolchains beim Hexfile-Export > so gut klarkommen, wenn die Linkadresse eine andere als die Flashadresse > ist. Ist für mich nicht denkbar, denn da gibt es nicht allzuviele Toolchains, die für Cortexe den Code erzeugen. Was haben wir denne? Keil, IAR, GCC und das war's schon fast. FPC erzeugt Win32 Format oder nur ELF. Evtl. noch Mikroe. Sonst noch was? Und ja, der GCC baut bei der Ausgabe von Intel-Hex einen Bockmist dahingehend, daß er das nur für den Intel 8086 vorgesehene CS:IP Modell benutzt. Dabei gibt es EXTRA für 32 Bit Plattformen das passende Modell auch im Intel-Hex-Code. Aber das berührt deine Bedenken gar nicht. Siehe Diskussion weiter oben im Thread. W.S.
W.S. schrieb: > Der Hintergrund ist ganz einfach, daß man als J-Link-Edu Besitzer ja > leider auf J-Flash verzichten muß Dafür gibts den Commander, da kann man bequem aus ner Batchdatei heraus flashen.
W.S. schrieb: > Und ja, der GCC baut bei der Ausgabe von Intel-Hex einen Bockmist Und 0x08000000 ist oberhalb des 1MB-Adreßraums, beginnt quasi ab 128 MB. Damit umgeht man eventuell das Problem. Ich lasse mir das beim GCC sowieso als Bin ausgeben und habe dahinter noch eine eigene Toolchain, um s_record nicht benutzen zu müssen. Aber der Kern ist wohl, daß es in den Linkerfiles von ST auch schon so ist. Es funktioniert auch beides gleichermaßen, auch von der Ausführungsgeschwindigkeit her. Allenfalls wäre ein Nachteil des Linkens zu 0x08000000, daß man das zum Debuggen nicht ins RAM legen kann (zusammen mit Boot0/Boot1). Aber das ist ja ohnehin nur eine Option, wenn man so wenig Code und Data hat, daß das alles zusammen noch ins RAM paßt.
W.S. schrieb: > Warum bloß binden hier so viele Leute ihren Code auf 0x0800:0000 ? weil man dann die unteren 128MB mittels MPU komplett ausblenden kann und NULL-Pointer fangen kann. Wenn ST das Flash bei 0 eingebaut hätte, würde ich für den Zweck 64k (oder so) Flash verschenken. Pascal-Programmierer kennen sowas natürlich nicht ;) Außerdem finde ich es natürlicher und übersichtlicher, wenn die Adressen beim Linken, beim Flashen und zur Laufzeit immer gleich sind.
W.S. schrieb: > Warum bloß binden hier so viele Leute ihren Code auf 0x0800:0000 Warum sollten sie nicht, was spricht dagegen? Beim Flashen mit J-Link gibts einen Fehler wenn man versucht direkt nach 0x0 zu flashen, also wenn man eh nach 0x8000000 flashen muß warum soll man dann nicht auch direkt dorthin linken? Dann kommt auch ein hex oder ein srec raus das direkt dort hin geflasht werden will wohin es auch gelinkt worden ist und alles funktioniert sofort und ohne irgendwelche Handstände.
gibt es eine Möglichkeit den Quellcode zu bekommen für Anfänger?
Gegeg J. schrieb: > warum grrr? > ich hatte als mini mauis gefragt eben darum. Mit wievielen Namen bist du eigentlich in diesem Forum unterwegs? Ich kann ja ne Menge verstehen, aber manches verwirrt denn doch. W.S.
Hallo, Gute Arbeit, bei mir funktioniert das Tool ohne Probleme (STM32F72X). Mich würde auch der Quellcode interessieren. Könntest du ihn mir bitte senden? Danke f.glaser19@protonmail.com
naja, wäre ja nett, wenn da wenigstens mal ne Empfangsbestätigung käme. W.S.
Konnte ich nie senden, da nie was angekommen ist:-( Also bei svkgroup@freenet.de
Hallo, Echt genial das Program. Ich habe die letzten Tagen nicht wirklich das STM Software programmieren können. Bei mir funktioniert nach Änderung der targets.cfi das Tool mit STM32L011x4 auch. Mich würde auch der Quellcode interessieren ;-). Könntest du ihn mir bitte senden? Merci alonso3786@gmail.com
Peter Pander schrieb: > Konnte ich nie senden, da nie was angekommen ist Naja, auch wenn das mittlerweile lang her ist: es macht offenbar einen Unterschied, ob man das Ganze an f.glaser19@protonmail.com oder an svkgroup@freenet.de schickt. Gelle? W.S.
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.