STM32F4xx - Backup Ram verliert Inhalte

[Christian J. (Gast)]

Moin... gähn

Ich suche mich in meinem Projekt tot, warum "auf einmal" das Backup Ram 
seinen Inhalt verliert, wenn ich die Stromversorgung wegnehme. Klar, 3V 
Batterie ist dran an Vbat, Platine ist umgelötet. Alles auch 
nachgemessen, an Vbar liegen die 3V. Die RTC läuft auch einwandfrei 
weiter, wenn ich den USB Stecker abziehe. Es lief auch mal aber jetzt 
eben nicht mehr nachdem das Programm erweitert wurde.

Damit wird es aktiviert.

/* Enable SRAM Backup Register */
    RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);         // Power 
für RTC/Backup RAM
    RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_BKPSRAM, ENABLE);     // 
Backup RAM mit Clock versorgen
    PWR_BackupAccessCmd(ENABLE);

Und das bleibt auch so.

Im Debugger auch alles gecheckt, schaltet man bei einigen DISABLE ein, 
"verschwindet" das Backup RAM auch wieder, beim ersten Befehl bleibt 
auch die Uhr stehen.

Druck auf RESET Knopf lässt alles wie es ist, das RAM behält seine 
Inhalte, die Anwendung erkennt das auch, da ich eine ID im Ram abgelegt 
habe, die abgefragt wird.

Mir fällt nichts mehr ein.... wieso kann das RAM seinen Inhalt noch 
verlieren? Das lief doch vorher :-( Oder habe ich durch 1000 Mal flashen 
die CPU geschossen? Leider kein Ersatzboard derzeit. Bin drauf und dran 
ein E2PROM einzubauen oder einen Sektor des Flash als E2PROM zu 
missbrauchen, da weiss man wenigstens was man hat.

[Harald (Gast)]

Idee dazu:
- Brown-Out Detection vom Prozessor benutzt, damit dieser im letzten 
Moment keinen Blödsinn macht?
- gibt es einen Write-Enable Pin, den man an einen Prozessorpin legen 
könnte. Beim Reset bzw. BrownOut würde dann sofort per internen Pull-Up 
an den IOs ein weiteres Schreiben verhindert.

[Harald (Gast)]

Ah, OK - internes RAM. Also kein WriteEnable Signal. Die BrownOut Idee 
bleibt aber.

[Christian J. (Gast)]

Harald schrieb:

> Idee dazu:
> - Brown-Out Detection vom Prozessor benutzt, damit dieser im letzten
> Moment keinen Blödsinn macht?
> - gibt es einen Write-Enable Pin, den man an einen Prozessorpin legen
> könnte. Beim Reset bzw. BrownOut würde dann sofort per internen Pull-Up
> an den IOs ein weiteres Schreiben verhindert.

Verstehe ich nicht ganz.

Habe zu dem Thema gegoogelt, es passierte einigen schon auch hier. Es 
kann ja nicht sein, dass die Uhr einwandfrei weiterläuft, auch deren 
Backup Register 00 bis 0x19 überleben einwandfrei die Wegnahme der CPU 
Spannung und nur das 4K Backup Ram ist gelöscht.

Ich warte mal auf das neue Board, evtl. ist ja die CPU auch beschädigt 
worden bei dem Rumbasteln.

[Georg (Gast)]

Christian J. schrieb:
> nur das 4K Backup Ram ist gelöscht

Was verstehst du denn darunter? Nachher 4096 mal 00?

Georg

[Christian J. (Gast)]

Georg schrieb:

> Was verstehst du denn darunter? Nachher 4096 mal 00?

Nein, Zufallszahlen, alles durcheinander. Nur die RTC Register sind wie 
vorher, also Strom hat der Hobel.

[eagle user (Gast)]

Das Backup RAM hat einen eigenen Low Power Spannungsregler den man extra 
einschalten muss. Der wird nur bei Batteriebetrieb benutzt, im normalen 
Betrieb wird das RAM vom Core versorgt.

Wenn du verraten würdest, welchen F4xx du hast, könnte man im Reference 
Manual nach dem passenden Bit suchen...

[Christian J. (Gast)]

eagle user schrieb:
> Wenn du verraten würdest, welchen F4xx du hast, könnte man im Reference
> Manual nach dem passenden Bit suchen...

STM32F407VG

[Christian J. (Gast)]

Reicht das nicht?

/* Enable SRAM Backup Register */
    RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);         // Power
