Ich setze jetzt meine Gehversuche mit dem STM32-F407-DIYMORE Board fort.
Jetzt gewappnet mit einem BMP-geflashten Blue Pill Board.
Frage zuerst: es genügt doch, wenn ich das DIYMORE-Board mit 3,3V vom
Blue Pill Board aus versorge, brauche doch die 5V nicht, oder?
Meine gdb Session hänge ich mal an.
Im .gdbinit steht im Moment:
Was mich wundert, ist, daß da bei 0x0 und folgende, kein 0xffffffff
stehen.
Was auch immer ich lade (load), es steht dieses Gemüse da, nicht der
Reset-Vektor und SP. Was mache ich falsch?
(zum Vergleich mal: NucleoBoard F411RE angeschlossen über on Board
ST-LINK und gdb mit OpenOCD gestartet). No Prob.
Christoph K. schrieb:> Frage zuerst: es genügt doch, wenn ich das DIYMORE-Board mit 3,3V vom> Blue Pill Board aus versorge, brauche doch die 5V nicht, oder?
... und schon geht es wieder los mit Sparen koste es was es wolle.
Von Abblock-Kondensatoren wollen wir bei dieser Attitude erst gar
nicht reden. Denn das ist immer nur unnützer Ballast der Geld kostet.
Weiter so. Das gibt wieder ein unterhaltsames Feuilloton zum Mitlesen
und Amüsieren.
Stefan ⛄ F. schrieb:> Christoph K. schrieb:>> Target voltage: 3.06V>> Hast du deinen Spannungsregler oder das USB Kabel überlastet?
Ich fand nie, daß diese angezeigten Spannungen etwas mit der Realität zu
tun haben. Warum, weiß ich nicht. Irgendwas in der BMP Soaftware mißt ja
die Spannung. Messe ich die 3,3V direkt am Board, so liegen da 3,30V an.
pegel schrieb:> Wieso 0x0?> Flash beginnt bei 0x08000000.
Beispiel:
1
ProgramreceivedsignalSIGINT,Interrupt.
2
0x00001516inserial_qkey()
3
(gdb)x/10x0
4
0x0:0x200003300x0000398f0x000037cf0x000037cf
5
0x10:0x000037cf0x000037cf0x000037cf0x00000000
6
0x20:0x000000000x00000000
7
(gdb)c
8
Continuing.
Nach meinem Verständnis liegt zwar das Flash gemappt nach 0x08000000,
aber innerhalb des Adressraums des Programms sind die Adressen relativ
zu 0x00000000. So zeigt der Reset-Vektor auch nicht auf 0x0800398f,
sondern auf 0x0000398f. Und gdb arbeitet auch im logischen Adressraum.
Im Falle meine mit OpenOCD und gdb gedebuggten Programms sieht's ja auch
richtig aus.
Mit BMP habe ich nocht nicht das gewünschte Bild.
Christoph K. schrieb:> Nach meinem Verständnis liegt zwar das Flash gemappt nach 0x08000000,> aber innerhalb des Adressraums des Programms sind die Adressen relativ> zu 0x00000000.
Anders herum. Der Flash Speicher beginnt an Adresse 0x0800 0000 und wird
auf Adresse 0x0000 0000 gemappt. Wenn du vom RAM bootest (macht beim
Debuggen Sinn) wird das RAM von 0x2000 0000 nach 0x000 0000 gemappt.
Ich frage mich manchmal, mit welcher Attitüde manche Leute wie Du hier
unterwegs sind. Was soll das?
Man sollte den Gästemodus hier abschaffen (wie man es auch in Leo.org
vor einiger Zeit gemacht hat).
So sehr ich die Expertise vieler Beiträger hier in den Foren schätze,
aber auf internationalen (engl.) Foren geht es weitaus seriöser zu. Zum
- geringen - sachlichen Gehalt Deines Einwandes:
Du meinst also im Ernst, ich wolle irgendwas sparen? Die
Abblockkondensatoren sind doch in der Schaltung eh vorhanden. Vorschrift
bei der Beschaltung des STM32Fxx ist ohnehin, daß sich nah am Chip ein
keramischer Abblockkondensator vorgeschriebener Dimensionierung zu
befinden hat. Also spare ich gar nichts, da alles vorhanden ist. Mehr
sag' ich dazu jetzt nicht. Dein Beitrag disqualifiziert sich von selbst.
Stefan ⛄ F. schrieb:> Christoph K. schrieb:>> Nach meinem Verständnis liegt zwar das Flash gemappt nach 0x08000000,>> aber innerhalb des Adressraums des Programms sind die Adressen relativ>> zu 0x00000000.>> Anders herum. Der Flash Speicher beginnt an Adresse 0x0800 0000 und wird> auf Adresse 0x0000 0000 gemappt. Wenn du vom RAM bootest (macht beim> Debuggen Sinn) wird das RAM von 0x2000 0000 nach 0x000 0000 gemappt.
Richtig, hatte mich falsch ausgedrückt. Aber was sieht gdb oder zeigt
gdb auf 0x0 an?
zu den Spannungen: was für ein Regler ist in dem XTW? Ich benutze da
lieber die 5V die aus dem Adapter kommen, die sind belastbarer und der
Regler vom Targetboard wird benutzt.
Die 3,x V Anzeige könnte man noch durch Anpassen des Umrechnungsfaktors
genauer machen, aber das ist ja nur Kosmetik. Da das XTW ja doch keine
Treiber hat braucht es auch es keine externe VTarget.
Das Addressmapping passiert im CPU core soweit ich weiss. Das kann von
CPU zu CPU verschieden sein, muss man im Datenblatt checken. Der H7 hat
z.B. auch verschiedene Adressbereiche und einige liegen aus
Debuggersicht auf anderen Adressen.
pegel schrieb:> was sagt denn:>> (gdb): x /10x 0x08000000
Habe den Grund gefunden. Hatte zwei verschiedene Images (.elf) und die
memmap des einen (nicht funktionierenden) sah so aus:
1
MEMORY
2
{
3
rom(RX):ORIGIN=0x08000000,LENGTH=0x4000
4
ram(WAIL):ORIGIN=0x20000000,LENGTH=0x4000
5
}
6
7
SECTIONS
8
{
9
.text:{*(.text*)}>rom
10
.bss:{*(.bss*)}>ram
11
}
Die des anderen:
1
MEMORY
2
{
3
rom(RX):ORIGIN=0x00000000,LENGTH=0x4000
4
ram(WAIL):ORIGIN=0x20000000,LENGTH=0x4000
5
}
6
7
SECTIONS
8
{
9
.text:{*(.text*)}>rom
10
.bss:{*(.bss*)}>ram
11
}
Aber eigentlich wäre doch 0x00000000 richtig, oder?
bei meinen Programmen wird immer auf Adresse 0x08000000 als Start
geflasht, es stört mich auch nicht das ich den Reset Vektor auf dieser
Adresse sehe.
Abhängig von den Boot Pins kann aber auch RAM oder eine FSMC Bank auf
0x0 gemappt werden.
Christoph K. schrieb:> Aber eigentlich wäre doch 0x00000000 richtig, oder?
Vielleicht kann man den Flash über die gemappte Adresse ab 0x000 0000
nur lesen (war nur geraten).
1. Bild zum Chip des DIYMORE-Boards
2. Bild möglicher 3,3V Wandler auf dem XTW (S2SL?)
Jetzt hat es erstmalig geklappt.*
(gdb) load
Loading section .text, size 0x3b80 lma 0x0
Start address 0x3a0e, load size 15232
Transfer rate: 118 KB/sec, 952 bytes/write.
(gdb) x /10x 0
0x0: 0x20000330 0x00003a0f 0x0000384f 0x0000384f
0x10: 0x0000384f 0x0000384f 0x0000384f 0x00000000
0x20: 0x00000000 0x00000000
*) aber nur, weil ich im Versuch die Randbedingungen verändert habe, was
man nie machen sollte. Ich habe ja seit gestern auch einen zweiten XTW
ST-LINK V2, den ich natürlich sofort - weil in Übung - mit den
BMP-Binaries geflasht habe.
Dachte, die wären somit austauschbar, aber mitnichten. Der Erstere
(schwarzes Eloxalgehäuse) funktioniert (s.o.), der zweite im rostbraunen
Gehäuse funktioniert nicht richtig.
Vielleicht werde ich ihn noch mal flashen. Soweit bisher.
Christoph K. schrieb:> Ich habe ja seit gestern auch einen zweiten XTW> ST-LINK V2, den ich natürlich sofort - weil in Übung - mit den> BMP-Binaries geflasht habe.>> Dachte, die wären somit austauschbar, aber mitnichten. Der Erstere> (schwarzes Eloxalgehäuse) funktioniert (s.o.), der zweite im rostbraunen> Gehäuse funktioniert nicht richtig.
Vermutlich andere Hardware. Genauso wie die BMP-Firmware kann auch die
ST-Link-Firmware praktisch beliebige GPIO für die Kommunikation mit dem
Target benutzen. Die Firmware muß dann natürlich zur Hardware passen.
Bei diesen ST-Links im Format eines USB-Sticks kann man von außen nicht
sehen, was genau drin ist. Da muß man schon etwas genauer nachsehen.
Axel S. schrieb:> kann auch die ST-Link-Firmware praktisch beliebige GPIO> für die Kommunikation mit dem Target benutzen.
Ich konnte meine ST-Link Klone immer problemlos mit der Software von ST
aktualisieren. Daher nehme ich an, dass die Pinbelegung bei allen die
gleiche sein sollte.
> Die Firmware muss dann natürlich zur Hardware passen.
Eben deswegen.
Nachdem ich jetzt mit GDB/OpenOCD ein Stück weitergekommen bin (Anschluß
des NRST Signals der SWD Schnittstelle) frage ich mich, wie das mit
blackmagic und blue pill aussieht. Wo schließt man da den NRST an?
Christoph K. schrieb:> Wo schließt man da den NRST an?
Na an den Reset Eingang, wo denn sonst?
Und ja, der fehlt an der Seitenleiste. Und ja, das führt regelmäßig zu
Schwierigkeiten.
Frag mich nicht, warum, ich habe mir das nicht ausgedacht. Die TraceSWO
Leitung fehlt auch.
Stefan ⛄ F. schrieb:> Christoph K. schrieb:>> Wo schließt man da den NRST an?>> Na an den Reset Eingang, wo denn sonst?>> Und ja, der fehlt an der Seitenleiste. Und ja, das führt regelmäßig zu> Schwierigkeiten.>> Frag mich nicht, warum, ich habe mir das nicht ausgedacht. Die TraceSWO> Leitung fehlt auch.
Ich meinte nicht das Target, ich meinte die Blue Pill.
Christoph K. schrieb:> Ich meinte nicht das Target, ich meinte die Blue Pill.
Und ich meine, das Blue Pill Board als Target. Drücke dich klarer aus!
Wenn du das Blue Pill Board als Debugger verwendest, dann schreibe das
auch. In diesem Fall bestimmt die Software, welcher Pin als
Reset-Ausgang verwendet wird. Das muss wohl irgendwo im Quelltext
stehen.
Stefan ⛄ F. schrieb:> Christoph K. schrieb:>> Ich meinte nicht das Target, ich meinte die Blue Pill.>> Und ich meine, das Blue Pill Board als Target. Drücke dich klarer aus!>> Wenn du das Blue Pill Board als Debugger verwendest, dann schreibe das> auch. In diesem Fall bestimmt die Software, welcher Pin als> Reset-Ausgang verwendet wird. Das muss wohl irgendwo im Quelltext> stehen.
Titel des Threads?
Christoph K. schrieb:> Titel des Threads?
Der ist genau so zweideutig.
a) Mit GDB und BlackMagic ein Blue Pill Board programieren?
b) Mit GDB und BlackMagic auf einem Blue Pill Board etwas
programieren?
Stefan ⛄ F. schrieb:> Christoph K. schrieb:>> Titel des Threads?>> Der ist genau so zweideutig.>> a) Mit GDB und BlackMagic ein Blue Pill Board programieren?> b) Mit GDB und BlackMagic auf einem Blue Pill Board *etwas*> programieren?
Für mich absolut eindeutig. Wenn wir schon einen Exkurs in die Grammatik
veranstalten wollen: Du übersiehst das Objekt:
<Akkusativ Objekt>: STM32-F407-DIY-MORE
<Subjekt(substantiviertes Verb)>: programmieren
<Adverbiale Ergänzung>:mit gdb und blackmagic blue pill
Wen oder was? STM32...
Was: programmieren
Mittels: gdb und bmp bp
Weder Dein a) noch b) lassen sich aus dem Titel herleiten
Christoph K. schrieb:> Ich setze jetzt meine Gehversuche mit dem STM32-F407-DIYMORE Board fort.> Jetzt gewappnet mit einem BMP-geflashten Blue Pill Board.>> Frage zuerst: es genügt doch, wenn ich das DIYMORE-Board mit 3,3V vom> Blue Pill Board aus versorge, brauche doch die 5V nicht, oder?>> Meine gdb Session hänge ich mal an.
Was hast du eigentlich vor?
Du hast noch keinerlei Plan, wie du dein Dingsda-Board mit Strom
versorgen willst, aber du hängst erstmal ein ellenlanges Debug-Protokoll
an.
Kriegst du denn wenigstens deine selbstgeschriebene Firmware in den µC
deines Boards hinein - oder nicht?
Ich würde dir empfehlen, zuerst die Versorgung deines Brettl's zu
erledigen.
Dann schreibst du deine Firmware.
Dann versuchst du, selbige in deinen µC zu programmieren - egal wie:
ST-Link, J-Link, Bootlader, sonstige Programmieradapter.
Dann schaust du, ob und wie sich deine Firmware benimmt. Entweder toter
Mann oder Vollfunktion oder irgend etwas dazwischen.
Dann kannst du immer noch überlegen, was da klemmen könnte und wie du es
flott kriegst.
W.S.
W.S. schrieb:> Christoph K. schrieb:>> Ich setze jetzt meine Gehversuche mit dem STM32-F407-DIYMORE Board fort.>> Jetzt gewappnet mit einem BMP-geflashten Blue Pill Board.>>>> Frage zuerst: es genügt doch, wenn ich das DIYMORE-Board mit 3,3V vom>> Blue Pill Board aus versorge, brauche doch die 5V nicht, oder?>>>> Meine gdb Session hänge ich mal an.>>> Was hast du eigentlich vor?>> Du hast noch keinerlei Plan, wie du dein Dingsda-Board mit Strom> versorgen willst, aber du hängst erstmal ein ellenlanges Debug-Protokoll> an.
Die Frage nach der Versorgung via 3.3V war ja nicht grundsätzlicher oder
essentieller Natur sondern eine rein akademische Frage.
Versorgen kann ich das Board über die USB-Schnittstelle mit der
Langzeitperspektive, auch über die USB-Schnittstelle vielleicht mal eine
VCOM in die Firmware hinein zu betreiben.
Aber primär geht es mir darum, das mecrispstellaris-Forth, das ich
erfolgreich in ein stm32F407-DISC1 board geflasht habe, auch in dieses
stm32-f407-DIYMORE board zu flashen. Ich habe den UART angepaßt an
USART1 an PA09/P10, aber das Programm loopt noch irgendwo in der
Initialisierung. Leider macht es auch solche Dinge, wie den Flash
rückwärts nach 0xffff zu durchsuchen um einen freien Bereich zu finden
(weil im Betrieb auch neue FORTH-Worte in den Flash geschrieben
werden). Muß wohl noch mal mit dem Autor Kontakt aufnehmen.
Die mecrispstellaris-forth Portierungen basieren alle auf .BIN files und
der dazugehörige memmap-File mappt rom auf 0x00000000 (wo meine
initialen Verständnisprobleme herrührten). Ich wunderte mich, warum die
BIN files
mit der Adresse 0 klarkommen, während der .ELF File da eine 0x08000000
braucht.
>> Kriegst du denn wenigstens deine selbstgeschriebene Firmware in den µC> deines Boards hinein - oder nicht?
Sowohl das komplette FORTH kriege ich hinein wie auch meine
Minimalst-Programme.
Ich bin nur auf dem Wege dahin auf viele interessante Nebenschauplätze
gestoßen, die mein Interesse weckten, wie z.B. die mit bmp
umprogrammierten STLINK-V2 USB sticks und die mit bmp geflashten blue
pills.
>> Ich würde dir empfehlen, zuerst die Versorgung deines Brettl's zu> erledigen.> Dann schreibst du deine Firmware.> Dann versuchst du, selbige in deinen µC zu programmieren - egal wie:> ST-Link, J-Link, Bootlader, sonstige Programmieradapter.> Dann schaust du, ob und wie sich deine Firmware benimmt. Entweder toter> Mann oder Vollfunktion oder irgend etwas dazwischen.> Dann kannst du immer noch überlegen, was da klemmen könnte und wie du es> flott kriegst.>> W.S.
Grüße
Chrstoph
Thread beobachten
Seitenaufteilung abschalten