STM32G071 LQFP32 und der HSE

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Sehe ich das richtig, dass die STM32G071KBT6N im LQFP32 Gehäuse nur den 
LSE rausgeführt haben und kein HSE?
Dabla: 
https://media.digikey.com/pdf/Data%20Sheets/ST%20Microelectronics%20PDFS/STM32G071_Rev1_DS.pdf

Irgendwie hab ich Bauchschmerzen dabei 4 UART mit dem RC zu betreiben.

Im GammelMX (zur Pinbelegung klicken nutz ich den ja durchaus gerne)
kann man sich "BYPASS Clock Source" klicken, also ein externer 
Oszilatotor sollte gehen, aber der entsprechende Pin heist im DB nicht 
so.

Hat den schonmal wer genutzt und weis ob das geht?
Oder ist der RC genau genug?

[A. B. (Gast)]

PC14 ist auch beim LQFP32 unter Table 12, "Additional Funktions" mit 
"OSC32_IN,OSC_IN" aufgeführt, also externer Oszillator geht schon. Aber 
wenn HSE, dann geht LSE nicht und umgekehrt.

Beim LQFP32 bleibt sonst höchstens noch: LSE mit Quarz, damit HSI16 
regelmäßig messen und nachtrimmen. "HSI16 frequency user trimming step" 
ist 0.2% bis 0.4%, d. h. man könnte mit etwas Mühe damit durchaus auf 
unter 0.5% Abweichung kommen. Für UART sollte das reichen.

[Gerd E. (robberknight)]

Die G-Serie ist noch ganz neu. Brauchst Du irgendwelche Features, die 
nur bei denen vorhanden sind?

Ansonsten würde ich noch nen halbes Jahr oder Jahr warten bis die 
gröbsten Fehler dokumentiert und die Dinger in allen Toolchains etc. 
voll unterstützt sind.

Das kann einem einiges an Zeit und Ärger ersparen.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Ja die sind neu und Mouser zeigt sie als abgekündigt an, interessanter 
Fehler.

Die hab ich ausgewählt, weil ich ein kleines Modbus Verteilerplatinchen 
mit Baudratenumsetzung und galv. Trennung bauen will um 3 DPS5005 an 
meinen Werktisch Modbus anzustöpseln.
Da wollt ich jetzt nicht ne Mouserbestellung aufmachen und Reichelt hat 
die oder den uralt F103.
Also ich weis nichtmal was für neue Features die G haben ;)
Der Jlink versteht den G071 laut der Webseite wohl schon und die Treiber 
schreib ich eh selber.

@A. B.
Ah danke, hab ich wohl zu schnell drübergescrollt.
Wär natürlich besser gewesen wennse LSE/HSE auf die gleichen Pins 
gebastelt hätten.

[Stefan F. (Gast)]

Was ist an der G Serie besonders?

[Alex D. (daum)]

Stefanus F. schrieb:
> Was ist an der G Serie besonders?

Die sind etwas neuer, haben einen Cortex M0+ statt M0 (bei den F0)

Der DMA hat einen Muxer für Requests, sodass jedes Peripheral jeden DMA 
Channel auslösen kann.

Es kommen irgendwann (H2 2019) kleine runter bis 8 pin packages.

Außerdem sind die mit 90nm (wie die L-Serie) statt 180nm (normale 
F-Serie) gefertigt, das bringt etwas Stromersparnis und evtl. etwas 
kleinere Chips, also vielleicht günstiger (oder mehr Gewinn für ST).

Dann haben die noch einen Timer der auf doppelten Systemtakt laufen kann 
und einige Teile mit mehr RAM (bei 64k Flash schon 36k SRAM).

Evtl haben die noch etwas mehr Peripherie, aber da hab ich keinen 
Überblick.

[Stefan F. (Gast)]

Alex D. schrieb:
> Es kommen irgendwann (H2 2019) kleine runter bis 8 pin packages.

Das wird spannend, die könnten meine ATtiny13 ablösen.

