Sicherlich bekomme ich hier wieder "haue", weil ich keinen Code poste bei meinem Problem. Allerings bin ich zu wirklich 100% sicher, dass es am Programmcode nicht liegt (Code posten wäre etwas schwierig, weil ich zum einen mit libopencm3 hantiere und oberhalb der Library meinen eigenen "Abstraktionslayer" darüber gesetzt habe). Folgendes: ich habe hier 2 Blackpill liegen, einer ist mit einem F411 bestückt, der andere mit einem F401. Zudem habe ich für Referenzzwecke ebenfalls je ein Nucleoboard mit F401 und F411. Um zu evaluieren wie ich mit den Blackpills umgehen kann gibt es natürlich ein einfaches Blinkprogramm (dachte ich). Nun zeigt sich folgendes Szenario: Mein Blinkprogramm funktioniert auf der Blackpill mit F411 sofort. Bei dem mit F401 blinkt es nicht, der Flashspeicher läßt sich aber fehlerlos beschreiben, sowohl mittels DFU-UTIL als auch mit ST-LINK V2. Auf dem F401 Nucleo-Board blinkt das Programm, das ich auf die F401-Blackpill geschoben habe (weshalb ich schlicht ausschließe, dass das am Programm liegen kann). Ist hierüber etwas bekannt? Gibt es eine Besonderheit mit der F401 Blackpill die ich nicht kenne oder ist das Teil einfach nur defekt (und ich kann es getrost in die Tonne treten und eine neue F401 Pille bestellen)?
Beim Nucleo kommt der Takt vom internen ST-Link - Das Blackpill hat einen Quarz. 1:1 übertragen wird also nicht gehen.
Harry L. schrieb: > Beim Nucleo kommt der Takt vom internen ST-Link - Das Blackpill hat > einen Quarz. > 1:1 übertragen wird also nicht gehen. Natürlich sollte das gehen, denn zum einen kann die Blackpill auch internen Takt, zum anderen geht das 1:1 beim F411 Nucleo und bei der Blackpill. Außerdem habe ich meinen Nucleo-Boards einen externen Quarz spendiert. Zudem: mein eigener Layer oberhalb der libopencm3 sieht so etwas vor: sys_init(MHZ96,intern_clock);
W.S. schrieb: > Hast du deine LED auch richtig herum und an das richtige Bein angelötet? > > W.S. Die Frage ist nicht wirklich ernst gemeint, oder? Zum einen geht auch die Onboard-LED nicht und zum anderen war ich an den GPIO-Pins auch mit dem Scope... alles low!
Ralph S. schrieb: > sys_init(MHZ96,intern_clock); natürlich geht es auch mit: sys_init(MHZ84, intern_clock); nicht! Die 96MHz waren ein Copy-Paste Fehler... sorry
Ralph S. schrieb: > Bei dem mit F401 blinkt es nicht, der Flashspeicher läßt sich aber > fehlerlos beschreiben, sowohl mittels DFU-UTIL als auch mit ST-LINK V2. Nun, die SWD-Schnittstelle dient nicht nur zum Programmieren des Flashs, sondern auch wunderbar als Debug-Schnittstelle ... Also einfach mal Nachschauen (statt Raten), was die CPU da so treibt, ob Oszillator läuft, wie der Port konfiguriert ist etc. ;-)
Ralph S. schrieb: > Die Frage ist nicht wirklich ernst gemeint, oder? Also, wenn ich hier sehen muß, daß manche Autoren selbst für blinky den Debugger benötigen, weil sie sonst auf dem Schlauch stehen, dann sehe ich sowas recht ernst, weil mir sonst vom vielen Kopfschütteln zu schwindlig wird. W.S.
Da war was mit Fakes der WeAct F401 Boards, F401CC vs. F401CE. https://github.com/WeActTC/MiniSTM32F4x1 Ich habe F411 und F401 als Mbed custom targets gebaut, laufen beide. 401CE und F401CC haben unterschiedlich viel RAM, was natürlich im Linkerscript beachtet werden muss.
W.S. schrieb: > Also, wenn ich hier sehen muß, daß manche Autoren selbst für blinky den > Debugger benötigen, weil sie sonst auf dem Schlauch stehen, dann sehe > ich sowas recht ernst, weil mir sonst vom vielen Kopfschütteln zu > schwindlig wird. > > W.S. Geh deine Betty hegen & pflegen und hör auf hier rumzustänkern. Seit Jahren immer die gleiche Litanei von dir.
Kann es sein, das es von dem Blackpill 401 unterschiedliche Versionen gibt? Zumindest haben die Blackpill STM32F401CC und die Nucleo den STM32F401RE. Evtl kommt da der Unterschied her?
W.S. schrieb: > Also, wenn ich hier sehen muß, daß manche Autoren selbst für blinky den > Debugger benötigen, weil sie sonst auf dem Schlauch stehen, dann sehe > ich sowas recht ernst, weil mir sonst vom vielen Kopfschütteln zu > schwindlig wird. > > W.S. Also wenn ich hier W.S. Leute sehe, die selbst für 3mm Löcher eine Bohrmaschine brauchen und nicht wie alle anderen die Handkurbel oder einen Nagel nehmen, dann sehe ich das auch ernst...
W.S. schrieb: > manche Autoren selbst für blinky den > Debugger benötigen Ich finde es ja eher bedenktlich das man nur wegen dem kleinen Kompfortgewinn in Hochsprachen schreibt oder Libs verwendet. Nur was man selbst, natürlich in ASM, gecoded hat, darf auf das System. Auch die neumodischen Flash Speicher sind mir unsympathisch. Was war an den Eproms auszusetzen? Da musste ich auch nicht einen neumodischen Programmer verwenden sonder konnte direkt mit dip switches Adress + Data einstellen und jede Speicherstelle per Hand beschreiben. Und mit externen Speicher brauche ich auch keinen Debugger, sondern nur noch LEDs an A0-15 und D0-7 + Einzelschrittbetrieb am Clk. Mehr als 8bit ist ohnehin Quatsch, denn wer will den sonst diese Datenmengen noch per Hand von ASM in Hex übersetzen und manuel ins Eprom tackern. Deswegen sind die 4bit Prozessoren eigentlich auch der Höhepunkt der Mikrocontrolertechnik gewesen. Beim 8085 bin ich ja noch mitgegangen. Der hatte nix, konnte nix und war arschlangsam, also leicht zu behersschen und nicht viel zu lernen. Debugger sind erst durch diese eklatanten Fehlentwicklung nötig geworden. Der ganze Quatsch ist viel zu komplex geworden. Mehrere Kerne, viele konkurrierende Prozesse, massive Libs und RTOS die ich alle nicht selbst geschrieben habe, kann mir die Recourcen fürs Deugging nicht einfach nehmen und wenn die SW irgendwo stoppt, kenn ich nicht den Zustand der internen Register. Wirklich brauchen tut man den Debugger nie. Man kann auch ewig Code Review machen, Pin oder uart debugging oder stumpfes try and error. Oder man ignoriert das es ein Problem gibt, weil man es nicht greifen kann. Ein Debugger ist praktisch und man gewöhnt sich schnell an den Kompfort. Nur die Einstellung das jemand der ein Tool nutzt um schneller und effizenter zu werden, weil es einfach da ist, fast nix kostet und unzählige Möglichkeiten bietet, ist schon echt schwach für einen technikaffinen Menschen. Denn eigentlich bist Du ja nicht gegen Debugger. Du sagt nur 'Seht alle her wie gut ich bin, das ich den nicht brauche' Und Du sagst: 'Ich mache das so wie ich es immer gemacht habe, weil ich zu unflexibel bin wenigstens mal auszuprobieren was ich an neuen Möglichkeiten dazugewinnen würde' Ausserdem: 'Ich habe ein angeknackstes Ego, denn ich muss zwanghaft die Leistung anderer schmälern, die Dinge anders als ich machen, weil ich nicht anerkennen kann das auch deren Weg zum Ziel führt und das vielleicht sogar schneller als meiner, wenn ich mal einen Fehler suchen muss'
Johannes S. schrieb: > 401CE und F401CC haben unterschiedlich viel RAM, was natürlich im > Linkerscript beachtet werden muss. 401CE: 512 kByte Flash / 96 kByte RAM 401CC: 256 kByte Flash / 64 kByte RAM stm32f401cc.ld
1 | MEMORY |
2 | {
|
3 | ram : ORIGIN = 0x20000000, LENGTH = 64K |
4 | rom : ORIGIN = 0x08000000, LENGTH = 256K |
5 | } |
6 | |
7 | INCLUDE libopencm3_stm32f4.ld |
An diese Sache hatte ich natürlich gedacht und jetzt passiert etwas hoch merkwürdiges: Gebe ich für ram im Linkerscript eine Länge von LENGTH = 32k an, funktioniert das Blinkprogramm (und andere Programme auch, die den Ram nicht in der Menge benötigen). -------------------------------------- Um das aufzuzeigen, hier die Ausgaben des Makes (mit einem Linkerscript für 32 kByte, ja ich weiß, dass es keinen F4 mit nur 32 k gibt):
1 | arm-none-eabi-gcc -std=gnu99 -Wall -Os -g -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=harc |
2 | make -C ../lib/libopencm3 |
3 | make[1]: Verzeichnis „/home/mcu/programming/stm32f4xx/lib/libopencm3“ wird betreten |
4 | GENHDR include/libopencm3/stm32/f4/irq.json |
5 | BUILD lib/stm32/f4 |
6 | make[2]: Für das Ziel „all“ ist nichts zu tun. |
7 | make[1]: Verzeichnis „/home/mcu/programming/stm32f4xx/lib/libopencm3“ wird verlassen |
8 | arm-none-eabi-gcc -std=gnu99 -Wall -Os -g -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hars |
9 | arm-none-eabi-objcopy -O binary blinky.elf blinky.bin |
10 | arm-none-eabi-size blinky.elf 1>&2 |
11 | text data bss dec hex filename |
12 | 1576 12 4 1592 638 blinky.elf |
und hier dann der Flashvorgang mittels ST-Link:
1 | st-flash write blinky.bin 0x8000000 |
2 | st-flash 1.6.0-301-gd11e6f4-dirty |
3 | 2022-02-22T16:38:06 INFO common.c: F4xx (low power): 64 KiB SRAM, 256 KiB flash in at least 16 KiB . |
4 | file blinky.bin md5 checksum: 7dddef28f15aba7c613136e9ff418a, stlink checksum: 0x0001d099 |
5 | 2022-02-22T16:38:06 INFO common.c: Attempting to write 1588 (0x634) bytes to stm32 address: 1342177) |
6 | Flash page at addr: 0x08000000 erased |
7 | 2022-02-22T16:38:07 INFO common.c: Finished erasing 1 pages of 16384 (0x4000) bytes |
8 | 2022-02-22T16:38:07 INFO common.c: Starting Flash write for F2/F4/L4 |
9 | 2022-02-22T16:38:07 INFO flash_loader.c: Successfully loaded flash loader in sram |
10 | enabling 32-bit flash writes |
11 | size: 1588 |
12 | 2022-02-22T16:38:07 INFO common.c: Starting verification of write complete |
13 | 2022-02-22T16:38:07 INFO common.c: Flash written and verified! jolly good! |
Deutlich zu sehen, dass der Chip schon als 256 kByte Flash / 64 kByte Ram erkannt und auch geflasht wird. Allerdings mit einem Linkerscript bei der Codeerzeugung auf 32 kByte begrenzt war. Natürlich gehe ich jetzt mal auf die Suche in meiner modifizierten libopencm3 Umgebung, kann mir das allerdings nicht erklären (außer, dass Teile des Rams tatsächlich defekt sind). Ich werde einfach eine weitere Blackpill bestellen und sehen, wie die sich verhält.
Ralph S. schrieb: > außer, dass Teile des Rams > tatsächlich defekt sind Schreib doch einen kleinen ram check.
oder mit dem STMCubeProgrammer checken, der kann auch einfach Speicherbereiche anzeigen und ändern.
Abschluß des Threads: Ich habe jetzt eine neue BlackPill mit STM32F401CC erhalten und natürlich sofort ausprobiert und diese BlackPill funktioniert so, wie sie soll, natürlich auch dann, wenn im Linker-Script die vollen 64 kByte angegeben sind. Also gehe ich davon aus, dass meine erste BlackPill schlichtweg einen Defekt im Ram hat und aus diesem Grunde geht sie den Weg allen irdischen: Ab in die Tonne ! Gruß Ralph
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.