STM32F103VDT6 Backup Register Vbat

[Ma B. (drumstick)]

Guten Tag!

Ich arbeite mit dem uVision von Keil und dem STM32F103VDT6.

Ich erfasse die Position meines Antriebs, die nach einem Stromausfall 
bekannt sein muss. Nun lade ich die Daten ins Backup Register. Dies 
Funktioniert prima! Doch nach einem Power Off sind die Daten verloren. 
ich habe eine Batterie 3V direkt an Vbat angeschlossen.

Ich speichere die Daten alle 50ms ins Backup Register. Und lese sie nur 
nach einem Power Up.

Ich benütze die StandartLib

/* Enable Backup Register */
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_BKP, ENABLE); 
  PWR_BackupAccessCmd(ENABLE);

Lesen:

set_MotorDistCounter(BKP_ReadBackupRegister(BKP_DR42));

Schreiben:

set_MotorDistCounterToBKP();

void set_MotorDistCounterToBKP(void)
{
  tsk_lock();
  NVIC_DisableIRQ(EXTI9_5_IRQn);     // External Interrupt 5, 6, 7, 8 and 9 are disable
  //BKP_DeInit();
  BKP_WriteBackupRegister(BKP_DR42, ihall_distance);
  NVIC_EnableIRQ(EXTI9_5_IRQn);      // External Interrupt 5, 6, 7, 8 and 9 are enable 
  tsk_unlock();
}

Habe ich etwas übersehen?

Dabnke und Gruss!
M.B.

[Ma B. (drumstick)]

Tja, es scheint so als ob ein Spannungsabfall an der Batterie beim 
Einschalten auf 1.2V für eine Zeitspanne von 28ns reicht, um das Backup 
Register zu löschen.

[Falk B. (falk)]

@  M. B. (drumstick)

>Tja, es scheint so als ob ein Spannungsabfall an der Batterie beim
>Einschalten auf 1.2V für eine Zeitspanne von 28ns reicht, um das Backup
>Register zu löschen.

Kaum. Wenn es kein prinzipieller Bug in dem IC ist, wird wohl deine 
Hardware oder Software das Problem sein. Meist muss die 
Backup-Geschichte einmalig per Software initialisiert werden.

[Ma B. (drumstick)]

Die 28ns entsprechen der Zeit, in der die Spannung an der Batterie unter 
1.8V fällt.

[Ma B. (drumstick)]

Ok.

Schreiben und lesen ins Backup funktioniert ohne Probleme. Nur nache dem 
Power off ist es weg!

[(prx) A. K. (prx)]

Kondensator?

[Ma B. (drumstick)]

Ja, die Batterie ist über einen Kondensator geschalten, der aber da 
falsch am Platz ist. Das erklärt den Spannungsabfall. Aber ich denke 
auch, dass dies nicht der Grund ist, dass die Daten nicht erhalten 
bleiben.? Aber sicher bin ich mir da nicht ganz.

Werde wohl den Kondensator entfernen!

[Falk B. (falk)]

@  M. B. (drumstick)

>Ja, die Batterie ist über einen Kondensator geschalten, der aber da
>falsch am Platz ist.

Wie meinst du das? Liegt der Kondensator parallel oder in Reihe zur 
Batterie? Hoffentlich nicht letzteres . . .

[Ma B. (drumstick)]

nein nein. Der Kondensator ist ein Fehler des Hardwareentwicklers. Das 
ich die Software trotzdem testen kann, habe ich parallel eine 3V 
Batterie angelötet!

[Ma B. (drumstick)]

Der Kondensator hat wirklich nicht gestört. Habe ihn entfernt und es 
funktioniert immer noch nicht!

[(prx) A. K. (prx)]

Zeig mal die Hardware, also Schaltung.

[Ma B. (drumstick)]

Wie erwähnt, über dem Kondensator parallel eine Batterie 3V (CR2025, 
Lithium von Energizer)

[(prx) A. K. (prx)]

Könnte der TAMPER Pin eine Rolle spielen?

[Ma B. (drumstick)]

A. K. schrieb:

>Könnte der TAMPER Pin eine Rolle spielen?

