Forum: Mikrocontroller und Digitale Elektronik STM32: Seltsames Verhalten


von KT315 (Gast)


Lesenswert?

Hallo zusammen,

ich drehe mich seit Wochen im Kreis und hoffe, dass ihr den Fehler mit 
frischen Augen sieht oder ev. Nachstellen könnt. Ich muss in einem 
Projekt beim Aufwachen des MCU aus dem StandBy zwischen Alarm, Drucken 
auf Reset Button und erstem Einschalten des Gerätes unterscheiden. Je 
nach dem läuft eine leicht veränderte Initialisation Routine. Beim Reset 
sollten die nachträglich geänderten Einstellungen nicht in den 
Ursprungszustand gesetzt werden, sondern werden über die serielle 
Schnittstelle angepasst. Danach geht das Ganze wieder in den 
StandBy-Betrieb. Das Board ist ein HW-848 mit einem STM32F401CC MCU aus 
China und soll mit 2 AA Batterien betrieben werden.

Das ganze läuft einwandfrei bis die Betriebsspannung bis auf ca. 2.7V 
sinkt.? Ab dann werden SBF & WUF nicht mehr gesetzt oder ev. beim 
Aufwachen wieder zurückgesetzt.  Da bin ich mir nicht sicher. Beim 
ALARMAF läuft auch in dem Fall alles einwandfrei. Die Alarm-Routine wird 
richtig abgearbeitet. Die Zustände beim Start/Aufwachen im 
Normal-Betrieb sind in der Tabelle dargestellt.

             SBF WUF
    Power On OFF OFF
    Alarm     ON  ON
    Reset     ON OFF

Ab 2.7V runter sind die alle immer OFF. Es schein so zu sein, dass PDR 
durchgeführt wird:

SBF: Standby flag
The SBF status flag in PWR_CR (see Section 5.4.2: PWR power 
control/status register (PWR_CSR))
indicates that the MCU was in Standby mode. This bit is set by hardware 
and cleared only by a POR/PDR (power-on reset/power-down reset) or by 
setting the CSBF bit in the PWR_CR register

 Aber warum? Der Grenzwert ist doch bei weitem nicht erreicht.

    Symbol    Parameter           Conditions     Min   Typ   Max  Unit
    Vpor/pdr  Power-on/power-down Falling edge  1.60  1.68  1.76    V
              reset threshold     Rising edge   1.64  1.72  1.80


Zum Testen habe ich ein kleines Sketch geschrieben. Das Programm wird 
weitgehend von CubeIDE erstellt. Es wird nur LSE, der Kalender mit 
Alarm-A eingerichtet. Der Alarm erfolgt ein Mal pro Minute. Über LED 
kann ich die Zustände der Flags beim Start/Reset/Aufwachen ermitteln. 
Das von mir geänderte Teil sieht wie folgt aus:
1
  /* USER CODE BEGIN 2 */
2
  if(__HAL_PWR_GET_FLAG(PWR_FLAG_SB) == SET)
3
  //if(__HAL_RCC_GET_FLAG(RCC_FLAG_LPWRRST))
4
  {
5
    for(int i=0; i<10; i++)
6
    {
7
      HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin);
8
      HAL_Delay(50);
9
    }
10
  }
11
12
  HAL_Delay(2000);
13
14
  if(__HAL_PWR_GET_FLAG(PWR_FLAG_WU) == SET)
15
  //if(__HAL_RCC_GET_FLAG(RCC_FLAG_PORRST) == SET)
16
  {
17
    for(int i=0; i<6; i++)
18
    {
19
      HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin);
20
      HAL_Delay(500);
21
    }
22
  }
23
24
  HAL_Delay(1500);
25
26
  if(__HAL_PWR_GET_FLAG(PWR_FLAG_SB) == RESET && __HAL_PWR_GET_FLAG(PWR_FLAG_WU) == RESET)
27
  //if(__HAL_RCC_GET_FLAG(RCC_FLAG_PINRST) == SET)
28
  {
29
    for(int i=0; i<2; i++)
30
    {
31
      HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin);
32
      HAL_Delay(5000);
33
    }
34
  }