für RTC/Backup RAM
    RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_BKPSRAM, ENABLE);     //
Backup RAM mit Clock versorgen
    PWR_BackupAccessCmd(ENABLE);

Ab dem 2.ten Befehl sieht man im Debugger das RAM sofort.

[eagle user (Gast)]

Ich meinte das Bit BRE (Bit 9) im PWR_CSR Register. Nachdem man nicht 
weiß, was PWR_BackupAccessCmd(ENABLE) macht (oder ob irgendwer das Bit 
zurücksetzt) solltest du mal direkt das PWR_CSR kontrollieren. Genau 
genommen muss auch das Bit BRR "Backup Regulator Ready" (Bit 3) gesetzt 
sein.

Solange der Debugger verbunden ist, wird das Backup RAM direkt versorgt, 
nicht über diesen Backup Spannungsregler, deshalb geht's dann immer.

[Christian J. (Gast)]

eagle user schrieb:

> Ich meinte das Bit BRE (Bit 9) im PWR_CSR Register. Nachdem man nicht
> weiß, was PWR_BackupAccessCmd(ENABLE) macht (oder ob irgendwer das Bit
> zurücksetzt) solltest du mal direkt das PWR_CSR kontrollieren. Genau
> genommen muss auch das Bit BRR "Backup Regulator Ready" (Bit 3) gesetzt
> sein.
>
> Solange der Debugger verbunden ist, wird das Backup RAM direkt versorgt,
> nicht über diesen Backup Spannungsregler, deshalb geht's dann immer.

Dank dir für den Tip. Grad reingeschaut, das ist ja ein Krampf mit den 
ganzen Bits da drin. Hatten die nichts zu tun bei ST oder gibts pro 
Bit-Erfindung ne Prämie?

Heute abend mal reinschauen, ob die Bits alle so rumtoggeln wie sie 
sollen...

Sind die Register direkt zugänglich, ohne dass ich die StdperophLib 
verwenden muss, also zb

PWR_CS->BRE = ....

oder

PWR_CS | = (1 << BRE)

oder ähnlich?

[Christian J. (Gast)]

Nett, wenn man per ftp von der Arbeit zu Hause was holen kann :-)

Da haben wir sie ja schon....

/*******************  Bit definition for PWR_CSR register 
********************/
#define  PWR_CSR_WUF                         ((uint32_t)0x00000001) 
/*!< Wakeup Flag                                      */
#define  PWR_CSR_SBF                         ((uint32_t)0x00000002) 
/*!< Standby Flag                                     */
#define  PWR_CSR_PVDO                        ((uint32_t)0x00000004) 
/*!< PVD Output                                       */
#define  PWR_CSR_BRR                         ((uint32_t)0x00000008) 
/*!< Backup regulator ready                           */
#define  PWR_CSR_WUPP                        ((uint32_t)0x00000080) 
/*!< WKUP pin Polarity                                */
#define  PWR_CSR_EWUP                        ((uint32_t)0x00000100) 
/*!< Enable WKUP pin                                  */
#define  PWR_CSR_BRE                         ((uint32_t)0x00000200) 
/*!< Backup regulator enable                          */
#define  PWR_CSR_VOSRDY                      ((uint32_t)0x00004000) 
/*!< Regulator voltage scaling output selection ready */
#define  PWR_CSR_ODRDY                       ((uint32_t)0x00010000) 
/*!< Over Drive generator ready                       */
#define  PWR_CSR_ODSWRDY                     ((uint32_t)0x00020000) 
/*!< Over Drive Switch ready                          */
#define  PWR_CSR_UDSWRDY                     ((uint32_t)0x000C0000) 
/*!< Under Drive ready                                */