[Dreikommaeinsvier (Gast)]

Mw E. schrieb:
> Irgendwie hab ich Bauchschmerzen dabei 4 UART mit dem RC zu betreiben.

Ja, das sind die AVR-geschädigten :-)

Nein im Ernst: Der LC ist genau genug, keine Sorge.

[Alex D. (daum)]

Stefanus F. schrieb:
> Das wird spannend, die könnten meine ATtiny13 ablösen.

Spannend wird eventuell auch das Anlöten der Teile, auf der Seite steht 
(derzeit) als package nur SON. Das wäre wie QFN, halt nur pins auf 2 
Seiten. Das geht dann halt nur auf Platinen mit halbwegs gutem 
Lötstopplack einfach zu löten (zumindest wenn die auch 0.5mm pin pitch 
haben)

[Stefan F. (Gast)]

Misst, irgend etwas mit Pins oder wenigstens Stummelbeinchen brauche ich 
schon. Sonst ist es für mich zu klein.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Alex D. schrieb:
> Der DMA hat einen Muxer für Requests, sodass jedes Peripheral jeden DMA
> Channel auslösen kann.
Also wie bei den H7xx, das ist eine gute Änderung.
Die feste Kanalzuweisung hat immer genervt.

Alex D. schrieb:
> Dann haben die noch einen Timer der auf doppelten Systemtakt laufen kann
Die Timer laufen ja fast immer mit Bustakt*2, bei den kleinen (64MHz) 
ist der Bustakt eben auch Systemtakt. Ein APB mit zB 168Mhz ist eben 
nicht drinne bei den größeren.

Dreikommaeinsvier schrieb:
> Mw E. schrieb:
>> Irgendwie hab ich Bauchschmerzen dabei 4 UART mit dem RC zu betreiben.
>
> Ja, das sind die AVR-geschädigten :-)
>
> Nein im Ernst: Der LC ist genau genug, keine Sorge.
Ja, ich gebe mich zu erkennen ;)
AVR Altbestände werden bei Gefrickel noch verbaut, aber Neudesigns mach 
ich nurnoch mit ARM.
Laut DB hat der RC +-1% max bei 0 - 85°C, schränkt die 
Baudratenabweichung etwas ein, aber sollte machbar sein.

Alex D. schrieb:
> Spannend wird eventuell auch das Anlöten der Teile, auf der Seite steht
> (derzeit) als package nur SON. Das wäre wie QFN, halt nur pins auf 2
> Seiten.
Wenn das package so groß wird wie die von NOR Flash, dann ist das halb 
so wild. Son STM32 Die ist ja nun nicht winzig.

[Alex D. (daum)]

Mw E. schrieb:
> Alex D. schrieb:
>> Dann haben die noch einen Timer der auf doppelten Systemtakt laufen kann
> Die Timer laufen ja fast immer mit Bustakt*2, bei den kleinen (64MHz)
> ist der Bustakt eben auch Systemtakt. Ein APB mit zB 168Mhz ist eben
> nicht drinne bei den größeren.

Ich meine wirklich doppelten Systemtakt. Der Kern taktet mit max. 64MHz, 
einer der Timer hat eine eigene PLL mit der er auf 128MHz laufen kann.

Mw E. schrieb:
> Alex D. schrieb:
>> Spannend wird eventuell auch das Anlöten der Teile, auf der Seite steht
>> (derzeit) als package nur SON. Das wäre wie QFN, halt nur pins auf 2
>> Seiten.
> Wenn das package so groß wird wie die von NOR Flash, dann ist das halb
> so wild. Son STM32 Die ist ja nun nicht winzig.

Durch die verwendete 90nm Node wird der Die doch ganz schön kleiner. Da 
skaliert auch Flash noch recht gut und Core sowie Peripherals sowieso. 
Kann also gut sein, dass die G0 dies deutlich kleiner sind als die der 
F0er.