Note: Tamper detection is still active when VDD power is switched off. 
To avoid unwanted resetting
of the data backup registers, the TAMPER pin should be externally tied 
to the correct level.

Da ist eine gute Idee!

[Daniel H. (Firma: keine) (commander)]

Ich wollte es grad posten :D Dann mal viel Erfolg :)

[Ma B. (drumstick)]

Aber

Bit 1 TPAL: TAMPER pin active level
0: A high level on the TAMPER pin resets all data backup registers (if 
TPE bit is set).
1: A low level on the TAMPER pin resets all data backup registers (if 
TPE bit is set).
Bit 0 TPE: TAMPER pin enable
0: The TAMPER pin is free for general purpose I/O
1: Tamper alternate I/O function is activated.


wenn ich das jetzt richtig verstanden habe. Sollte es so stimmen und im 
Debugger wird nie ein Bit gesetzt?!

[Ma B. (drumstick)]

denke ist eher dies gemeint:

Bit 8 TEF: Tamper event flag
This bit is set by hardware when a Tamper event is detected. It is 
cleared by writing 1 to the
CTE bit.
0: No Tamper event
1: A Tamper event occurred
Note: A Tamper event resets all the BKP_DRx registers. They are held in 
reset as long as the
TEF bit is set. If a write to the BKP_DRx registers is performed while 
this bit is set, the
value will not be stored.

[(prx) A. K. (prx)]

M. B. schrieb:
> Die 28ns entsprechen der Zeit, in der die Spannung an der Batterie unter
> 1.8V fällt.

Ist das Bild mit Kondensator parallel zur Batterie gemessen? Das wäre 
schon etwas krass, jedenfalls wenn Kerko.

[Ma B. (drumstick)]

Ja, parallel gemessen!

[Willi (Gast)]

A. K. schrieb:
> Ist das Bild mit Kondensator parallel zur Batterie gemessen? Das wäre
> schon etwas krass, jedenfalls wenn Kerko.

Ich glaube, das Schaltibild zeigt nicht den Schaltungsaufbau.
Ich vermisse 100nF!

[(prx) A. K. (prx)]

Kerko? Erklär mir bitte mal jemand, wie dann ein solcher Einbruch 
möglich ist, wenn die Schaltung stimmt, das Layout nicht katastrophal 
ist und sich der Tastkopf nicht irgendeinen Käse einfängt.

[Falk B. (falk)]

@  A. K. (prx)


wenn die Schaltung stimmt,
wenn das Layout nicht katastrophal
ist
 und wenn sich der Tastkopf nicht irgendeinen Käse einfängt.

Dreimal wenn, das geht ja nun wirklich nicht ;-)

[Ma B. (drumstick)]

- Schaltschema stimmt
- Layouter 28 Jahre Erfahrung
- Messaufbau: Batterie 3cm Entfernung zum Print. Verbindung 
lackisolierter Kupferdraht direkt auf die Pads des Kondensators gelötet

Punkt 3 ist am wahrscheinlichsten!

[Ma B. (drumstick)]

void BKP_ClearFlag(void)
{
  /* Set CTE bit to clear Tamper Pin Event flag */
  BKP->CSR |= BKP_CSR_CTE;
}

bevor ich ins bkp_dr schreibe.


hat nichts gebracht, aber ich habe im Layout festgestellt, dass der 
Tamper Pin PC13 in der Luft hängt!

[(prx) A. K. (prx)]

M. B. schrieb:
> Bit 0 TPE: TAMPER pin enable
> 0: The TAMPER pin is free for general purpose I/O

Das ist der interessantere Teil.

[Ma B. (drumstick)]

A. K. schrieb:

>M. B. schrieb:
>> > Bit 0 TPE: TAMPER pin enable
>> > 0: The TAMPER pin is free for general purpose I/O

> Das ist der interessantere Teil.

bedeutet, wenn TPE 0 ist, ist es frei für I/O zur Verfügung!

[(prx) A. K. (prx)]

Eben. Ist es 0?

[Ma B. (drumstick)]

meine Init:

/* Enable Backup Register */
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_BKP, ENABLE);
  BKP_TamperPinCmd(DISABLE);

Auch im Debugger ist dieser Pin immer 0!

[Ma B. (drumstick)]