[Christian J. (Gast)]

Sooo.......

Dann kommt hier mal die Auflösung, an der wahrscheinlich schon mancher 
graue Haare bekommen hat...tatatataaaa.

Um das Backup Ram zu benutzen muss folgende Sequenz herhalten bei 
Verwendung der StdPeripLib 1.6.1

/* Enable SRAM Backup Register */
    RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE); 
    RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_BKPSRAM, ENABLE);
    PWR_MainRegulatorModeConfig(PWR_Regulator_Voltage_Scale1);
    PWR_WakeUpPinCmd(ENABLE);
    PWR_BackupRegulatorCmd(ENABLE);
    while(PWR_GetFlagStatus(PWR_FLAG_BRR) == RESET);
    PWR_BackupAccessCmd(ENABLE);

BRE laesst sich erst setzen, wenn das EWUP Bit gesetzt wurde. Zufall 
dass ich das rausgefunden habe.

Und dann ist der BKRAM Inhalt beim Power Off/on auch wieder da :-))))

Danke Dir !

[Tassilo H. (tassilo_h)]

Christian J. schrieb:
> BRE laesst sich erst setzen, wenn das EWUP Bit gesetzt wurde. Zufall
> dass ich das rausgefunden habe.

Warum sollte das so sein? Steht das irgendwo im Datenblatt?. Waere ja 
unpraktisch, wenn man den WKUP-Pin nicht braucht (oder PA0 fuer was 
anderes braucht).

[Christian J. (Gast)]

Tassilo H. schrieb:
> Warum sollte das so sein? Steht das irgendwo im Datenblatt?. Waere ja
> unpraktisch, wenn man den WKUP-Pin nicht braucht (oder PA0 fuer was
> anderes braucht).

k.A. Ist jedenfalls so, BRE lässt sich bei mir nur setzen, wenn vorher 
EWUP gesetzt worden ist. Tja...

Sag mal, gibt es da ein Standardverfahren diese Bits zu setzen, außer 
den PeriphLib Funktionen?

[Tassilo H. (tassilo_h)]

Also bei mir sieht das für die RTC so aus wie unten gezeigt, Backup-RAM 
ist noch nicht verwendet, soll aber noch, deshalb bin ich auf diesen 
Thread aufmerksam geworden.
Ich verwende direkten Registerzugriff (abgesehen vom clock enable, 
anfangs hab' ich noch die Lib verwendet, bis mir aufgefallen ist, daß 
das für viele Dinge unübersichtlicher ist als direkter Registerzugriff 
und auch nicht portabler). So kann ich den Code wenigstens mit dem 
Datenblatt abgleichen. Ob es Probleme mit dem Backup RAM gibt, weiß ich 
nicht, das wird (noch) nicht verwendet (daher auch das etwas sinnlose 
DBUP an/aus und der Backup Regulator wird noch nicht eingeschaltet).

void clockSetRTCWriteProtection(bool enable)
{
  if (enable) {
    RTC->WPR = 0xFF;
    PWR->CR &= ~PWR_CR_DBP;
  } else {
    PWR->CR |= PWR_CR_DBP;
    RTC->WPR = 0xCA;
    RTC->WPR = 0x53;
  }
}

void clockSetInitializationMode(bool enable)
{
  if (enable) {
    RTC->ISR |= RTC_ISR_INIT;
    systickSetIOTimeout(3);
    while ( ((RTC->ISR & RTC_ISR_INITF) == 0) && (!systickIOTimeoutExpired()) );
  } else {
    // clear init flag and also the RSF flag
    RTC->ISR &= ~(RTC_ISR_INIT | RTC_ISR_RSF);
  }
}

