STM32L152V8T6 Low Power?

[Bernd S. (soundgott)]

Jetzt muss ich auch mal die werte Forengemeinde um Hilfe bitten:
Ich bin dabei ein eigenes Board (4-L Multilayer) mit einem STM32L152V8T6 
in Betrieb zu nehmen. Bei der Schaltung kommt es auf extrem niedrige 
Stromaufnahme an, daher auch die Wahl des Controllers. Vorab getestet 
mit dem ST STM32L152c-discovery board (da ist der kleinere Bruder 
(64pin) verbaut. die mitgelieferte Demosoftware zeigt u.A. Stromaufnahme 
in verschiedenen Modi

Mein eigenes Board benimmt sich dagegen als Vielfrass:

        Discovery      eigenes
Run       700uA         2.3mA
Sleep     240uA         1.9mA
LP Run     7.3uA        53uA
LP Sleep   3.6uA        53uA

Software ist die gleiche drauf, bei meinem Board ist nichts am 
Controller angeschlossen (ausser Block C's) und ein Taster, equivalent 
zum Discovery.
der Controller auf meinem Board lässt sich normal ansprechen und tut 
auch...
bis auf die Stromaufnahme. Es kann nur am Chip liegen, beim Board ohne 
Chip (nur die C's) fließt auch kein Strom. Hat einer vieleicht noch eine 
Idee ?

[Jim M. (turboj)]

War da der Debugger noch angeschlossen? Der verfälscht die Strommessung.

[Bernd S. (soundgott)]

Nein, der war nicht mehr dran

[Dirk K. (dekoepi)]

Du machst nichts, was im Errata-Sheet erwähnt wird?
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/errata_sheet/CD00278726.pdf
Wie sieht die Spannungsversorgung aus? Derselbe Step-Down/LDO wie auf 
dem Discovery, dieselbe Spannung (z.B. 1,65V)?
Derselbe Takt nach Initialisierung?

#include "stm32f1xx.h"
static char text[255];
RCC_ClocksTypeDef Clocks;

void init(void) {
  SystemInit();  // Initialize the System

  GPIO_InitTypeDef GPIO_InitStructure;
  USART_InitTypeDef USART_InitStruct;
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1, ENABLE);
  RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA, ENABLE);

  // UART1: Configure PA9 and PA10
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9 | GPIO_Pin_10;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
  GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
  GPIO_Init(GPIOA, &GPIO_InitStructure);

  GPIO_PinAFConfig(GPIOA, GPIO_PinSource9, GPIO_AF_1);
  GPIO_PinAFConfig(GPIOA, GPIO_PinSource10, GPIO_AF_1);

  USART_InitStruct.USART_BaudRate = 57600;
  USART_InitStruct.USART_WordLength = USART_WordLength_8b;
  USART_InitStruct.USART_StopBits = USART_StopBits_1;
  USART_InitStruct.USART_Parity = USART_Parity_No;
  USART_InitStruct.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
  USART_InitStruct.USART_Mode = USART_Mode_Tx | USART_Mode_Rx;
  USART_Init(USART1, &USART_InitStruct);
  USART_Cmd(USART1, ENABLE);


  RCC_GetClocksFreq(&Clocks);
}

void uart_tx(char *out) {
  while (*out) {
    while(!(USART1->ISR & USART_FLAG_TXE)) {
      // Nothing, really.;
    }
    USART1->TDR = *out++;
  }
}

int main (void) {
  init();

  sprintf(text, "STM32F1xx-Test begins.\r\nHCLK is %ld MHz, PCLK %ld MHz, System %ld MHz, ADC %ld MHz.\r\n", (Clocks.HCLK_Frequency/1000000), (Clocks.PCLK_Frequency/1000000), (Clocks.SYSCLK_Frequency/1000000), (Clocks.ADCCLK_Frequency/1000000));
  uart_tx(text);
}

Mal den Code für STM32F0 grob auf F1 gemünzt (PA9+10 auch da UART?), 
darauf aber gerade ungetestet (keine Zeit grade).

[Bernd S. (soundgott)]

erstmal Danke für die "frühe" Antwort.
Spannungsversorgung identisch 3V VDD bei beiden Systemen. Am 
Discoveryboard hängt zusätzlich ja noch das Glass-LCD, bei mir ist 
garnix dran, nur die üblichen Blocks (5 x 100nF/10uF Kerko), zusätzliche 
Blocks noch an VDDA->VSSA und der Quarz (32...kHz) an OSC32IN/OUT, wie 
auch beim Discovery.
Was mich auch noch etwas mistrauisch macht: selbst im Reset zieht das 
Ding auch noch immerhin 0.9mA. Wenn ich nachher etwas Zeit habe, werde 
ich noch mal prüfen: alle GPIO'S in definierten Zustand z.B. Input und 
Pulldown's an und dann Clocks aus und STOP. (empfohlen wird zwar alles 
auf Analogeingang, aber erstmal testen, wo da vielleicht ein Unterschied 
besteht. Vieleicht floatet ja der eine oder andere Pin irgendwo hin, ist 
ja schon nicht mehr so ganz trivial mit 'ner korrekten Messung bei den 
Strömen :-)

