STM32Fxxx Bootlader Programmer STM32Prog

Windows-App versus Kommandozeilen-Tool.
Überleg dir selbst, was du lieber magst.

W.S.

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..)

Hier noch ein Bild des Verbindungstests..

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.

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.

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.

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 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.

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:

> 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.

gibt es eine Möglichkeit den Quellcode zu bekommen für Anfänger?

Hast du ne email-Adresse?
W.S.

svkgroup@freenet.de

Gegeg J. schrieb:
> (cdfgdfgdfhsdklklk)
grrr...

warum grrr?
ich hatte als mini mauis gefragt

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.