STM32 - RTC läuft viel zu langsam

[Jan (Gast)]

Hallo,

ich habe hier ein STM32F103C8 Evaluation Board (2€ Billig Board). Auf 
diesem ist ein 32,768kHz Quarz für die Real Time Clock.
Ich gehe jetzt mal davon aus, dass dort nicht gerade ein High-Tech 
Präzisions Quarz verbaut ist, aber die Abweichungen die ich bekomme 
erscheinen mir doch sehr hoch. Nach 100 Sekunden geht das System schon 
ca. 1 Sekunde nach. Ist so was üblich, oder habe ich Schrott in meiner 
Initialisierung?
Vielen Dank für die Infos.
Nachfolgend ist noch mein Code zur Initialisierung:

  NVIC_InitTypeDef NVIC_InitStructure;

  RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR | RCC_APB1Periph_BKP, ENABLE);  // Enable PWR and BKP clocks
  PWR_BackupAccessCmd(ENABLE);                        // Allow access to BKP Domain
  BKP_DeInit();                                // Reset Backup Domain
  RCC_LSEConfig(RCC_LSE_ON);                          // Enable LSE (32,768kHz Quarz)
  while (RCC_GetFlagStatus(RCC_FLAG_LSERDY) == RESET){}            // Wait till LSE is ready (Einschwingvorgang abwarten)

  RCC_RTCCLKConfig(RCC_RTCCLKSource_LSE);        // LSE as Clock source (32,768kHz Quarz)
  RCC_RTCCLKCmd(ENABLE);                // Enable RTC Clock
  RTC_WaitForSynchro();                // Wait for RTC registers synchronization
  RTC_WaitForLastTask();                // Wait until last write operation on RTC registers has finished
  RTC_ITConfig(RTC_IT_SEC, ENABLE);          // Enable the RTC Second Interrupt
  RTC_WaitForLastTask();                // Wait until last write operation on RTC registers has finished
  RTC_SetPrescaler(32767);              // Set RTC prescaler: set RTC period to 1sec
  RTC_WaitForLastTask();                // Wait until last write operation on RTC registers has finished


  NVIC_InitStructure.NVIC_IRQChannel = RTC_IRQn;
  NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
  NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;  
  NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;      
  NVIC_Init(&NVIC_InitStructure);

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Starte das Programm im Debugger, warte bis alles laeuft, unterbreche es, 
lass Dir dann den Inhalt der RTC Register ausgeben und vergleiche die 
Werte mit den Werten die Du mit dem Referenzmanual ausrechnest.

Aktuelle Cube Bibliotheken enthalten kein RTC_SetPrescaler, vermutlich 
verwendest Du die alte Standardlibrary.

[W.S. (Gast)]

Jan schrieb:
> RTC_SetPrescaler(32767);

Solange du mit diesem gräßlichen "InitStructure" Zeugs arbeitest, mußt 
du selber nachschauen, ob obiger Wert richtig ist. Ich fasse dieses 
ST-Zeugs nicht an und würde lieber in das RefMan zum Chip schauen. Und 
das rate ich dir ebenfalls an.

W.S.

[C. H. (hedie)]

Jan schrieb:
> Nach 100 Sekunden geht das System schon
> ca. 1 Sekunde nach. Ist so was üblich, oder habe ich Schrott in meiner
> Initialisierung?

Das passt schon.
Du musst den halt zuerst kalibrieren.

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

1 Sekunde auf 100 Sekunden ist zu viel. Wenn es nicht ein Messfehler 
ist. Erst wenn es x Sekunden in x * 1000 Sekunden, mit x > 3, wuerde ich 
der Messung glauben.

[Jan (Gast)]

Hi,

danke für die Tipps.
Ich habe mir die RTC Prescaler Register angeschaut - es steht der Wert 
drin, den ich reingeschoben hatte.

Die Kalibrierung mittels BKP_RTCCR Register ist soweit ich das aus 
"AN2604
Application note" verstehe, eher für Abweichungen von einigen Sekunden 
pro Monat.

Aber ich bin eben im Reference Manual über einen Hinweis gestolpert:
"Due to the fact that the switch only sinks a limited amount of current 
(3 mA), the use of GPIOs PC13 to PC15 in output mode is restricted: the 
speed has to be limited to 2 MHz with a maximum load of 30 pF and these 
IOs must not be used as a current source (e.g. to drive a LED)."

Sinnvollerweise ist auf meinem Evaluation Board die einzige LED genau an 
diesem Port PC13 angeschlossen. Ich hatte sie im Sekundentakt mitblinken 
lassen. Aufgefallen war mir, als ich versucht habe am Quarz mit dem Oszi 
mitzuhören, dass extreme Störungen im Sekundentakt auftreten.

Hab den Ausgang jetzt zu einem Eingang gemacht und schon läuft die Uhr 
seit 10 Minuten ziemlich gut (soweit ich das bisher mit einer Stoppuhr 
überprüfen kann). Jetzt lass ich das mal über einen längeren Zeitraum 
laufen.

Beste Grüße!

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Womit wird verglichen?

[Jan (Gast)]

Was meinst du damit?
Meinst du meine "Referenzuhr?", mit der ich vergleiche?
Das ist aktuell die Stoppuhr in meinem Handy. Was besseres fällt mir 
gerade nicht ein...

[TK (Gast)]

Hallo,
ich kenne jetzt den F103 mit dem RTC-Block nicht - aber bei anderen
Bausteinen muß man bei der Auswahl des Uhrenquarzes darauf achten, 
welche (eingebaute) Last existiert. Es gibt da welche mit 12.5pF, mit 
10pF und mit 8,5pF. Weiterhin müssen/sollen manche Gehäuse auf Masse 
gelegt werden, andere können frei stehen. Ich vermute mal das Problem an 
genau dieser Stelle.