Init:

/* Enable Backup Register */
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_BKP, ENABLE);
  BKP_TamperPinCmd(DISABLE);

schreiben:

PWR_BackupAccessCmd(ENABLE);
BKP_WriteBackupRegister(BKP_DR42, ihall_distance);
PWR_BackupAccessCmd(DISABLE);

lesen:

PWR_BackupAccessCmd(ENABLE);
set_MotorDistCounter(BKP_ReadBackupRegister(BKP_DR42));
PWR_BackupAccessCmd(DISABLE);

[Ma B. (drumstick)]

M.B. schrieb:



> meine Init:

>

/* Enable Backup Register */
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_BKP, ENABLE);
  BKP_TamperPinCmd(DISABLE);

> Auch im Debugger ist dieser Pin immer 0!


Habe folgendes versucht:

BKP_TamperPinCmd(ENABLE);

Bit bleibt 0!!

[(prx) A. K. (prx)]

Wenn man die wahrscheinlich scheinenden Ursachen ausgeschlossen hat, 
dann sollte sich an den Gedanken gewöhnen, sich mit den als 
unwahrscheinlich oder ausgeschlossen betrachteten Ursachen beschäftigten 
zu müssen.

[Willi (Gast)]

A. K. schrieb:
> Wenn man die wahrscheinlichen scheinenden Ursachen ausgeschlossen hat,
> dann sollte sich an den Gedanken gewöhnen, sich mit den als
> unwahrscheinlich oder ausgeschlossen betrachteten Ursachen beschäftigten
> zu müssen.

Das ist für mich die immer noch nicht richtig abgeblockte Spannung Vbat.
Nie und Nimmer könnte sonst das Oszilloskope oben gezeigtes Bild 
liefern. Vielleicht rechnet mal jemand die notwendigen Stöme in einem 
100nF X7R C aus, um die gezeigten Anstiegs- und Abfallzeiten zu 
erhalten. Ohne zu rechnen: diese könnte ein µC-Pin überhaupt nicht 
liefern!

[Ma B. (drumstick)]

Ein Bug?
Meine Unfähigkeit?
Hardwaredefekt?
Hat das überhaupt schon Jemand mit einem stm32f103vdt6 geschafft?

Ja, langsam bin ich so weit!

Aber wenn alles immer sofort laufen würde, würde es ja auch keinen Spass 
machen ;-)


ratlosratlosratlos

[(prx) A. K. (prx)]

Willi schrieb:
> Ohne zu rechnen: diese könnte ein µC-Pin überhaupt nicht
> liefern!

Ausserdem fresse ich einen Besen wenn der Vdd/Vbat Power Switch im Chip 
auch nur nennenswerte Milliamperes durchreichen kann.

[Ma B. (drumstick)]

Warning:

During tRSTTEMPO (temporization at VDD startup) or after a PDR
is detected, the power switch between VBAT and VDD remains
connected to VBAT.
During the startup phase, if VDD is established in less than
tRSTTEMPO (Refer to the datasheet for the value of tRSTTEMPO)
and VDD > VBAT + 0.6 V, a current may be injected into VBAT
through an internal diode connected between VDD and the
power switch (VBAT).
If the power supply/battery connected to the VBAT pin cannot
support this current injection, it is strongly recommended to
connect an external low-drop diode between this power
supply and the VBAT pin.

tRSTTEMPO Min: 1  Typ: 2.5   MAX: 4.5  ms


Habe eine neue Spur!

[(prx) A. K. (prx)]

Falsche Richtung. Dioden pflegen nur in eine Richtung zu leiten. Das ist 
nur ein Problem für deine Batterie, wenn sie von jener Sorte ist, die 
schon bei geringem Ladestrom schaden nimmt.

[Ma B. (drumstick)]

Eine Diode zwischen Vdd und Vbat in Richtung Vbat koppelt beim switch 
Vbat richtig von Vdd ab. Ich denke schon, dass dies ein Problem sein 
könnte!?

[Ma B. (drumstick)]

bzw. eine Lösung sein könnte!?

[Ma B. (drumstick)]

A. K. schrieb:

