Ich habe einen Metalldetektor nachgebaut, link zu der Beschreibung ist hier: http://fandy.ucoz.org/publ/metalloiskatel_quot_kvazar_quot_quot_quasar_quot/metalloiskatel_quot_quasar_arm_quot/2-1-0-5 Ich kennen mich mit den ARMsen nicht gut aus, irgendwie muss ja das Hexfile da drauf. Probiert habe ich es mit einem ST Discovery Board darauf ist eine SWD Schnittstelle, die habe ich an die SWD Schnittstelle von den Quasar Board angeschlossen. Zusätzlich habe ich den Resetpin vom ARM (Pin7) an die SWD Schnittstelle angeschlossen. Mit dem ST Link Utility ließ sich dann das Hexfile übertragen, das Programm sagt: 16:46:38 : Connected via SWD. 16:46:38 : Connection mode : Normal. 16:46:38 : Debug in Low Power mode enabled. 16:46:38 : Device ID:0x410 16:46:38 : Device flash Size : 64KBytes 16:46:38 : Device family :STM32F10xx Medium-density 16:47:16 : Memory programmed in 14s and 446ms. 16:47:16 : Verification...OK 16:47:16 : Programmed memory Checksum: 0x00A1E7CE Sollte also funktioniert haben, aber das Ding geht nicht an. Eigentlich hätte ich ein Piepton erwartet und eine Anzeige im Display. Muss ich da noch irgendwas beachten? Bei den AVR gibt es ja die Fuses die er für die Taktraten braucht, gibt es hier sowas auch?
Gast
#4974563
Ich gehe davon aus das du die Jumper auf dem Discovery richtig gesetzt hast. Probier doch einfach eine frühere Version vom hex, sind ja genug da. Gibts auch einen Quelltext dazu?
Sourcecode gibt es leider keinen, daher bin ich auf die Hexfiles angewiesen. Ich hab das Teil immer noch nicht zum laufen gebracht. Laut dem ST Tool funktioniert die Programmierung, allerdings habe ich das Gefühl, dass der Chip nicht startet. Keine Signale an irgendwelchen Pins feststellbar. Am Quarz kann ich mit dem Oszi ein Sinus erkennen, ansonsten nix. Gibt es da sonst noch was ARM typisches zu beachten, muss ich dem irgendwie seine Taktquelle erklären oder geschieht das alles in dem Programm?
zu .bin wandeln dann flashen
Fred F. schrieb: > Ich habe einen Metalldetektor nachgebaut, > ... > Sollte also funktioniert haben, aber das Ding geht nicht an. Bist Du sicher, dass die Hardware in Ordnung ist?
Wandeln? Ich habe gerade mal ein Hexfile in .bin umbenannt, damit moppert das Tool rum , da das File zu groß ist. 181KB hat so ein Hex File. Der Chip ist ein STM32F100C8T6.
Dietrich L. schrieb: > Bist Du sicher, dass die Hardware in Ordnung ist? Das LCD ist umgebaut auf 3.3V betrieb, getestet an einen AVR läuft. Die Lötstellen sehen sauber aus (mit Lupe kontrolliert). Spannungsversorgung funktioniert. Der IC lässt sich ja auch beschreiben, aber es tut sich halt nix.
Fred F. schrieb: > Wandeln? Ich habe gerade mal ein Hexfile in .bin umbenannt, damit > moppert das Tool rum , da das File zu groß ist. 181KB hat so ein Hex > File. Der Chip ist ein STM32F100C8T6. umbenennen bringt nix,
1 | |
Sorry, ich verstehe nur Bahnhof, ich bastel sonst mit AVR, kannst du Bitte erklären was ich da wie machen soll? arm-none-eabi-objcopy -I ihex --output-target=binary code.hex code.bin
Fred F. schrieb: > Wandeln? Ich habe gerade mal ein Hexfile in .bin umbenannt, damit > moppert das Tool rum , da das File zu groß ist. Ja, wandeln. Umbenennen hilft nicht, denn dann werden die ASCII-Zeichen im HEX-File als Code "verwendet". Beispiel: https://de.wikipedia.org/wiki/Intel_HEX#Beispiel. Ein .bin-File ist 1:1-Abbild des FLASHs.
Fred F. schrieb: > Sorry, ich verstehe nur Bahnhof, ich bastel sonst mit AVR, kannst du > Bitte erklären was ich da wie machen soll? > > arm-none-eabi-objcopy -I ihex --output-target=binary code.hex code.bin stell mal hier deine .hex Datei
Irgendeine Ausgewählt:
Fred F. schrieb: > Irgendeine Ausgewählt: siehe im Anhang
Vielen Dank erstmal, damit spring er auch nicht an, muss ich nacher noch mal ran. Jetzt ist erstmal die Familie dran ... Eierfärben, spazieren...
Kleines Update: Ich habe mir mit einem FTDI ein USB Uart Adapter gebaut. Hier ist ein Forum, in dem das Gerät behandelt wird.(das ist nur der kurze Ausschnitt über Programmierprobleme) Leider gibt es das nur auf russisch. http://md4u.ru/viewtopic.php?f=95&t=9553&start=175 Mit google Übesetzer versteht mann etwas mehr. Wie in dem Beitrag habe ich es mit dem Flash Loader probiert, ich habe eine Hex Datei und auch das bin File probiert. Der Chip wird korrekt erkannt, beschreiben funktioniert und dann NIX. Klar Hardwarefehler lassen sich nie ganz ausschliessen, aber was könnte den den am starten hindern? Im Schaltplan ist ein Widerstand in Reihe zum Quarz, ist sowas Okay? Die beiden Boot Pins müssen für Betrieb auf Masse hängen? Am Resetpin hängt ein 100nF gegen Ground.
Gast
#4976164
Hast du auch den Jumper von 'BOOTLOADER' auf 'WORK' nach Abschluss der Programmierung gesteckt?
Ja hab ich gemacht, vieleicht ist auch der µC defekt, aber beschreiben funktioniert ja, seltsam. Irgendwie bin ich ratlos. Kann ich mit dem Flash Loader eine .hex Datei laden oder brauche ich da auch eine .bin? In dem verlinkten Forumsbeitrag sieht es so aus, als ob die damit direkt das Hexfile brennen.
Gast
#4976502
Schließ doch eine LED an und schreib ein Blinky zum Test.
Gast
#4976665
Ich denke mal du hast nicht unbedingt eine Entwicklungsumgebung für den STM32 an Start, oder? Ich habe dir eine bin/hex angehängt die den 8MHz Quarz benutzt, PLL auf intern 24MHz setzt und die LED am PA12 im Sekundentakt blinken lässt.
Vielen Dank für die Unterstützung. Eine Entwicklungsumgebung habe ich zwar drauf, aber ich kann damit ehrlich gesagt nicht gut umgehen. Die 32bitter sind doch etwas komplexer als so ein kleiner AVR. Ich habe mal beide Dateien per Uart draufgeschoben, es funktioniert mit beiden mit dem Hex und dem bin File. Die LED blinkt in sekundentakt. Das verwirrt mich immer mehr, vieleicht löte ich den IC nochmal neu auf, oder ich entferne mal die Widerstände zur angeschlossenen Peripherie.
Gast
#4976805
Meine Vermutung, da es ja so anscheinend funktioniert, ist die Initialisierung des LCD falls diese abgefragt wird. Mehr ist ja eigentlich nicht dran das bremsen könnte. Hast du getestet ob an den LCD Leitungen etwas ankommt?
Bei dem LCD liegt der RW Pin auf Gnd. An den Ausgängen liegt nirgendwo ein Takt an, lediglich feste High oder Low Pegel. Der einzige Takt ist am Quarz. Ich habe noch mal alle Pins des STM auf Kurzschlüsse überprüft, weiterhin alle ausgänge verfolgt, soweit alles i.O.. Ich bin langsam echt ratlos.
Der letzte Stand der Dinge, neuen Prozessor bestellt, eingebaut, programmiert>>> läuft. Nochmal ein dickes Dankeschön an alle Unterstützer. Was mit dem alten µC war kann ich nicht sagen, zum LED blinken hat es ja noch gereicht, mehr halt nicht.
Fred F. schrieb: > Sollte also funktioniert haben, aber das Ding geht nicht an. Eigentlich > hätte ich ein Piepton erwartet und eine Anzeige im Display. > Muss ich da noch irgendwas beachten? Bei den AVR gibt es ja die Fuses > die er für die Taktraten braucht, gibt es hier sowas auch? Steht Dir kein Debugger zur Verfügung? mfg klaus
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.