STM32G4: minimale Sequenz zum Einschalten des ADC1

[Raoul D. (raoul_d219)]

Hallo zusammen,

ich möchte den ADC1 eines Nucleo32G4-Boards mit dem G431 in Betrieb 
nehmen.

Dazu habe ich folgendes Vorgehen bisher (ohne HAL):

            RCC->AHB2ENR |= RCC_AHB2ENR_ADC12EN;
            
            MODIFY_REG(ADC1->CR, ADC_CR_DEEPPWD_Msk, 0x00 << ADC_CR_DEEPPWD_Pos); 
            ADC1->CR |= ADC_CR_ADVREGEN;
            
            wait_us(100);

            ADC1->ISR |= ADC_ISR_ADRDY; // clear flag
            
            // VREF ?
            
            ADC12_COMMON->CCR |= (0x0b << ADC_CCR_PRESC_Pos); // prescaler 256
            MODIFY_REG(ADC1->CFGR , ADC_CFGR_RES_Msk, (0x00 << ADC_CFGR_RES_Pos)); // 12 bit
            
            // temp sensor channel select (ADC1 INP16)
            
            ADC1->SQR1 = (0x00 << ADC_SQR1_L_Pos) | (16 << ADC_SQR1_SQ1_Pos);
            
            ADC1->CR |= ADC_CR_ADEN;
            
          while(!(ADC1->ISR & ADC_ISR_ADRDY)); //  ????

Das ADC_ISR_ADRDY geht allerding nie auf true.

Der Systemtakt und AHB Takt ist 170MHz.

Was mache ich falsch?

[Wastl (hartundweichware)]

Wenn ich von STM alles so mundgerecht serviert bekomme dann
gebe ich mich als faulen Sack und lasse CubeMX den Code
generieren.

Wenn ich das beispielhaft für einen G431 mache bekome ich
den folgenden übersichtlichen Code der (vermutlich doch)
alles beinhaltet. Und das ohne HAL-Funktionen zu verwenden.

Daran könntest du dich orientieren wenn du wirklich auf
Registerebene alles zu Fuss machen möchtest. Das kann jedoch
- wie so oft - stark fehlerbehaftet sein. Also viel Erfolg,
welchen Weg du auch immer beschreiten willst .....

/* ADC1 init function */
void MX_ADC1_Init(void)
{
  LL_ADC_InitTypeDef ADC_InitStruct = {0};
  LL_ADC_REG_InitTypeDef ADC_REG_InitStruct = {0};
  LL_ADC_CommonInitTypeDef ADC_CommonInitStruct = {0};

  LL_GPIO_InitTypeDef GPIO_InitStruct = {0};

  /* Peripheral clock enable */
  LL_AHB2_GRP1_EnableClock(LL_AHB2_GRP1_PERIPH_ADC12);
  
  LL_AHB2_GRP1_EnableClock(LL_AHB2_GRP1_PERIPH_GPIOA);
  /**ADC1 GPIO Configuration  
  PA0   ------> ADC1_IN1 
  */
  GPIO_InitStruct.Pin = LL_GPIO_PIN_0;
  GPIO_InitStruct.Mode = LL_GPIO_MODE_ANALOG;
  GPIO_InitStruct.Pull = LL_GPIO_PULL_NO;
  LL_GPIO_Init(GPIOA, &GPIO_InitStruct);

  /* ADC1 interrupt Init */
  NVIC_SetPriority(ADC1_2_IRQn, NVIC_EncodePriority(NVIC_GetPriorityGrouping(),0, 0));
  NVIC_EnableIRQ(ADC1_2_IRQn);

  /** Common config 
  */
  ADC_InitStruct.Resolution = LL_ADC_RESOLUTION_12B;
  ADC_InitStruct.DataAlignment = LL_ADC_DATA_ALIGN_RIGHT;
  ADC_InitStruct.LowPowerMode = LL_ADC_LP_MODE_NONE;
  LL_ADC_Init(ADC1, &ADC_InitStruct);

  ADC_REG_InitStruct.TriggerSource = LL_ADC_REG_TRIG_SOFTWARE;
  ADC_REG_InitStruct.SequencerLength = LL_ADC_REG_SEQ_SCAN_DISABLE;
  ADC_REG_InitStruct.SequencerDiscont = LL_ADC_REG_SEQ_DISCONT_DISABLE;
  ADC_REG_InitStruct.ContinuousMode = LL_ADC_REG_CONV_SINGLE;
  ADC_REG_InitStruct.DMATransfer = LL_ADC_REG_DMA_TRANSFER_NONE;
  ADC_REG_InitStruct.Overrun = LL_ADC_REG_OVR_DATA_PRESERVED;
  LL_ADC_REG_Init(ADC1, &ADC_REG_InitStruct);

  LL_ADC_SetGainCompensation(ADC1, 0);
  LL_ADC_SetOverSamplingScope(ADC1, LL_ADC_OVS_DISABLE);
  LL_ADC_DisableDeepPowerDown(ADC1);
  LL_ADC_EnableInternalRegulator(ADC1);
  ADC_CommonInitStruct.CommonClock = LL_ADC_CLOCK_ASYNC_DIV1;
  ADC_CommonInitStruct.Multimode = LL_ADC_MULTI_INDEPENDENT;
  LL_ADC_CommonInit(__LL_ADC_COMMON_INSTANCE(ADC1), &ADC_CommonInitStruct);
  LL_ADC_EnableIT_EOC(ADC1);
  LL_ADC_DisableIT_EOS(ADC1);
  /** Configure Regular Channel 
  */
  LL_ADC_REG_SetSequencerRanks(ADC1, LL_ADC_REG_RANK_1, LL_ADC_CHANNEL_1);
  LL_ADC_SetChannelSamplingTime(ADC1, LL_ADC_CHANNEL_1, LL_ADC_SAMPLINGTIME_2CYCLES_5);
  LL_ADC_SetChannelSingleDiff(ADC1, LL_ADC_CHANNEL_1, LL_ADC_SINGLE_ENDED);
}