> Mir scheint eher, dass du den verlorenen Schlüssel unter der Laterne
> suchst, weil es dort, wo er tatsächlich verloren ging, zu dunkel ist.

ja, Du hast sicher nicht ganz unrecht. Ich suche natürlich weiter, bis 
die Hardware angepasst wurde. Es kam halt eine Spur Hoffnung auf, das 
Problem gefunden zu haben.

Danke für Deine Unterstützung!

[Ma B. (drumstick)]

So, habe ein Demoprogramm erstellt ,das auf dem EVAL MCBSTM32C läuft:

#include <RTL.h>
#include <stdlib.h>
#include <stdint.h>
#include "stm32f10x.h"

void init(void)
{
  /* Enable Backup Register */
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_BKP, ENABLE);
  BKP_TamperPinCmd(DISABLE);  
}

int main (void)
{
   init();
  while(1)
  {
    PWR_BackupAccessCmd(ENABLE);
    BKP_ClearFlag();
    BKP_WriteBackupRegister(BKP_DR1, 0x00000005);
    PWR_BackupAccessCmd(DISABLE);
  };
}

Danach ziehe ich den Stecker vom Board. Wenn ich den Stecker wieder 
anschliesse und den Debugger starte, steht der Wert 0x05 im DR1. Ich 
habe noch den Schemaausschnitt des Boards angehängt.

Es scheint also zu funktionieren!

Der Unterschied zum Board, die haben den Tamper auf 3V angeschlossen für 
den Taster meiner hängt in der Luft. Habe ihn jedoch softwaremässig 
ausgeschalten.

[Ma B. (drumstick)]

Noch ein Unterschied vom Board zu meiner Hardware:

Auf dem Board ist ein STM32F107VCT6 und auf meinem Print ist ein 
STM32F103VDT6.

Aber sonst kommt mir wirklich nichts mehr in den Sinn, es läuft einfach 
nicht!

[Dirk (Gast)]

Hast du schon mal den den Prozessor getauscht? Deiner scheint im Eimer 
zu sein, warum auch immer. Ansonsten kannst du lange rumsuchen.

[Ma B. (drumstick)]

Das habe ich schon probiert, ohne Erfolg!

Ich lade die Daten alle 50ms in BKP und verfolge dies im Debugger, dann 
ziehe ich den Stecker. Schliesse den Stecker wieder an, starte den 
Debugger. BKP Register ist leer bzw. 0.

[Ma B. (drumstick)]

Folgendes habe ich jetzt probiert. Mein Demoprogramm den uP von meiner 
Hardware geladen, Device angepasst.

Programm laufen gelassen, Wert 5 im BKP. Stecker gezogen und wieder 
angeschlossen. Dann Debugger gestartet und siehe da, wert 5 im BKP.

Jetzt siehts eher wieder nach einem Programmierfehler aus. Was alles 
kann das BKP reseten?

Danke und Gruss!

M.B.

[Ma B. (drumstick)]

Hi,

ich schreibe per Tastendruck ins Backup RAM Register DR1. Nach einem
Poweron schreibe ich den Wert vom BKP zurückt in die Zählervariable.

Am Vbat, der nach einem Spannungsabfall an Vdd per internem Switch
automatisch zugeschalten wird, hängt ein Kondensator mit einer Diode.
Nach einem Poweroff beträgt die Spannung am Kondensator 2.68V.

Das Problem nun ist, dass nach einem Poweroff die Daten im BKP Ram
verloren gehen.

Ich verwende die StandartLib.

Mein Code:

#include <RTL.h>
#include <stdlib.h>
#include <stdint.h>
#include "stm32f10x.h"

#define PIN_MOT_Enable_BASE  GPIOD_BASE
#define PIN_MOT_Enable_PIN   11
#define PIN_MOT_Enable_PIN2  12


void init(void)
{
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO, ENABLE);
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOD, ENABLE);
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOE, ENABLE); 
}

