STM32F4 - programmierbar, aber läuft nicht

[Vincent H. (vinci)]

Grüß euch

Ich erkunde gerade die STM32F4 Familie und habe diesbezüglich eine 
kleine Platine entwickelt. Nach erster Euphorie, dass diese 
programmier/lesbar usw. war musste ich leider feststellen, dass ich den 
Controller zwar mit meinem Code versehen kann, dieser aber schlichtweg 
nicht loslaufen will...

Egal ob ich den Chip via ST Utility oder OpenOCD programmiere, er gibt 
keinen Mucks von sich. Das "run" command aus dem ST Utility gibt 
ebenfalls die Fehlermeldung "Unable to run application" aus. Nach einem 
System oder Core reset behauptet das Tool der Core befinde sich im 
"Lockup" state.


tia

[ich kann nicht hellsehen, aber crawlen (Gast)]

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka12545.html

[Vincent H. (vinci)]

ich kann nicht hellsehen, aber crawlen schrieb:
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka12545.html


Hm. Mein "Code" tut bisher nichts.
Wüsste nicht wie das passieren soll...?
Die Initialisierung stammt gar aus STs Cube Tool.

[Dispol (Gast)]

Kommst Du mit dem Debugger in die Initialisierung rein?
Ich hatte das mal, dass die PLL falsch konfiguriert war.

[Vincent H. (vinci)]

Dispol schrieb:
> Kommst Du mit dem Debugger in die Initialisierung rein?
> Ich hatte das mal, dass die PLL falsch konfiguriert war.


Leider nein, nur programmieren geht.
Aber der Fehler tritt auch ein wenn ich den internen Oszillator 
verwende.


Einmal hatte ich sowas ähnliches wo letztendlich die flash latency 
falsch gesetzt war. Die hab ich aber mittlerweile testweise schon 
erhöht... ohne Ergebnis.

[Vincent H. (vinci)]

Ok, mittlerweile bin ich mir sicher, dass es sich um einen Lockup 
handelt.
Im ST Utility Tool kann man den Core State via Hakerl bei "Live Update" 
auch direkt anzeigen lassen und da befindet er sich ständig im Lockup.

Aber ich versteh nicht wieso.
1:1 den selben Startup Code hab ich bereits einmal erfolgreich 
genutzt...
das gibts ja nicht

[?!? (Gast)]

Vincent Hamp schrieb:
> Ok, mittlerweile bin ich mir sicher, dass es sich um einen Lockup
> handelt.
> Im ST Utility Tool kann man den Core State via Hakerl bei "Live Update"
> auch direkt anzeigen lassen und da befindet er sich ständig im Lockup.
>
> Aber ich versteh nicht wieso.
> 1:1 den selben Startup Code hab ich bereits einmal erfolgreich
> genutzt...
> das gibts ja nicht

Hallo Vincent,

es kann sein, daß irgendein Takt nicht stimmt. Da muß nur irgendwo eine 
falsche Zahl bei einem Teiler oder Multiplikator stehen und schon ist 
ein bestimter Takt außerhalb des erlaubten Bereiches.
Installiere dir mal den STM32CubeMX, da kannst du das gesamte Taktschema 
(und auch andere Interna) anschauen und konfigurieren. Ich bin auch noch 
am Anfang des STM32-Weges und finde das Teil sehr nützlich.

[Vincent H. (vinci)]

?!? schrieb:
> Vincent Hamp schrieb:
>> Ok, mittlerweile bin ich mir sicher, dass es sich um einen Lockup
>> handelt.
>> Im ST Utility Tool kann man den Core State via Hakerl bei "Live Update"
>> auch direkt anzeigen lassen und da befindet er sich ständig im Lockup.
>>
>> Aber ich versteh nicht wieso.
>> 1:1 den selben Startup Code hab ich bereits einmal erfolgreich
>> genutzt...
>> das gibts ja nicht
>
> Hallo Vincent,
>
> es kann sein, daß irgendein Takt nicht stimmt. Da muß nur irgendwo eine
> falsche Zahl bei einem Teiler oder Multiplikator stehen und schon ist
> ein bestimter Takt außerhalb des erlaubten Bereiches.
> Installiere dir mal den STM32CubeMX, da kannst du das gesamte Taktschema
> (und auch andere Interna) anschauen und konfigurieren. Ich bin auch noch
> am Anfang des STM32-Weges und finde das Teil sehr nützlich.



Mit dem Tool hab ich den Controller bereits konfiguriert.
Aber Achtung, das Teil is Fluch und Segen zugleich.


So leicht die Takt-Konfiguration damit auch wird gibts etwa einen Bug, 
der die Flash Latency falsch einstellt! Nach sowas sucht man dann 
ewig...

[?!? (Gast)]

Vincent Hamp schrieb:
> So leicht die Takt-Konfiguration damit auch wird gibts etwa einen Bug,
> der die Flash Latency falsch einstellt! Nach sowas sucht man dann
> ewig...

Danke für den Hinweis. Falls mir das mal passiert...
Sonst kann ich dir leider auch keinen Tipp geben. Aber ich verfolge den 
Thread mal weiter, vielleicht hat jemand eine Idee.

[Vincent H. (vinci)]

Ach Gott!

Der "Fehler" lag bei Eclipse.

ASM-Datein mit kleiner .s Endung werden von diesem standardgemäß nämlich 
nicht erkannt. -.-

[Jim M. (turboj)]

Vincent Hamp schrieb:
> Nach einem
> System oder Core reset behauptet das Tool der Core befinde sich im
> "Lockup" state.

Dann lass Dir mal von OpenOCD die ersten 8 Werte der Vectortabelle 
ausgeben.
Schau Dir insbesondere den ersten Wert (initialer SP, muss in den RAM 
oder an dessen Ende zeigen und durch 8 teilbar sein) und den zweiten 
Wert (PC, muss in den Flash zeigen und ungrade sein) an. Die 
Vectortabelle steht am Anfang des Flashs.

[Warning (Gast)]

Vincent Hamp schrieb:
> Ach Gott!
>
> Der "Fehler" lag bei Eclipse.
>
> ASM-Datein mit kleiner .s Endung werden von diesem standardgemäß nämlich
> nicht erkannt. -.-

Na,na, hat da einer die Errors oder Warnings ignoriert? ;-)

[Vincent H. (vinci)]

In so einem Fall spuckt Eclipse leider weder noch aus.
Tritt ja schlichlich zur Compilezeit ja auch kein Fehler auf...