void clockInit()
{
  uint32_t v;

  if ( (RCC->BDCR & (RCC_BDCR_RTCEN | RCC_BDCR_RTCSEL_1 | RCC_BDCR_RTCSEL_0 | RCC_BDCR_LSEBYP | RCC_BDCR_LSEON))
     !=  (RCC_BDCR_RTCEN | RCC_BDCR_RTCSEL_0 | RCC_BDCR_LSEON) ) {
    // initialization needed
    // reset Backup domain
    RCC->BDCR |= RCC_BDCR_BDRST;
    RCC->BDCR &= ~RCC_BDCR_BDRST;
    // enable write access to BDCR
    PWR->CR |= PWR_CR_DBP;
    // clear all the RTC relevant bits
    v = RCC->BDCR & (~(RCC_BDCR_RTCEN | RCC_BDCR_RTCSEL_1 | RCC_BDCR_RTCSEL_0 | RCC_BDCR_LSEBYP | RCC_BDCR_LSEON));
    v |= (RCC_BDCR_RTCEN | RCC_BDCR_RTCSEL_0 | RCC_BDCR_LSEON);
    RCC->BDCR = v;
    // ok, RTC clock selected and enabled, set it up
    clockSetRTCWriteProtection(false);
    RTC->CR &= 0xFF000000; // clear all non-reserved bits
    RTC->ISR &= 0xFFFE8000; // clear all non-reserved bits
    clockSetInitializationMode(true);
    RTC->PRER = 255; // sync divider by 256
    RTC->PRER |= 127<<16; // async divider by 128
    clockSetInitializationMode(false);
    clockSetRTCWriteProtection(true);
    clockTimeAvailable = false;
  } else {
    clockTimeAvailable = true;
    // enable write access to Backup Domain
    PWR->CR |= PWR_CR_DBP;
  }
  // enable backup sram
   RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_BKPSRAM, ENABLE);
  PWR->CR &= ~PWR_CR_DBP;

... etc.

[Christian J. (Gast)]

Tassilo H. schrieb:
> Ich verwende direkten Registerzugriff (abgesehen vom clock enable,
> anfangs hab' ich noch die Lib verwendet, bis mir aufgefallen ist, daß
> das für viele Dinge unübersichtlicher ist als direkter Registerzugriff
> und auch nicht portabler).

Naja, das erinnert mich an meine schlimmsten LPC2368 Zeiten, wo ich die 
PLL etc auch so gesetzt habe. Ich könnte keine Zeile intuitiv lesen so 
wie das da steht. Ich habe grad nochmal rumprobiert, jetzt lässt sich 
BRE auch so setzen. Vorher aber defintiv nicht. Warum weiss ich nicht, 
das Bit blieb 0. Ich schalte EWUPO jetzt wieder ab nachdem alles gesetzt 
ist und belasse es dabei. Nachher geht das wieder nicht.

Ok, auf jeden Fall sind wir etwas weiter. Ich finde es nur echt blöd, 
dass die StdPeriphLib kein pdf als Manual hat, diese chm Datei finde ich 
voll daneben.

PS: Wo steht das denn alles drin? Automatische Ergänzung funzt nicht.

PWR->CR |= PWR_CR_DBP;

CMSIS?

PS: Mit dem BRE Bit hat es irgendwas auf sich, jetzt lässt es sich nicht 
mehr zurücksetzen im Debugger. Seltsam....

[Tassilo H. (tassilo_h)]

Christian J. schrieb:
> PS: Wo steht das denn alles drin? Automatische Ergänzung funzt nicht.
>
> PWR->CR |= PWR_CR_DBP;

stm32f4xx.h

Da ist alles drin nach dem Schema
[Peripheriename aus dem Datenblatt]->[Registername aus dem Datenblatt]

Diese Headerdatei kam mit der CooCox IDE, aber nach den Kommentaren ist 
sie von ST und gehört zu CMSIS.