[Niklas G. (erlkoenig)]

Versuch mal:

RCC->AHB2ENR |= RCC_AHB2ENR_ADC12EN;
__DSB ();
ADC1->CR = ADC_CR_ADVREGEN;
            
wait_us(100);
ADC1->ISR = ADC_ISR_ADRDY; // clear flag

Schau auch mal im Debugger was jeweils in den Registern steht (CR1, 
ISR).

Die Bits in ISR sind "rc_w1", also geht löschen wie oben gezeigt (kein 
OR).

[Irgend W. (Firma: egal) (irgendwer)]

Raoul D. schrieb:

> 0x00 << ADC_CR_DEEPPWD_Pos
> (0x00 << ADC_CFGR_RES_Pos)
> (0x00 << ADC_SQR1_L_Pos)

Kann mir mal jemand erklären was das sein soll?
Ich hätte eigentlich gedacht das hier eine Null n mal nach links 
geschiftet wird und dann immer noch Null ist. Aber zusammen mit dem mir 
unbekannten Makro "MODIFY_REG" scheint das wohl was anderes zu bewirken, 
sonst wäre es ja sinnlos und verwirrend?

[Raoul D. (raoul_d219)]

Niklas G. schrieb:
> Versuch mal:
>
>

RCC->AHB2ENR |= RCC_AHB2ENR_ADC12EN;
> __DSB ();
> ADC1->CR = ADC_CR_ADVREGEN;
> 
> wait_us(100);
> ADC1->ISR = ADC_ISR_ADRDY; // clear flag
> 
>

>
> Schau auch mal im Debugger was jeweils in den Registern steht (CR1,
> ISR).

CR1 gibt es ja nicht, Du meinst sicher CR

> Die Bits in ISR sind "rc_w1", also geht löschen wie oben gezeigt (kein
> OR).

Danke, das habe ich übersehen.

Die MB mit __DSB() ist m.E. unnötig und führt auch nicht zum Erfolg.

[N. M. (mani)]

Irgend W. schrieb:
> Kann mir mal jemand erklären was das sein soll?

Vermutlich spuckt der Code Generator immer den gleichen Code aus und 
trägt falls notwendig nur eine 1 ein.

Irgend W. schrieb:
> Ich hätte eigentlich gedacht das hier eine Null n mal nach links
> geschiftet wird und dann immer noch Null ist.

Ja, würde ich auch sagen.

