Skip to main content
Explorer II
May 26, 2025
Solved

adc fails to initialize

  • May 26, 2025
  • 14 replies
  • 1445 views

Board: stm32h753zi nucleo

Firmware & CubeMX: latest version

I have configured the adc to continous conversion and DMA output. The initialization fails in main.c in HAL_ADC_INIT. I stepped through the HAL lib and saw that LL_ADC_IsInternalRegulatorEnabled returns the HAL_ERROR.

The docstring of this function says

 /* Verification that ADC voltage regulator is correctly enabled, whether */
 /* or not ADC is coming from state reset (if any potential problem of */
 /* clocking, voltage regulator would not be enabled). */
 if (LL_ADC_IsInternalRegulatorEnabled(hadc->Instance) == 0UL)

I do not find any documents online which describe how the clock frequency of the adc should be set up. Could you please give me a hint.

    This topic has been closed for replies.
    Best answer by mo_krauti

    I discovered my error. I have built some cpp classes as abstractions for io functionality. There is also an analog class in which I started the analog DMA transfer in the constructor. Then I created an global instances of this class so the constructor interfered with the ADC startup logic in main. I was sure that the error could not originate from my abstraction code because the fault already occurred in the CubeMX generated main.c, but I did not think of the constructor of the global variable also being called at startup.

    Thank you very much for your help.

    14 replies

    Super User
    June 12, 2025

    > After resetting the board the State variable is already set to 0x00000100UL HAL_ADC_STATE_REG_BUSY on the first breakpoint.

    Data breakpoints are not precise, so the processor stops a couple of cycles *after* the given variable is written (unlike the usual instruction breakpoints, which stop *just before* the marked instruction is executed). So it's more tricky to use during debugging, as you have to "walk back" somewhat, and in some cases that's simply impractical, e.g. if the write occurs just before a function return.

    Another way to potentially tackle this is to look at Cube/HAL sources (and potentially yours, too) to find instances where HAL_ADC_STATE_REG_BUSY symbol is used.

    As I've said I don't use Cube/HAL so these are generic recommendations. Maybe somebody more versed in Cube/HAL will chime in and enlighten us on what can potentially go wrong in that code.

    JW

    mo_krautiAuthor
    Explorer II
    June 12, 2025

    Thank you for the hint about data breakpoints. Now I see that just before the breakpoint, the State is really written:

     /* Set ADC state */
     /* - Clear state bitfield related to regular group conversion results */
     /* - Set state bitfield related to regular operation */
     ADC_STATE_CLR_SET(hadc->State,
     HAL_ADC_STATE_READY | HAL_ADC_STATE_REG_EOC | HAL_ADC_STATE_REG_OVR | HAL_ADC_STATE_REG_EOSMP,
     HAL_ADC_STATE_REG_BUSY);

    But this should just clear the adc.

    I noticed that when starting up HAL_ADC_Start_DMA is called. But I only do this later in the code and is is stuck in the Error Handler before. Somehow this call must survive my openocd reset routine and still execute afterwards.

    mo_krautiAuthorAnswer
    Explorer II
    June 12, 2025

    I discovered my error. I have built some cpp classes as abstractions for io functionality. There is also an analog class in which I started the analog DMA transfer in the constructor. Then I created an global instances of this class so the constructor interfered with the ADC startup logic in main. I was sure that the error could not originate from my abstraction code because the fault already occurred in the CubeMX generated main.c, but I did not think of the constructor of the global variable also being called at startup.

    Thank you very much for your help.

    Super User
    June 12, 2025

    Thanks for coming back with the solution.

    JW