STM32F4xx - Backup Ram verliert Inhalte

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.

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

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.

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

Was verstehst du denn darunter? Nachher 4096 mal 00?

Georg

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.

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

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

STM32F407VG

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.

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.

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?

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                                */

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

1

/* Enable SRAM Backup Register */

2

    RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE); 

3

    RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_BKPSRAM, ENABLE);

4

    PWR_MainRegulatorModeConfig(PWR_Regulator_Voltage_Scale1);

5

    PWR_WakeUpPinCmd(ENABLE);

6

    PWR_BackupRegulatorCmd(ENABLE);

7

    while(PWR_GetFlagStatus(PWR_FLAG_BRR) == RESET);

8

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