int main (void)
{
  init();
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_BKP, ENABLE);
  PWR_BackupAccessCmd(ENABLE);
  BKP_ClearFlag();
  
  if(RCC_GetFlagStatus(RCC_FLAG_PORRST) != RESET)
  {
    /* Clear reset flags */
    RCC_ClearFlag();
    if(BKP_ReadBackupRegister(BKP_DR1) == 0)
    {
      
    }
    else
    {
      PWR_BackupAccessCmd(ENABLE);
      BKP_WriteBackupRegister(BKP_DR1, 0x0000000C);
      PWR_BackupAccessCmd(DISABLE);
    }
  }
  while(1)
  {
    if((GPIO_ReadInputDataBit((GPIO_TypeDef *) PIN_MOT_Enable_BASE, (1 << PIN_MOT_Enable_PIN)) == 0))
    {
      PWR_BackupAccessCmd(ENABLE);
      BKP_WriteBackupRegister(BKP_DR1, 0x00000005);
      PWR_BackupAccessCmd(DISABLE);
    }

    if((GPIO_ReadInputDataBit((GPIO_TypeDef *) PIN_MOT_Enable_BASE, (1 << PIN_MOT_Enable_PIN2)) == 0))
    {
      PWR_BackupAccessCmd(ENABLE);
      BKP_WriteBackupRegister(BKP_DR1, 0x0000000B);
      PWR_BackupAccessCmd(DISABLE);
    }
      
  };
}

Hat schon mal Jemand so etwas gemacht, oder sieht Jemand meinen Fehler?

Vielen Dank und freundliche Grüsse!

M.B.

[Ma B. (drumstick)]

Habe ich das richtig verstanden, wenn ich nur Daten im BKP speichern 
möchte, muss ich das RTC nicht initialisieren?

Danke und Gruss!

M.B.

[Ma B. (drumstick)]

Erstaunlich, dass ich der erste bin, der das BKP so einsetzt!

[Mechthild (Gast)]

M. B. schrieb:
> Erstaunlich, dass ich der erste bin, der das BKP so einsetzt!

Irgendjemand muss den Anfang machen und vorangehen. In den STM32-Foren 
weltweit wird der Ausgang dieses Abenteuers schon mit Spannung erwartet. 
Also, halte durch!

[Ma B. (drumstick)]

Es nervt mich einfach, weil ich das ganze Power Down Reset und Power On 
reset nicht ganz verstehe und ob ich für den Vbatvom externen zum 
internen Clock wechseln muss?



@ Mechthild: Schwer verständlicher Sarkasmus!

Klar würde ich durchhalten bis zum bitteren Ende! Nur, das Ende wird 
heute sein, denn Morgen muss es laufen! Ich habs versucht!
Um die ganze Materie zu verstehen benötigt man viel mehr Zeit, als ich 
gedacht habe. Das heisst nicht, das ich dachte, es wird einfach! Aber, 
wenn man etwas neues macht, kann man nicht alles immer richtig 
einschätzen. Wer nichts wag gewinnt nichts.

trotzdem war das Forum immer eine grosse Hilfe, vielen Dank!

Grüsse!

M.B.

[Mechthild (Gast)]

M. B. schrieb:
> trotzdem war das Forum immer eine grosse Hilfe, vielen Dank!

Probiere es doch noch mal in spezialisierten Foren, z.B.:

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/AllItems.aspx

[Ma B. (drumstick)]

Warum wird der Power Down / Power Up Reset nur gesetzt, wenn ganz kurz 
die Spannung weg gefallen ist?

[Ma B. (drumstick)]

Kann sich jemand vorstellen, welchen Teil einer Initialisierung den 
BKP_DR reseten könnte?

- Clock Einschalten
- BKP_ClearFlag
- BackupAccessCmd
- ect.

Danke und Gruss!

M.B.

[Matthias K. (matthiask)]

Ich verwende die Backupregister auch ohne Probleme regelmäßig. 
Allerdings immer im Zusammenhang mit dem RTC und einen entsprechenden 
Uhren-Quarz. Auch habe ich die PVR Funktion aktiviert.

Ich benutze nach Taktfreigabe für die BKP Unit ein:
BKP_DeInit();                   // Backup-Register auf Standardwerte
um sicher zu stellen, dass die Anfangswerte in den Registern stehen.

Weiterhin lasse ich nach:

PWR_BackupAccessCmd(ENABLE);

die BKP Unit in Ruhe, gebe also niemals ein DISABLE.