Irgend W. schrieb:
> Aber zusammen mit dem mir unbekannten Makro "MODIFY_REG" scheint das
> wohl was anderes zu bewirken, sonst wäre es ja sinnlos und verwirrend?

Man könnte sagen es ist sinnlos. Man könnte auch sagen dass man dadurch 
direkt sieht was auf dem entsprechenden Bit steht. Manche Bit sind 
Default 0, manche 1.
Ich denke also das ist Ansichtssache.

[Raoul D. (raoul_d219)]

Wastl schrieb:
> Wenn ich von STM alles so mundgerecht serviert bekomme dann
> gebe ich mich als faulen Sack und lasse CubeMX den Code
> generieren.

Habe ich jetzt auch gemacht: geht trotzdem nicht. ADC_ISR_ADRDY bleibt 
false.

[Harry L. (mysth)]

Raoul D. schrieb:
> Habe ich jetzt auch gemacht: geht trotzdem nicht. ADC_ISR_ADRDY bleibt
> false.

Du sollst ja auch die dafür vorgesehen Callback-Funktionen nutzen!

[Andreas B. (abm)]

Hm, erstens fehlt die Kalibrierungsphase und zweitens ist der notwendige 
Ablauf im RM genau beschrieben, ADC on-off control 21.4.9. Beim G0 geht 
es bei mir so, wie im (zugehörigen) RM beschrieben (ohne diesen ganzen 
HAL-Krempel), und soweit ich auf den ersten Blick sehe, gibt's da auch 
keine wesentlichen Unterschiede zw. G0 und G4.

[Harry L. (mysth)]

Andreas B. schrieb:
> wie im (zugehörigen) RM beschrieben (ohne diesen ganzen
> HAL-Krempel),

Dieser ganz "HAL-Krempel" funktioniert aber i.d.R und bis auf ganz, ganz 
wenige Ausnahmen zuverlässig, frei von Nebenwirkungen und das sogar 
unter Berücksichtigung der letzten Eratas.

Während die Superchecker, die sich für schlauer halten als die Ings bei 
ST noch an ihrer Initialisierung herumfrickeln kann man sich 
HAL-sei-Dank bereits auf die eigentliche Aufgabe/Anwendung 
konzentrieren.

[Andreas B. (abm)]

Harry L. schrieb:
> Dieser ganz "HAL-Krempel" funktioniert aber i.d.R und bis auf ganz, ganz
> wenige Ausnahmen zuverlässig, frei von Nebenwirkungen und das sogar
> unter Berücksichtigung der letzten Eratas.
>
> Während die Superchecker, die sich für schlauer halten als die Ings bei
> ST noch an ihrer Initialisierung herumfrickeln kann man sich
> HAL-sei-Dank bereits auf die eigentliche Aufgabe/Anwendung
> konzentrieren.

Ach Gottchen, da regt sich mal wieder einer auf. Sei's drum, wer es so 
machen will (und für die simple GPIO-Init. gleich wer weiß wieviel Flash 
verbraten will), soll's doch gerne machen, was juckt's mich? Wenn jemand 
nicht mal die ADC-Initialisierung nach RM hin bekommt, ist das Ganze 
ohnehin ziemlich akademisch ...

[Harry L. (mysth)]

Andreas B. schrieb:
> und für die simple GPIO-Init. gleich wer weiß wieviel Flash
> verbraten will

Allein mit diesem Satz hast du dich vollkommen disqualifiziert.
Man sollte nicht über Dinge schwadronieren, die man nicht kennt/von 
denen man keine Ahnung hat/ die man nicht verstanden hat.

Flash ist i.d.R auch reichlich vorhanden, und für ungenutzten Speicher 
gibts auch kein Geld zurück, und auch, wenn der generierte Code etwas 
länger erscheint, gilt das nicht zwangläufig für das, was der 
Compiler/Linker daraus macht.

Der generierte Code ist jedenfalls gut verständlich und dokumentiert - 
im Gegensatz zu den meisten Frickler-Ejakulaten.

[Raoul D. (raoul_d219)]

Alle bisherigen Antworten waren leider falsch.

Es fehlte ganz simpel:

            RCC->CCIPR |= 0x02 << RCC_CCIPR_ADC12SEL_Pos;