35
36
  __HAL_RTC_ALARM_DISABLE_IT(&hrtc, RTC_FLAG_ALRAF);
37
  __HAL_RTC_ALARM_CLEAR_FLAG(&hrtc, RTC_FLAG_ALRAF);
38
  __HAL_PWR_CLEAR_FLAG(PWR_FLAG_WU);
39
  __HAL_PWR_CLEAR_FLAG(PWR_FLAG_SB);
40
  __HAL_RTC_ALARM_ENABLE_IT(&hrtc, RTC_FLAG_ALRAF);
41
42
  HAL_PWR_EnterSTANDBYMode();
43
  /* USER CODE END 2 */
Ich habe den Sketch auch mit Nucleo F411RE & G071RB getestet. Bei Beiden 
gibt es das Problem nicht. Die funktionieren bis auf 2V einwandfrei. Ein 
zweites Board mit STM32F401CC verhält sich gleich.

Mit RCC-Flags konnte ich leider die Zustände beim Start auch nicht 
zwischen Power-On & Reset unterscheiden.

BOR ist ausgeschaltet. In dem Fall dürfte allerdings MCU ja auch gar 
nicht mehr starten. Tut es aber zuverlässig bis auf unter 2V.

von Kevin M. (arduinolover)


Lesenswert?

Sicher, dass der µC die 2,7V auch bekommt, wenn das normale AA 
Batterieen sind, ich nehme an 2 in Reihe, kann es gut sein das beim 
einschalten des µC die Spannugn einbricht. Wenn die Batterien leerer 
werden haben sie meistens einen ziehmlich hohen Innenwiderstand.

: Bearbeitet durch User
von KT315 (Gast)


Lesenswert?

Wenn es so wäre, dann müsste doch auch die Backup Domain resetet sein. 
Also  die RTC-Registern inkl. ALRMF & WUTF gelöscht sein. Das sind sie 
aber nicht. Die Alarm-Routine wird standardmäßig abgearbeitet.

Ich hatte es auch schon mal mit einem Labornetzteil ausprobiert. Das 
Verhalten ist gleich. Da hatte ich eigentlich das Labornetzteil im 
Verdacht. Ist ja ein schnell geschustertes Selbstbauteil.

Werde demnächst noch mal nachmessen. Habe allerdings keine großen 
Hoffnungen.

von mh (Gast)


Lesenswert?

KT315 schrieb:
> Das Board ist ein HW-848 mit einem STM32F401CC MCU aus
> China

> Nucleo F411RE & G071RB getestet. Bei Beiden
> gibt es das Problem nicht.

> Ein
> zweites Board mit STM32F401CC verhält sich gleich.

Ist das zweite F401-Board auch ein HW-848 aus China?
Vielleicht werden neben den STMs von BluePill/BlackPill/usw. inzwischen 
auch größere Controller nachgebaut...

von KT315 (Gast)


Lesenswert?

ja, das ist das Gleiche Board.

von A. B. (Gast)


Lesenswert?

Das spezielle HW-848 kenne ich nicht (zumindest nicht unter diesem 
Namen), aber einige dieser F4x1-Boards haben einen Spannungsregler 
drauf: Ist der ausgebaut/überbrückt? Und die "Crystal Oscillators" wie 
in den Beschreibungen meist steht, sind tatsächlich beides Quarze, nicht 
etwa Quarzoszilltoren?

von KT315 (Gast)


Angehängte Dateien:

Lesenswert?

Ich habe jetzt die Spannungen gemessen. Die brechen leicht in beiden 
Fällen um ca. 30mV ein. Der Unterschied ist die Dauer. Bei kleineren 
Spannung dauert es etwa 500 ms bei größeren ca. 30µs bis zur Erholung.

Das dürfte doch keine so gravierende Auswirkung haben.?

@A.B. Spannungsregler und LEDs sind wegen dem Standby-Modus entfernt. So 
habe ich  im Standby 2.7 µA statt 1.7 mA Stromverbrauch.

Es sind die "Crystal Oscillators" verbaut inkl. passende Kerkos.

von KT315 (Gast)


Angehängte Dateien:

Lesenswert?

Die erste Datei wurde irgendwie nicht mit übertragen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.