Die Backupregister beschreibe und lese ich allerdings nur im 
Zusammenhang mit dem synchronisierten RTC also nach einem 
RTC_WaitForLastTask();

[Ma B. (drumstick)]

Guten Tag!

Ich möchte mit einer Power Voltage Detection von Vdd auf Vbat
umschalten. Im Referenzmanual Figur 4, ist abgebiltet, dass mit einem
PVD auf Vbat umschalten kann. In der Funktionsbeschreibung steht aber
niergends, dass es umschaltet sobals ein PVD eingeschalten ist?

Danke und Gruss!

M.B.

[Matthias K. (matthiask)]

Wie Du in dem neuen Beitrag fragst, solltest Du Dich nochmal näher mit 
den Möglichkeiten der STM32 Familie beschäftigen. Ich benutze die PVR 
Funktion so:

RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR,   ENABLE);         // POWER Takt 
PWR_PVDCmd(ENABLE);                       // Power Voltage Detector freigeben
PWR_PVDLevelConfig(PWR_PVDLevel_2V9);     // auf 2.9V einstellen BSP.

...

 // Externer Interruptcontroller EXTI-16 (intern PVD zugeordnet) freigeben
  EXTI_ClearITPendingBit(EXTI_Line16 );
  EXTI_InitStructure.EXTI_Mode = EXTI_Mode_Interrupt;
  EXTI_InitStructure.EXTI_Line = EXTI_Line16;
  EXTI_InitStructure.EXTI_Trigger = EXTI_Trigger_Rising; // Auslösung VDD < PVD Vergleichsspannung
  EXTI_InitStructure.EXTI_LineCmd = ENABLE;
  EXTI_Init(&EXTI_InitStructure);


  // PVD Interrupt
  NVIC_InitStructure.NVIC_IRQChannel = PVD_IRQn;
  NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 1;
  NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
  NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
  NVIC_Init(&NVIC_InitStructure);

...

// PVD Interrupt-Handler
// Power-Voltage-Detector - löst aus, wenn die VDD/VAA unter die eingestellte Vergleichsspannung
// fällt (optional auch darüber/beides). PVD ist EXTI-16 intern zugeordnet. EXTI-16
// muss entsprechend konfiguriert werden.
//***********************************************************************************************
void PVD_IRQHandler (void) {
  // PWR_PVDCmd(DISABLE);
  EXTI_ClearITPendingBit(EXTI_Line16);  // Bestätigungsbit EXTI
  NVIC_ClearPendingIRQ(PVD_IRQn);       // Bestätigungsbit PVD
  PVDFunktion();                        // Hier gezielt sichern und System runterfahren
}

[(prx) A. K. (prx)]

M. B. schrieb:
> Im Referenzmanual Figur 4, ist abgebiltet, dass mit einem
> PVD auf Vbat umschalten kann.

5.1.2: "The switch to the VBAT supply is controlled by the Power Down 
Reset embedded in the Reset block."

Der PVD scheint mir eine separate Komponente zu sein.

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Da musst Du 5.1.2 lesen, die extra dick geschriebene Warning.

[Ma B. (drumstick)]

@ Matthias K.:

Vielen Dank für die Hilfe.

Ich habe den Versuch gestartet, die BKPs auch im Zusammenhang mit dem 
RTC zu verwenden. Ohne grossen Erfolg. Ausserdem versuche ich noch mit 
einem PVD, dass switchen auf Vbat frühzeitig sicher zu stellen.

Meine Init:

/* Enable Backup Register */
   RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);
   RCC_APB1PeriphClockCmd(RCC_APB1Periph_BKP, ENABLE);
   BKP_TamperPinCmd(DISABLE);
   BKP_DeInit();
   PWR_BackupAccessCmd(ENABLE);

/* Enable RTC Register */
   RCC_LSEConfig(RCC_LSE_ON);
  while(RCC_GetFlagStatus(RCC_FLAG_LSERDY) == RESET)
  {
  }
  RCC_RTCCLKConfig(RCC_RTCCLKSource_LSE);
  RCC_RTCCLKCmd(ENABLE);
  RTC_WaitForSynchro();
  RTC_WaitForLastTask();
  RTC_ITConfig(RTC_IT_SEC, ENABLE);
  RTC_WaitForLastTask();  
  RTC_SetPrescaler(32767);
  RTC_WaitForLastTask();