Den STM32G081EB mit 128k Flash und 36k RAM gibts im WLCSP mit 2,3*2,5mm 
(5,75mm^2), das ist die Größe des die. Die im SON8 package gibts nur bis 
32k Flash und 8k RAM, der speicher macht den Großteil der Größe aus, 
also könnte der auf 1/4 der Fläche kommen, das wären 1,4mm^2. Ich glaube 
das würde leicht in ein recht kleines SON package passen.

[m.n. (Gast)]

Stefanus F. schrieb:
> Alex D. schrieb:
>> Es kommen irgendwann (H2 2019) kleine runter bis 8 pin packages.
>
> Das wird spannend, die könnten meine ATtiny13 ablösen.

Interessanter finde ich den G071 im TQFP32 als lötfreundliche 
Alternative zum ATmega328. Wenn man geschickt einkauft, liegt der Preis 
etwas über zwei Euro.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Es ist LQFP, nicht TQFP ;)
Aber ja, er hat 0,8mm Pinabstand statt den STM32 üblichen 0,5mm.

edit: das gilt aber wirklich nur für den 32er

[m.n. (Gast)]

Mw E. schrieb:
> Es ist LQFP, nicht TQFP ;)

Na gut, LQFP is halt ein bisschen dicker, hat aber die gleichen Beine 
;-)

[Christopher J. (christopher_j23)]

Mw E. schrieb:
> Es ist LQFP, nicht TQFP ;)
> Aber ja, er hat 0,8mm Pinabstand statt den STM32 üblichen 0,5mm.
>
> edit: das gilt aber wirklich nur für den 32er

haben nicht alle STM32 im LQFP32 den selben Pin-Abstand?

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Im Anhang mal ne eagle 6.1 lib für STM32G071KxTxN und STM32G071KxT6.
Die haben ein anderes Pinlayout, eines schön geordnet mit viel Port A 
und B.
Das andere ist einmal mit der Schrotflinte abgedrückt (also so wie mans 
von den STM32 eigentlich kennt).

Christopher J. schrieb:
> Mw E. schrieb:
>> Es ist LQFP, nicht TQFP ;)
>> Aber ja, er hat 0,8mm Pinabstand statt den STM32 üblichen 0,5mm.
>>
>> edit: das gilt aber wirklich nur für den 32er
>
> haben nicht alle STM32 im LQFP32 den selben Pin-Abstand?
Das ist jetzt mein erster STM32 im LQFP32, daher kann ich dir das leider 
nicht beantworten.
(Bisher braucht ich eher 64Pins+)

[STM32 Fanboy (Gast)]

Mw E. schrieb:
> Im Anhang mal ne eagle 6.1 lib für STM32G071KxTxN und STM32G071KxT6.
> Die haben ein anderes Pinlayout, eines schön geordnet mit viel Port A
> und B.
> Das andere ist einmal mit der Schrotflinte abgedrückt (also so wie mans
> von den STM32 eigentlich kennt).