Achso, Deinen Code kann ich ja auch mal laufen lassen, die Pins sollten 
stimmen.

[Uwe Bonnes (Gast)]

Sind alls unbeschalteten Pins auf "Analog" eingestellt? Die Querstroeme 
der Eingangsinverter zeigen sich sonst deutlich.

Gibt es unversorgte Schaltungsteile, in die ein als Ausgang geschalteter 
uC Pin Strom in die Schutzdioden hineinpumpt?

Gleiche Taktfrequenz?

Wo sind WFE/WFI um in den Sleep Modus zu kommen? Im Run Modus braucht 
z.B. der F411 deutlich weniger Strom!

[Bernd S. (soundgott)]

@Uwe Bonnes
 Momentan kann ich mich nur sporadisch mit dem Projekt befassen, soviel 
jedoch vorab:
* Startup mit MSI = 2MHz
* GPIO-Clocks ein
* GPIO's (so weit wie möglich -> PA13/14 :-) ) auf Analogmodus
  das macht ca. 30-40uA Reduzierung pro Port aus
* GPIO-Clocks aus
* es sollte dann eigentlich __WFE() folgen, bis dahin bin ich jedoch
  noch nicht gekommen.

Das Board ist NUR mit dem Controller, Block-C's und SWD-Anschluss 
bestückt, auch fehlt momentan noch der vorgesehene Quarz an OSC32.

Weiter runter als ca. 500uA bin ich aber immer noch nicht...

[Uwe Bonnes (Gast)]

Bernd S. schrieb:
> @Uwe Bonnes
>  Momentan kann ich mich nur sporadisch mit dem Projekt befassen, soviel
> jedoch vorab:
> * Startup mit MSI = 2MHz
> * GPIO-Clocks ein
> * GPIO's (so weit wie möglich -> PA13/14 :-) ) auf Analogmodus
>   das macht ca. 30-40uA Reduzierung pro Port aus
> * GPIO-Clocks aus
> * es sollte dann eigentlich __WFE() folgen, bis dahin bin ich jedoch
>   noch nicht gekommen.
>
> Das Board ist NUR mit dem Controller, Block-C's und SWD-Anschluss
> bestückt, auch fehlt momentan noch der vorgesehene Quarz an OSC32.
>
> Weiter runter als ca. 500uA bin ich aber immer noch nicht...

Das Datenblatt sagt fuer 2 MHz im Run Modus typisch 470 und max. 600 uA. 
Dann passt doch alles.

[Bernd S. (soundgott)]

Das schon, ist richtig, aber ich will ja noch bis zum STOP kommen, hab 
ich aber noch nicht testen können

[Bernd S. (soundgott)]

Zur Info:
habe bei ST / GitHUb noch 'n paar passende Examples gefunden
https://github.com/bjornfor/stm32-test
damit bin ich im Lowpower RunMode schon mal bis auf 150uA 
'runtergekommen.
Allerdings gibts ab und an da mal eine Hardfault Exception (Bus 
Failure...)
das habe ich dann mit der KEIL-IDE festgestellt. Normalerweise nutze ich 
jedoch Coocox 1.7.7. Nur muss man da schon ziemliche Klimmzüge 
veranstalten, um überhaupt einigermassen debuggen zu können (HW-Reset 
problem). Ich denke mal, dass damit wohl das Problem fast gelöst ist.
Also Danke nochmal an alle für Eure Tips.
Vielleicht stelle ich das Projekt mal hier 'rein, wenns soweit gediehen 
ist.