STM32F4 - programmierbar, aber läuft nicht

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 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.

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

?!? 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...

Ach Gott!

Der "Fehler" lag bei Eclipse.

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

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.

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