grummel, Ordnung ist schön und gut, aber jetzt passt auf das 8 Jahre 
alte Layout keine coolen, neuen, schnellen Chips mehr obwohl auf allen 
STM32 drauf steht :-(

Ist da Atmel - äh - Microchip mit den cortex SAMs besser?

[Stefan G. (sgrz)]

Guten Abend in die Runde

Das Thema HSE steht hier zwar schon ein Weilchen, aber ich habe eine 
Frage rund um das Thema HSE und PLL der STM32G0 Serie.
Ich nutze keinen 32 Pin, sondern einen 48er (STM32G071CBTx) Rev B.

Ich habe ein fertiges PCB Design und leider den Fehler gemacht bestimmte 
Sachen zuvor ungetestet zu lassen. Wie z.B. die vollständige 
Inbetriebnahme der CLOCK CFG.

Ist bereits jemandem gelungen den STM32G071 tatsächlich mal mit 64MHz 
auf dem SYSCLK zu betreiben. Bei mir besteht das Problem, dass ich die 
PLL mit HSE sowie HSI konfigurieren kann, aber bei einem SYSCLK von 
55MHz (56 MHz) Schluss ist.
Mein PCB-Design sowie mein Nucleo-Board (STM32g071RBTx ... 64 Pins) 
zeigen bei gleichem Code das gleiche Verhalten.

SYSCLK direkt gemessen mit Oszi am MCO Pin ohne Vorteiler:
HSE ... OK
HSI ... OK
LSI ... OK
HSE mit PLL bis 55MHz ... OK
HSI mit PLL bis 55MHz ... OK

Mein bisheriger Testcode:

/* Includes */
#include <stddef.h>
#include "stm32g0xx_conf.h"

#include "stm32g0xx_ll_rcc.h"
#include "stm32g0xx_ll_bus.h"
#include "stm32g0xx_ll_gpio.h"

// ========================================================================
 */

#define LL_RCC_PLLN_MUL_SYS  50

int main(void) {

  LL_RCC_DeInit();


  LL_RCC_HSI_Enable();
  while ( !LL_RCC_HSI_IsReady() );

  LL_RCC_HSE_Enable();
  while ( !LL_RCC_HSE_IsReady() );

  LL_RCC_PLL_ConfigDomain_SYS( LL_RCC_PLLSOURCE_HSE , LL_RCC_PLLM_DIV_3 , LL_RCC_PLLN_MUL_SYS , LL_RCC_PLLR_DIV_4 );
//  LL_RCC_PLL_ConfigDomain_ADC( LL_RCC_PLLSOURCE_HSE , LL_RCC_PLLM_DIV_3 , LL_RCC_PLLN_MUL_SYS , LL_RCC_PLLP_DIV_4 );
//  LL_RCC_PLL_ConfigDomain_TIM1( LL_RCC_PLLSOURCE_HSE , LL_RCC_PLLM_DIV_3 , LL_RCC_PLLN_MUL_SYS , LL_RCC_PLLQ_DIV_2 );

  LL_RCC_PLL_Enable();
  while ( !LL_RCC_PLL_IsReady() );

  LL_RCC_PLL_EnableDomain_SYS();
//  LL_RCC_PLL_EnableDomain_ADC();
//  LL_RCC_PLL_EnableDomain_TIM1();

  LL_RCC_SetSysClkSource( LL_RCC_SYS_CLKSOURCE_PLL );
  LL_RCC_SetAHBPrescaler( LL_RCC_SYSCLK_DIV_1 );
  LL_RCC_SetAPB1Prescaler( LL_RCC_APB1_DIV_1 );


  LL_RCC_ConfigMCO( LL_RCC_MCO1SOURCE_SYSCLK , LL_RCC_MCO1_DIV_1 );


  LL_GPIO_InitTypeDef testpin;

  LL_IOP_GRP1_EnableClock(LL_IOP_GRP1_PERIPH_GPIOA);

  LL_GPIO_ResetOutputPin(GPIOA, LL_GPIO_PIN_0);
  LL_GPIO_ResetOutputPin(GPIOA, LL_GPIO_PIN_1);
  LL_GPIO_ResetOutputPin(GPIOA, LL_GPIO_PIN_6);

  LL_GPIO_StructInit( &testpin );
  testpin.Pin = LL_GPIO_PIN_0 | LL_GPIO_PIN_1 | LL_GPIO_PIN_6;
  testpin.Mode = LL_GPIO_MODE_OUTPUT;
  testpin.Speed = LL_GPIO_SPEED_FREQ_VERY_HIGH;
  testpin.OutputType = LL_GPIO_OUTPUT_PUSHPULL;
  testpin.Pull = LL_GPIO_PULL_DOWN;

  LL_GPIO_Init(GPIOA, &testpin);

  testpin.Pin = LL_GPIO_PIN_8;
  testpin.Mode = LL_GPIO_MODE_ALTERNATE;
  LL_GPIO_Init(GPIOA, &testpin);

  LL_GPIO_SetAFPin_8_15( GPIOA , LL_GPIO_PIN_8 , LL_GPIO_AF_0 );

  while (1) {
    LL_GPIO_TogglePin(GPIOA, LL_GPIO_PIN_0);
    LL_GPIO_TogglePin(GPIOA, LL_GPIO_PIN_1);
    LL_GPIO_TogglePin(GPIOA, LL_GPIO_PIN_6);
  }

  return 0;
}

Würde mich über eine Hilfestellung freuen...

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Definiere "Schluss ist".

Die Kiste macht kein mucks mehr? Es bleibt bei 55MHz?

#define LL_RCC_PLLN_MUL_SYS  50
Das mit div3 und div4 ist auch nen bissle Krumm und kommt auch bei 
66,67MHz raus.

Machmal:

#define LL_RCC_PLLN_MUL_SYS  16
LL_RCC_PLL_ConfigDomain_SYS( LL_RCC_PLLSOURCE_HSI , LL_RCC_PLLM_DIV_2 , LL_RCC_PLLN_MUL_SYS , LL_RCC_PLLR_DIV_2 );

[Stefan F. (Gast)]

Braucht dieser µC keine Wait-States (Flash Latency), wenn er so hoch 
getaktet wird?

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Stimmt die fehlen bei ihm, glatt übersehen.

VCore ist aber nach dem Reset schon auf Range1, da liegt dann nicht noch 
ein Fehler.

Ansonsten empfiehlt es sich noch den Instruction Prefetch und Cache zu 
aktivieren.

[Stefan G. (sgrz)]

OK, ein paar Definitionen fehlen und vor allem "ganz" korrekte Werte.

Mit "Schluss ist" ist gemeint, dass der Core stehen bleibt bzw. meine 
Debug-Session die Verbindung zum Core verliert, wenn der Symbolwert 
LL_RCC_PLLN_MUL_SYS groeßer als 55 ist und

LL_RCC_SetSysClkSource( LL_RCC_SYS_CLKSOURCE_PLL );

ausgeführt wurde.

Das HSI besitzt einen Wert 16Mhz.
Das HSE besitzt bei mir einen Wert von 12Mhz Quarz. Das ist unerwähnt 
geblieben.
Der Wert scheint vllt. ungewoehnlich, dieser stammt aus einem Projekt 
von einem stm32f303, daher sind da noch ganz paar Quarze da.

So ergibt sich, dass

$$HSE / div3 * LL\_RCC\_PLLN\_MUL\_SYS / div4$$

64Mhz ist bei LL_RCC_PLLN_MUL_SYS = 64

Dieses Symbol steht fuer ein einfacheres Lesen des HCLK in MHz.

Die Flash Wait-States habe ich mal glatt ignoriert. Zugegeben, ist auch 
mein erstes Projekt mit der aktuellen LL-Lib von ST. Diese ist 
jedenfalls für mich leicht gewöhnungsbedürftig aufgebaut, wenn man 
bisher die Std-Lib genutzt hat. So wollte ich Stück für Stück jede 
Komponente mal in Betrieb nehmen und das ging offensichtlich direkt 
schief.

Danke für den Hinweis bezüglich der Flash-Wait-States. Nach dem einfügen 
des CMD:

LL_FLASH_SetLatency( LL_FLASH_LATENCY_2 );

spätestens ein CMD vor dem HCLK vom HSI auf den PLL Ausgang umgeschaltet 
wird, läuft der Core jetzt auch weiter bei LL_RCC_PLLN_MUL_SYS = 64

Den Instruction Prefetch und den Cache habe ich vorerst unverändert 
gelassen. Der Cache ist nach Reset auch schon an.

Vielen Dank nochmals für die schnellen Hinweise

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Wenn dir die Lib nicht liegt, dann kannste auch direkt mit den CMSIS 
Definitionen auf den Register trommeln.

Die CMSIS Header liegen in:
Benutzer\STM32Cube\Repository\STM32Cube_FW_G0_V1.2.0\Drivers\CMSIS\Devic 
e\ST\STM32G0xx\Include