/* Enable PVD Register */
  PWR_PVDCmd(ENABLE);
  PWR_PVDLevelConfig(PWR_PVDLevel_2V9);

Nach einem erneuten einschalten, ist das BKP resetet und das RTC CNT 
Register 0.

[(prx) A. K. (prx)]

Markus Müller schrieb:
> Da musst Du 5.1.2 lesen, die extra dick geschriebene Warning.

Kennt er schon, siehe oben. Das ist eine andere Baustelle, denn Strom 
von Vdd nach Vbat dürfte höchstens für eine genervte Lithium-Batterie 
sorgen, nicht aber für einen temporären Ausfall von Vbat oder der 
Backup-Domain.

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Ich glaube den BKP_DeInit(); darf nicht ausgeführt werden, denn der 
resetet alles.
Schaue aber nach was der genau macht.

[Matthias K. (matthiask)]

Markus Müller schrieb:
> Ich glaube den BKP_DeInit(); darf nicht ausgeführt werden, denn der
> resetet alles.

Macht es. Es kommt drauf an, wenn man BKP_DeInit(); aufruft. Am Anfang 
der Initialisierungsphase sorgt es auch dafür, das die Register der Unit 
die richtigen Anfangswerte haben. Bei den vielen AND und OR der FW-Lib 
hatte ich bei anderen Units ohne DeInit()'s schon Probleme. Muss aber 
nicht unbedingt auf die BKP zutreffen.

[Matthias K. (matthiask)]

M. B. schrieb:
> RCC_LSEConfig(RCC_LSE_ON);

Hast Du denn überhaupt einen LSE Quarz angeschlossen?

[Willi (Gast)]

M. B. schrieb:
> Tja, es scheint so als ob ein Spannungsabfall an der Batterie beim
> Einschalten auf 1.2V für eine Zeitspanne von 28ns reicht, um das Backup
> Register zu löschen.

Habe ich es überlesen und hast Du dieses Problem denn schon gelöst, oder 
ignorierst Du es einfach?
Sollte es die tatsächliche Fehlerquelle sein, kannst Du an den Registern 
weiterhin erfolglos 'herumspielen'.

[Ma B. (drumstick)]

Nee, das muss HSE heissen. DANKE. Habe einen externen 25MHz Osz.

main:

int main (void) {

  GP_I_O_Init();                // the function GP_I_O_Init is call
  Motor_Init();                 // the function Motor_Init is call 
  Timer_Init();
  PWR_BackupAccessCmd(ENABLE);
  
  if(BKP_ReadBackupRegister(BKP_DR42) != 0xFEAF)   
  {
    RTC_Config();
    BKP_WriteBackupRegister(BKP_DR42, 0xFEAF);
    
  }
  else
  {
    RTC_WaitForSynchro();
    RTC_ITConfig(RTC_IT_SEC, ENABLE);
    RTC_WaitForLastTask();
  }

  
  os_sys_init (tsk_init_bknd);  // Initialize RTX and start init   
}

RTC_Config

void RTC_Config(void)
{
  /* Enable Backup Register */
   RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);
   RCC_APB1PeriphClockCmd(RCC_APB1Periph_BKP, ENABLE);
   BKP_TamperPinCmd(DISABLE);
     RCC_HSEConfig(RCC_HSE_ON);
   while(RCC_GetFlagStatus(RCC_FLAG_HSERDY) == RESET)
   {
   }
   RCC_RTCCLKConfig(RCC_RTCCLKSource_HSE_Div128);
   RCC_RTCCLKCmd(ENABLE);
   RTC_WaitForSynchro();
   RTC_WaitForLastTask();
   RTC_ITConfig(RTC_IT_SEC, ENABLE);
   RTC_WaitForLastTask();  
   RTC_SetPrescaler(25000);
   RTC_WaitForLastTask();
}

[Ma B. (drumstick)]

@ Willi:

Aus diesem Grund hatte ich ein Testprogramm für das MCBSTM32C Board 
geschrieben, und es funktioniert auch nicht! Ausser es wäre ein Hardware 
und Softwareproblem. wo ja auch nicht unmöglich wäre.

