Systick zu langsam / Hardwarefehler

[Jens (Gast)]

Moin,
ich setze in einer Serienproduktion STM32F103RF ein. Ab und zu schaue 
ich mir mal Ausfälle an, die den Fertigungstest nicht bestanden haben, 
um ggf. Optimierungen durchzuführen.
Da es sich um ein kommerzielles Produkt handelt, kann ich leider keine 
Schaltpläne posten, aber letztendlich handelt es sich nur um den 
Prozessor mit Hühnerfutter, der ein paar UARTs betüddelt.

99,9% werden ohne Fehler gefertigt, weshalb es in meiner Frage nicht um 
einen  systematischer, sondern Einzelfehler geht.

Dieser zeigt sich wie folgt:
Der Systick läuft ca. Faktor 10 zu langsam.

Mir viel dies zunächst nicht auf, bis ich gesehen habe, dass der 
Zeitstempel der Debugausgabe entsprechend langsam läuft. Folglich 
funktionieren einige Timeouts auch nicht wie erwartet.

Das Interessante ist, dass die UARTs mit der richtigen BAUD-Rate 
arbeiten! D.h. deren Taktquelle ist in Ordnung. Also bin ich von einem 
defekten Controller ausgegangen, doch auch dies hat den Fehler nicht 
behoben!

Bevor jetzt Aussagen über die Glaskugel etc. kommen, möchte ich eine 
konkrete Frage stellen:

Hat jemand schon einmal erlebt, dass der Systick aufgrund eines 
Beschaltungsfehlers falsch tickte während anderen Taktquellen trotzdem 
richtig liefen?

VG
Jens

[meckerziege (Gast)]

Kannst du dir die internen taktteiler ansehen? Technisch wäre das 
denkbar dass einer falsch eingestellt ist. Ebenso gibt es beim systick 
einen 8er teiler optional.

An den f1 solltest du doch nen debugger ran bringen

Kann viele gründe haben. Sw bug (zugriff auf uninitialisierten wert), hw 
fehler, programmierfehler in der fertigung.

[BS (Gast)]

Jens schrieb:
> Hat jemand schon einmal erlebt, dass der Systick aufgrund eines
> Beschaltungsfehlers falsch tickte während anderen Taktquellen trotzdem
> richtig liefen?

Ja, ich hatte so was mal, als bei einer Platine die interne 
Core-Spannung des Prozessors (1.7V, intern aus VDD generiert, externer 
Kondensator dran) durch eine Lötbrücke auf VDD angehoben wurde. 80% der 
Prozessoren liefen trotzdem normal, die restlichen 20% aber liefen 
deutlich zu langsam. Das waren Cypress-Prozessoren. Da waren aber auch 
die UARTs zu langsam.

[Jens (Gast)]

BS schrieb:
> Jens schrieb:
>> Hat jemand schon einmal erlebt, dass der Systick aufgrund eines
>> Beschaltungsfehlers falsch tickte während anderen Taktquellen trotzdem
>> richtig liefen?
>
> Ja, ich hatte so was mal, als bei einer Platine die interne
> Core-Spannung des Prozessors (1.7V, intern aus VDD generiert, externer
> Kondensator dran) durch eine Lötbrücke auf VDD angehoben wurde. 80% der
> Prozessoren liefen trotzdem normal, die restlichen 20% aber liefen
> deutlich zu langsam. Das waren Cypress-Prozessoren. Da waren aber auch
> die UARTs zu langsam.

Sowas hatte ich auch mal, da war einer der VDD Pins nicht richtig 
verlötet. Das hatte dann ähnliche Wirkung wie jetzt. Ich hatte diesmal 
dann aber alle VDDs mal direkt am Controller nachgemessen und da war es 
ok.

[Test (Gast)]

Leg doch mal den F_CLK auf den MCO Pin und schau es dir dort an. Der 
SYS_CLK wird davon mit /8 abgeleitet. Schwingen deine Oszillatoren 
sicher? Oszillator Fallback auf HSI wird überwacht?

[NichtWichtig (Gast)]

Derartiges Verhalten zeigen einige BluePills bei mir.

Ausführung zu langsam, serial paßt.

Siehe BluePill Fake thread.

[Fenner (Gast)]

Jens schrieb:
> Also bin ich von einem
> defekten Controller ausgegangen, doch auch dies hat den Fehler nicht
> behoben!

Heisst das du hast den Controller getauscht und das Problem bestand 
weiter? D.h. ein Board, das nicht richtig fubktioniert, geht nie, auch 
nach neuem Flashen etc. nicht?

[Wolfgang (Gast)]

Jens schrieb:
> Dieser zeigt sich wie folgt:
> Der Systick läuft ca. Faktor 10 zu langsam.

Was heißt "ca. Faktor 10"?
Würde ein Faktor 8 bei dir auch noch unter  "ca. Faktor 10" fallen?
Ist der Fehler bei den fehlerhaften Boards immer gleich oder streut der 
Faktor?

[meckerziege (Gast)]

meckerziege schrieb:
> Kannst du dir die internen taktteiler ansehen? Technisch wäre das
> denkbar dass einer falsch eingestellt ist. Ebenso gibt es beim systick
> einen 8er teiler optional.
> An den f1 solltest du doch nen debugger ran bringen
> Kann viele gründe haben. Sw bug (zugriff auf uninitialisierten wert), hw
> fehler, programmierfehler in der fertigung.

Wie siehts nun hiermit aus?