Habe dieses board -
http://www.ebay.de/itm/1-2-5-10Stks-STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-/272425764978?var=&hash=item3f6dd74872:m:mrAOyKktZjIFkrwmEnoO1Mg
-
vergeblich versucht mittels St-Link V2 zu flashen.
Fehlermeldung coide:
C:\CooCox\CoIDE>"C:/CooCox/CoIDE/bin\coflash.exe" program STM32F103C8
"C:/CooCox/CoIDE/workspace/y/y/Debug/bin/y.elf" --adapter-name=ST-Link
--port=SWD --adapter-clk=1000000 --erase=affected --reset=SYSRESETREQ
--driver="C:/CooCox/CoIDE/flash/STM32F10x_MD_64.elf"
Erase: Done
Program: Failed
Error: Flash driver function execute error
vom Hersteller aufgespieltes Blink-programm läuft noch, so dass erase
offenbar auch nicht geht.
Alle möglichen jumper-Stellungen des bootladers durchprobiert. Chip ist
richtig ausgewählt.
103VE lässt sich flashen, also link und coide in Ordnung.
Hat jemand eine Idee, was der Fehler sein könnte?
Oder:
Vor dem Starten des Programmiervorgangs den Reset Knopf gedrückt halten
und
erst nach dem Start loslassen.
Könnte sein, dass die existierende Firmware die für SWD benötigten Pins
umprogrammiert hat.
grundschüler schrieb:> Alle möglichen jumper-Stellungen des bootladers durchprobiert. Chip ist> richtig ausgewählt.
Also, was willst du benutzen? Den Bootlader oder SWD? Das sind zwei
verschiedene Dinge.
Frage:
Schaffst du es, aus deinem "STM32F10x_MD_64.elf" ein dazu passendes
Hexfile oder Binärfile zu erzeugen? Also FromElf oder ObjCopy benutzen?
Wenn ja, dann lade dir den Stm32Prog hier aus dem Forum herunter und
versuche dein Glück damit. Dort kannst du alles in Einzelschritten tun,
also Löschen, Leertest, Programmieren usw.
W.S.
Ich habe mit einen Discovery-Board die Platinen schon programmiert.
Platine an Discovery-Board über SWD anschließen. Vorher bestimmte Jumper
auf dem Discovery-Board ziehen.
Discovery-Board mit USB an Linux-PC.
Open-OCD auf Linux-PC draufinstallieren.
Danke erstmal für die Unterstützung.
Kabel sind ca. 40cm. Kann daran eigentlich nicht liegen, weil 103VE und
103ZE damit geflasht werden können.
>Also, was willst du benutzen? Den Bootlader oder SWD? Das sind zwei
verschiedene Dinge.
Wenns irgend geht, SWD, einfach weil ich noch nie - außer bei asuro? -
einen bootlader benutzt habe. Es fehlt mit auch das passende Kabel für
den usb-Usart. Wenn ich das passende Kabel finde, werde ich deinen
Bootlader mal ausprobieren.
>Probier mal den ST Visual programmer :
werde ich probieren.
>Vor dem Starten des Programmiervorgangs den Reset Knopf gedrückt halten
hat nicht geholfen
aus der Fehlermeldung:
adapter-clk=1000000
Kann man den Takt irgendwie herabsetzen?
Der 103C8 ist doch ein Massenprodukt. Hat jemand Erfahrung mit flashen
mittels link-v2?
Bei diesen China-Boards ist meistens der Schreibschutz der Controller
gesetzt (Warum auch immer...).
Einfach mit dem ST-Tool den Schreibschutz entfernen und das Ganze läuft.
Welche Datei hast du denn versucht zu flashen?
Versuch doch mal eine andere Datei aus dem Netz zu flashen,
aber die muss natürlich compiliert sein. Der Quelltext geht
da natürlich nicht, nie.
Ich wiederhole mich:
Zu lange Kabel? schrieb:> Oder:>> Vor dem Starten des Programmiervorgangs den Reset Knopf gedrückt halten> und> erst nach dem Start loslassen.>> Könnte sein, dass die existierende Firmware die für SWD benötigten Pins> umprogrammiert hat.
hp-freund schrieb:> Fehlt wohl der Treiber:
stlink v2 nochmal installiert. Funktioniert mit 103ve. eprcore60.dll
nicht gefunden.
stvp ist wohl nur eine oberfläche, die den Zugriff auf verschiedene
Programmer ermöglicht - wie coflash.exe.
Mit coflash.exe direkt ist es mir nun gelungen, einen "erase"
auszuführen: es blinkt nichts mehr. Lässt sich aber auch nicht neu
beschreiben.
Das ganze macht so keinen Spaß.
Ich schmeiß die Dinger weg und bestell mir noch einen 103ve
Zu lange Kabel? schrieb:> Vor dem Starten des Programmiervorgangs den Reset Knopf gedrückt halten>> und>> erst nach dem Start loslassen.
alles in allen denkbaren Varianten erfolglos probiert
>> Könnte sein, dass die existierende Firmware die für SWD benötigten Pins>> umprogrammiert hat.
Unwahrscheinlich da Massenprodukt und der blinkende pin c13 sicher nicht
ein swd-pin ist.
Andreas R. schrieb:> Mal unter Linux probieren?
Es geht irgendwas vermutlich richtig in den usb-link rein, denn es geht
ja mit dem 103ve.
Dann ist irgendwo zwischen link und 103c8 ein problem.
Jetzt noch das Betriebssystem wechseln ist mir zu heftig. Wenn
103c8-Stm-chips nicht einfach funktionieren nehm ich halt was anderes.
Ich hab dke dinger auch. Hast du den schreibschutz entfernt? Musste ich
zwar nicht aber soll vorkommen das es noetig ist. Bei mir funktionieten
die dinger uebrigens tadellos
Wir hatten für ein Projekt hundert dieser <€1,50 Boards bei
verschiedenen chinesischen Anbietern gekauft.
Zuerst sind wir auch fast verzweifelt, als wir die unter Linux nicht
flashen konnten.
Nach zwei Tagen Experimentieren haben wir dann mal auf einem Windows-PC
die Teile mit dem ST-Tool angesehen und wie oben schon berichtet, war
auf ALLEN der Schreibschutz gesetzt. Was sich die Chinesen dabei gedacht
haben???
Nach dem Entfernen lief unter Linux alles wunderbar.
john doe schrieb:> die Teile mit dem ST-Tool angesehen und wie oben schon berichtet, war> auf ALLEN der Schreibschutz gesetzt. Was sich die Chinesen dabei gedacht
Schreibschutz hört sich plausibel an. Dagegen spricht nur, dass das
"erase" inzwischen geklappt hat. Das st-tool läuft -wie oben
beschrieben- nicht. Müsste micht in die st-tool-dokumentation
einarbeiten. Die Zeit verwende ich lieber auf mein Projekt.
grundschüler schrieb:> john doe schrieb:>> die Teile mit dem ST-Tool angesehen und wie oben schon berichtet, war>> auf ALLEN der Schreibschutz gesetzt. Was sich die Chinesen dabei gedacht>> Schreibschutz hört sich plausibel an. Dagegen spricht nur, dass das> "erase" inzwischen geklappt hat. Das st-tool läuft -wie oben> beschrieben- nicht. Müsste micht in die st-tool-dokumentation> einarbeiten. Die Zeit verwende ich lieber auf mein Projekt.
"Erase" ist etwas ganz anderes als "write".
john doe schrieb:> Nach zwei Tagen Experimentieren haben wir dann mal auf einem Windows-PC> die Teile mit dem ST-Tool angesehen und wie oben schon berichtet, war> auf ALLEN der Schreibschutz gesetzt. Was sich die Chinesen dabei gedacht> haben???
Ich habe da so eine Idee: möglicherweise ist dort überall die Firmware
des ST-Link's drauf. Die gibt's im Netz auch separat und sie wird wohl
ganz gern als Test genommen: FW drauf und gucken wie es blinkt und wie
sich das Teil am USB anmeldet.
Das hilft ein Bulkerase.
W.S.
flupp schrieb:> ahso>> guckst du hier:>> Youtube-Video "Short Tutorial: How To Start Programming STM32 Arduino> MCUs"
Meine Nerven. Das war der entscheidende Hinweis. Alten usb-to-serial
gesucht und irgendwo auch gefunden. Alles genau so gemacht wie im Video,
Schreibschutz entfernt. mit link-v2 eigenes blinkprogramm aufgespielt.
Es blinkt!
Respekt für alle Beiträge aus dem Forum. Ohne diese Hilfe hätte ich
keine Chance gehabt.
Entschädigt wird man durch im Vergleich zum AVR gewaltige Rechenleistung
der 3€-boards und durch den -im Vergleich zu winAVR- sehr hilfreichen
Coide-debugger. Hier mal ein Vorschlag zur Vermeidung der
stm-Structuren:
grundschüler schrieb:> #define pinSET(x,y) GPIO(x)->ODR|=(1<<y)> #define pinCLR(x,y) GPIO(x)->ODR&=~(1<<y)
Guck mal nach dem BSR und BRR. Das ist noch nen Tick schneller ohne
R/M/W.
grundschüler schrieb:> Hier mal ein Vorschlag zur Vermeidung der> stm-Structuren:
Ja, eben. Solche Denkweisen kommen angesichts dessen, was man hier seit
Jahren lesen muß, immer wieder von AVR-Leuten.
mein ganz dringender Rat dazu: Löse dich von solcher Denke. Die Ports in
den Controllern der ARM-Riege sind was Anderes als das, was man früher
bei AVR gehabt hat.
Es gibt bei den Cortexen deutlich effizientere Port-Benutzungsmethoden,
angefangen von Write-only-Registern zum Setzen und Rücksetzen von Pins
bis hin zu Bitfeldern, wo jedes Pin quasi als ein bool oder longbool
angesprochen werden kann.
Irgendwelche Pseudo-Vereinheitlichungen a la "#define PORTC 2" und so
sind überhaupt nicht hilfreich, sondern schaffen bloß einen uneffektiven
Code.
Stattdessen solltest du wirklich das RefManual lesen und dich mit dem
Gebrauch der GPIO-Peripheriecores und deren Registern, also der echten
Hardware vertraut machen.
W.S.
W.S. schrieb:> deutlich effizientere Port-Benutzungsmethoden
Schau dir mal im Debugger an, was bei der Abarbeitung einer Structur
passiert.
z.B. dieser Befehl
{*(uint32_t*)(GPIOA_BASE + PORT(port) *0x400 +
(pin/8)*4)&=~(0b1111<<(4*(pin%8)));
für das Setzen eine Registers + sehr viel mehr völlig überflüssige
Befehle. Ich habe ger übersichtlichen Code bei dem ich weiß, was die mcu
macht.
Du kannst davon ausgehen, dass ich mich mit dem Aufbau der Register
beschäftigt habe, weil ich sie ohne structs direkt ansprechen kann. Ohne
Lesen des Manuals wird man dies nicht können. Gerade das ist es, was
mich an Stm-Structuren stört, dass sie sich nicht auf das Manual
zurückführen lassen.
> Die Ports in den Controllern der ARM-Riege sind was Anderes als das, was> man früher bei AVR gehabt hat.
Register sind Register. So groß sind die Unterschiede gar nicht.
Mit ODR / BSR,BSRR habt ihr sicher recht. Das wird noch geändert.
Nico W. schrieb:> Was das bedeutet, weißt du sicher in einer Woche selbst nicht mehr.
Das hab ich einmal gemacht und interessiert mich gar nicht mehr. Ich
wüsste aber immer, dass hier die für pin zuständigen Werte im dafür
zuständigen Register gelöscht werden.
1
do{ \
2
if(v) \
3
IO##_PORT->BSRR=MASK(IO##_PIN); \
4
else \
5
IO##_PORT->BSRR=MASK((IO##_PIN+16)); \
6
}while(0)
Die while-0-Schleife verstehe ich nicht. Die if-abfrage ist überflüssig.
W.S. schrieb:
> deutlich effizientere Port-Benutzungsmethoden
Ich zitiere mal aus einer früher geführten Diskussion:
"Ob man nun UART0->TRH = MyByte; oder nach anderer Deklaration UART0THR
=
MyByte; schreibt, ist damit egal und das Verwenden von Struct's führt zu
keinerlei Vorteil. Da ist mir das separate Deklarieren mit exakt den
gleichen Namen wie im RefMan bedeutend lieber."
Beitrag "Re: LPC Registerzugriff Fehler in LPC176x.h"
genau meine Meinung. Mine #defines beruhen auf dem früheren nxp-Konzept
in z.B. der lpc1768x.h Datei. Da sind auch solche #defines enthalten.
Kann also nicht so ganz falsch sein.
Die Stm-routine zum Setzen von wenigen Registern auf Eingan/Ausgang ist
einfach nur grausam:
grundschüler schrieb:> Die while-0-Schleife verstehe ich nicht. Die if-abfrage ist überflüssig.
Ohne die while-0-Schleife funktioniert das Beispiel hier nicht.
1
if(something)
2
WRITE(PA_1,1);
3
else
4
do_something_else();
Die if-Abfrage ist nicht überflüssig. Damit kann ich den Pin an und aus
schalten.
grundschüler schrieb:> Mine #defines beruhen auf dem früheren nxp-Konzept> in z.B. der lpc1768x.h Datei. Da sind auch solche #defines enthalten.
NXP hat KEIN Konzept! NXP hatte noch nie ein eigenes Konzept. Alles was
damals geschrieben wurde, das wurde von irgend welchen Leuten in einer
Comunity frei erfunden - nur hat diesen tollen Code nun NXP an sich
genommen und frickelt damit weiter - entsprechend große Differenzen gibt
es im Code z.B. zwischen LPC176x und LPC43xx. Abgesehen davon dass auch
noch die ein oder andere Register Deklaration komplett fehlt.
Hingegen die STM Header und die automatisch generierten Sourcen
entsprechen schon sehr stark der ARM driver Specification.
Du tust gut daran sich an das zu halten, denn damit sind deine Sourcen
automatisch für die Zukunft leichter portierbar auf andere µC von ST.
Außerdem ist damit auch der Einstieg in das Berufsleben als µC
Programmierer leichter und du verstehst viel schneller den existierenden
Code.
Nico W. schrieb:> Nein
danke für den Hinweis. Verstanden. Ich habe einen Macro aus zwei
statements und muss die sicher verbinden. dazu ist der Macro bei mir mit
{} eingeklammert, bei dir mit do{}while(0), was mglw. das gleiche ist,
mglw. auch nicht. werde ich ausprobieren und ggf. ändern.
Markus M. schrieb:> NXP hat KEIN Konzept!
und STM?
Für meine Hobby-Anwendungen ist der Hersteller im Prinzip egal. Ich
verwende inzwischen hauptsächlich AVRs und STMs, früher LPCs. Sind alle
gut.
zur Zeit Mega328 und STM32F103C8, weil man da ohne Rücksicht auf das
3€-board alles ausprobieren kann. Ich verwende noch winAVR und Coide.
studio ist mir zu nervig. Cube weiß ich nicht. LPCXpresso war sicher
besser als coide - coide ist aber auch nicht schlecht.
Ich muss mir für coide den Zugang zu Standard-Funktionen neu erarbeiten
und versuche das durch Macros in reproduzierbare Schritte zu fassen. Da
läuft in den Stm-Structuren einfach zu viel im Hintergrund ab. Obwohl
ich inzwischen einige mcu-Erfahrung habe, ist es mir mit den STM-structs
nicht gelungen, ein I2c-lcd zum laufen zu bringen. Ging erst nach
Transfer der Fleury-lib von avr auf arm.
Nico W. schrieb:> error: 'else' without a previous 'if'
Das lässt sich auch mit do-while-0 nicht vermeiden. Ist aber auch kein
wirkliches Problem, weil man nach der Fehlermeldung weiß, dass ein semi
zu viel bzw. 2Klammern zu wenig sind.
wegen eines bugs nochmal der getestete code:
grundschüler schrieb:> Mine #defines beruhen auf dem früheren nxp-Konzept> in z.B. der lpc1768x.h Datei. Da sind auch solche #defines enthalten.> Kann also nicht so ganz falsch sein.
Es geht nicht um "so ganz falsch", sondern um Strategien. Du hast weiter
oben mit sowas wie #define pinset(port, pin) und so angefangen. Das ist
die falsche Richtung.
Man braucht sowas nicht nur NICHT, sondern es ist auch letztlich etwas
Schlechtes. Sowohl für die Effizienz des erzeugten Codes als auch für
die Quellen an sich.
Denke du mal lieber daran, sinnvolle Low-Level-Treiber für die diversen
Peripherien zu schreiben. Also solche, die die Hardware ordentlich
puffern, kapseln, betreiben. In so einem Treiber kann man viel besser
mit direkten Anweisungen arbeiten, wie z.B.
void Motor_Ein (void)
{ GPIOB_BSRR = 1<<7; }
oder so ähnlich. Das übergeordnete Programm braucht wirklich nicht zu
wissen, an welchem Pin der Motor hängt und ob man das nun H oder L
setzen muß. Zum Portieren braucht man dann auch bloß eben diesen
Lowlevel-Treiber zu ändern - und an Routine, die den Motor tatsächlich
betreibt, ihn vielleicht kompliziert regelt oder sonstwas, braucht es
gar keine Änderung. Das ist letztlich viel übersichtlicher, als wenn du
mit pinset(...) arbeiten würdest.
Es gibt viele Firmen, die solche von dir genannten hochkomplizierten
Makros mit Vorliebe unter die Leute streuen. Find ich schlecht, da es
auf Dauer damit nur unleserlich wird und man abgeschottet ist davon, was
wirklich passiert, beim Lesen zu verstehen. Gut gemeint ist fast immer
das Gegenteil von gut gemacht.
Also: System KISS: mach's lieber einfach, laß hakelige Makros bleiben,
programmiere nicht wie ein Seiltänzer sondern auf eher biedere Weise.
W.S.
grundschüler schrieb:> Das lässt sich auch mit do-while-0 nicht vermeiden.
Natürlich lässt sich das mit do-while(0) vermeiden.
1
#define DO_SOMETHING do { do_something; }while(0)
2
3
if(what)
4
DO_SOMETHING;
5
else
6
yupp();
wird zu
1
if(what)
2
do{do_something;}while(0);
3
else
4
yupp();
Und die do-while(0) wird der Compiler dann eh rausschmeißen. Es geht
hier um eine gescheite Syntax. Du wolltest doch was gescheites basteln
und weg von der HAL oder StdPeriph. Aber so wird das nur deutlich mehr
murks.
Nico W. schrieb:> Natürlich lässt sich das mit do-while(0) vermeiden.
kein Problem, kommt halt do-while-0 um Makros aus mehreren Zeilen drum
rum.
Jedenfalls Danke für den hINWEIS.
Thread beobachten
Seitenaufteilung abschalten