[Falk B. (falk)]

Die ARMs von ST sind ja soooo tooooll ;-)

Lästerliche Grüße eines niederen 8-Bitter

[Willi (Gast)]

M. B. schrieb:
> Aus diesem Grund hatte ich ein Testprogramm für das MCBSTM32C Board
> geschrieben, und es funktioniert auch nicht! Ausser es wäre ein Hardware
> und Softwareproblem. wo ja auch nicht unmöglich wäre.

Was willst Du damit sagen?
Ich weiß immer noch nicht, ob bei Dir die Spannung an Vbat nun frei von 
Spannungseinbrüchen ist.

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Welche Revision hat Dein Prozessor?

Ich hatte letztens auch enorme Probleme mit einem STM32F417VG.
Die Revision A hatte alle möglichen Probleme, zu viel Stromverbrauch der 
Batterie bis hin zum Datenverlust.

Als ich die Revision Z einlötete waren die Probleme beseitigt.

Im Errata stand nichts.

Wenn das mit dem STM32F103 nicht klappt, empfehle ich den STM32F4xx, den 
bei dem wurde einiges in der Peripherie erweitert und deutlich 
verbessert.
Abgesehen davon hat der auch 4KB Backup-RAM.

[Falk B. (falk)]

@  Markus Müller (mmvisual)

>Welche Revision hat Dein Prozessor?

>Die Revision A hatte alle möglichen Probleme, zu viel Stromverbrauch der
>Batterie bis hin zum Datenverlust.

>Als ich die Revision Z einlötete waren die Probleme beseitigt.

WOW! ST hat nur 25 Revisionen gebraucht, um das Ding bugfrei zu 
bekommen. RESPEKT! ;-)

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Nein, Rev B..Y gibt es nicht.

[(prx) A. K. (prx)]

Das Z signalisiert bloss, dass es die garantiert ein für alle Mal letzte 
ist - jeder Bug darin bleibt drin. ;-)

[Ma B. (drumstick)]

Danke, guter Hinweis. Habe Revision "Z" ! :-(

[Simon (Gast)]

Ich hatte über die letzten Tage ein ähnliches Problem. Ich nutze das 
Olimex P-103 Board.
Ich wollte Daten im Backup-Register halten, sobald die Versorgungsspg. 
weg fällt. Ich habe eine Buffer-Batterie an VBat angeschlossen und zuvor 
die Verbindung (Löt-Jumper) zur restlichen +3V3 getrennt.

Leider war das Backup-Register meistens zurückgesetzt (=0), nachdem ich 
die Versorgungs-Spg. kurz unterbrochen hatte. Leider war dieses Phänomen 
auch nicht immer ersichtlich... Nur ein Reset über den HW-Button zeigte 
ein richtiges Verhalten.

---> Lösung: Ein 100nF Kondensator parallel zur Batterie.

[Matthias (Gast)]

Simon schrieb:
> ---> Lösung: Ein 100nF Kondensator parallel zur Batterie.

Genau wegen diesem Kondensator bin ich auf den Thread hier gestoßen. In 
den ganzen ANs wird der weggelassen, ich habe hier gerade ein Design, wo 
ich ihn einfach vergessen hab, ohne drüber nachzudenken.
Kann das ein Problem werden? Könnte den notfalls hässlich mit dazulöten. 
Habt ihr da weitere Erfahrung?

Was ist außerdem mit dem Ladestrom? Ich hab ne schnell ansteigende Vdd, 
sicher unter 1ms. An VBat hängt eine CR2032. Laut diverser Datenblätter 
(Ich habe die Panasonic Manganese Dioxide Lithium Coin Batteries) sind 
maximal 10 mA zugelassen, vermutlich damit nichts ausläuft oder so. Und 
man soll im Leben maximal 3% nachladen. Leider finde ich zum 
STM32L476VGT6, den ich einsetze, keine Spezifikation der Höhe des 
möglichen Rückwärtsstroms... Es ist ja davon auszugehen, dass die Diode 
relativ schwach ist. Eine entsprechende Messmöglichkeit fehlt mir hier 
auch. Gibts da Erfahrungswerte?

Danke euch!