Gruß
TK

[Axel S. (a-za-z0-9)]

TK schrieb:

> .... muß man bei der Auswahl des Uhrenquarzes darauf achten,
> welche (eingebaute) Last existiert. Es gibt da welche mit 12.5pF, mit
> 10pF und mit 8,5pF. Weiterhin müssen/sollen manche Gehäuse auf Masse
> gelegt werden, andere können frei stehen. Ich vermute mal das Problem an
> genau dieser Stelle.

Ganz sicher nicht.

Eine Sekunde Abweichung auf 100 Sekunden - das sind 10000 ppm. So weit 
daneben schwingt kein Quarz der Welt wegen falscher Bürde-Kondensatoren. 
Er schwingt dann vielleicht gar nicht oder auf einer Oberwelle.

[TK (Gast)]

Axel schrieb:
>Ganz sicher nicht.
>Er schwingt dann vielleicht gar nicht oder auf einer Oberwelle.

Und was ist, wenn der nur sporadisch schwingt? Ist das kein Grund für 
eine riesige Abweichung?
Vielleicht sollte der TO uns einfach mal sagen, welchen Typ er genau 
eingesetzt hat und ob evtl. noch zusätzliche Last-Cs am STM hängen 
(Anmerkung Schaltplan)

Gruß
TK

[Jan (Gast)]

Hi,

zu dem verwendeten Typ: Ich habe keine offiziellen Schaltpläne zu diesem 
Board, also kann ich nicht genau sagen, welcher Quarz darauf verbaut 
ist, das einzige was auf dem Gehäuse neben der Frequenz lesbar ist, ist 
ein großes "E". Die Kondensatoren haben meines Wissens 100pF.
Zusätzliche Last Cs habe ich nicht angeschlossen.

Das Problem schien aber vielmehr ein internes Thema des STM32F103C8T6 zu 
sein, dass man an PC13 keine Last anhängen darf (was ich zuvor mit einer 
LED getan hatte), wenn man den 32,768kHz Quarz (an PC14/15) betreibt. 
Scheint irgendwas mit der Stromversorgung zu tun zu haben (siehe meinen 
letzten Beitrag).

Viele Grüße

[Jan (Gast)]

Was ich noch vergessen hatte: sobald ich die LED an PC13 nicht mehr 
benutzt habe, läuft der Takt ziemlich präzise. Ich kann bisher nach 
einem Tag keine (mit der Stoppuhr) messbare Abweichung erkennen. Ich 
denke mal alles was jetzt an Abweichung übrig bleibt ist akzeptable 
Toleranz und kann mit der internen Kalibrierung korrigiert werden.

[Amateur (Gast)]

Hast Du es mal mit aufrunden versucht?

Also statt 32767 mit 32768?

[Amateur (Gast)]

Ich vergaß: Beim Aufruf von RTC_SetPrescaler(?).

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Jan schrieb:
> Was ich noch vergessen hatte: sobald ich die LED an PC13 nicht
> mehr
> benutzt habe, läuft der Takt ziemlich präzise. Ich kann bisher nach
> einem Tag keine (mit der Stoppuhr) messbare Abweichung erkennen. Ich
> denke mal alles was jetzt an Abweichung übrig bleibt ist akzeptable
> Toleranz und kann mit der internen Kalibrierung korrigiert werden.

Les Dir die Bemerkungen zu PC13-15 im Datenblatt genau durch:

5. PC13, PC14 and PC15 are supplied through the power switch. Since the 
switch only sinks a limited amount of current
   (3 mA), the use of GPIOs PC13 to PC15 in output mode is limited: the 
speed should not exceed 2 MHz with a maximum
   load of 30 pF and these IOs must not be used as a current source 
(e.g. to drive an LED).

[Dirk K. (dekoepi)]

Wieso liest eigentlich niemand die Posts durch vor dem Antworten? Hat 
Jan doch schon längst geschrieben, dass er die Quelle des Übels gefunden 
hat und dass das Minimalboard dort aufgrund der offenbar 
zugrundeliegenden Arduino-Idee eines "Pin13 für LED" kaputt designt ist:


Jan schrieb:

> Aber ich bin eben im Reference Manual über einen Hinweis gestolpert:
> "Due to the fact that the switch only sinks a limited amount of current
> (3 mA), the use of GPIOs PC13 to PC15 in output mode is restricted: the
> speed has to be limited to 2 MHz with a maximum load of 30 pF and these
> IOs must not be used as a current source (e.g. to drive a LED)."
>
> Sinnvollerweise ist auf meinem Evaluation Board die einzige LED genau an
> diesem Port PC13 angeschlossen. Ich hatte sie im Sekundentakt mitblinken
> lassen. Aufgefallen war mir, als ich versucht habe am Quarz mit dem Oszi
> mitzuhören, dass extreme Störungen im Sekundentakt auftreten.

[Flo (Gast)]

Hallo,
ich hatte genau das gleiche Problem. Bei mir lief der RTC Timer aber nur 
etwa halb so schnell wie gewünscht. Ich habe auch so ein China Board. 
Bei mir war die LED an PC13 auch schön am Blinken.

Ich war schon am verzweifeln, ich hatte schon mehrere Sachen versucht, 
z.B. auch den Quarz ausgelötet und nachgemessen.
Besonders auch weil der Code auf dem Discovery Board funktioniert hat 
und nur auf dem China Teil nicht richtig ging.

Nachdem ich PC13 "ausgeschaltet" hatte, ging es bei mir auch.

Vielen Dank, von allein wäre ich da nicht darauf gekommen. Ich hatte 
zwar auch im Datenblatt nachgelesen, aber nur unter RTC und Pin 
Konfiguration, nicht bei Backup Register :(

Vg
  Flo