Issue with STM32L432KC Nucleo and ADC

[XaviPacheco]

Have anyone programmed the STM32L432KC nucleo? I'm having hard time trying to simply turn a led on. I'm using CubeMx with Hal Library. I've set the pin as output, and used the following line: HAL_GPIO_WritePin(GPIOB, GPIO_PIN_7, GPIO_PIN_SET);

I had enabled an analog input for ADC. If I disable the ADC, the controller works fine, but if it is enabled, I can't do anything with my micro, it inhibits itself.

[newbrain]

Not that specific Nucleo, but many others, with and without HAL or LL...

The HAL is "a bit" bloated and has some bugs (much less than other vendor provided libraries I have seen, though) but it generally works.
It gets some time to get used to its conventions, though CubeMX is good help in generating complete initialization code.

Did you try debugging to see where your code gets stuck?
Are you enabling interrupts but not servicing them?

Without your code, it's next to impossible to give a meaningful answer  , so help us help you!

[XaviPacheco]

This is the main code generated by Cube Mx. I added a few lines in the while loop. I haven't tried debugging it. I'm not enabling interrupts.

[XaviPacheco]

The while loop never executes. So, something is happening before that, i.e, at the initialization code. I'm using SW4STM32.

[XaviPacheco]

Still haven't found the exact solution, but I'm closer to find the problem. The issue has to do with the clock. And something goes wrong in this fragment:

PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_ADC;
  PeriphClkInit.AdcClockSelection = RCC_ADCCLKSOURCE_PLLSAI1;
  PeriphClkInit.PLLSAI1.PLLSAI1Source = RCC_PLLSOURCE_MSI;
  PeriphClkInit.PLLSAI1.PLLSAI1M = 1;
  PeriphClkInit.PLLSAI1.PLLSAI1N = 16;
  PeriphClkInit.PLLSAI1.PLLSAI1P = RCC_PLLP_DIV7;
  PeriphClkInit.PLLSAI1.PLLSAI1Q = RCC_PLLQ_DIV2;
  PeriphClkInit.PLLSAI1.PLLSAI1R = RCC_PLLR_DIV2;
  PeriphClkInit.PLLSAI1.PLLSAI1ClockOut = RCC_PLLSAI1_ADC1CLK;
  if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit) != HAL_OK)
  {
    _Error_Handler(__FILE__, __LINE__);
  }

[XaviPacheco]

Note that the compiler doesn't throw errors. Everything compiles well, but the code does nothing. As I said, if remove the ADC, then the code works. Strictly speaking, the problem goes away if the ADC clock configuration is removed. So, certainly, I might no be setting the right clock for the ADC.

[XaviPacheco]

And this is the clock tree that I have

[newbrain]

The while loop never executes. So, something is happening before that, i.e, at the initialization code. I'm using SW4STM32.

At first glance, I notice two things:

• The call to HAL_ADC_Init(&hadc1); is redundant, though I don't think that should be a problem.
  The function is already called by MX_ADC1_Init().
• In the SystemClock_Config() call there's one line missing:

Code: [Select]

...
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_MSI;
  RCC_OscInitStruct.PLL.PLLM = 1;  // <- This line is missing
  RCC_OscInitStruct.PLL.PLLN = 16;
...


The missing value will cause a later check to fail and invoke the error handler (an infinite loop).
Most probably, you have inadvertently deleted it, as I'm sure it is generated by CubeMX.

If I have time, I might give the code an actual run (with an STM32L476).

[XaviPacheco]

I'm sure I'm not missing that line, as I regenerated the code with CubeMx, and haven't changed anything. Futhermore, the problem is with the  PeriphClkInit variable, not with  RCC_OscInitStruct (I think). Because if I remove the PeriphClkInit variable, the problem would be solved. But that variable is needed in order to set the ADC clock.

[newbrain]

I'm sure I'm not missing that line, as I regenerated the code with CubeMx, and haven't changed anything. Futhermore, the problem is with the  PeriphClkInit variable, not with  RCC_OscInitStruct (I think). Because if I remove the PeriphClkInit variable, the problem would be solved. But that variable is needed in order to set the ADC clock.

So the code you attached is not the same code you are running...
As:
1. The line is definitely missing in the attached main.c, and, in fact, it will hang while trying to set the ADC clock (as the PLLM by default will not match the one requested for the peripheral).
2. When you regenerate the code, the calls to HAL_ADC_Init() and HAL_ADC_Start() would disappear, as they are not in an /* USER CODE ... */ bracket.

Difficult to say more in this case.

[XaviPacheco]

Okay. I'll check again, and be back. I will upload the code generated by CubeMx again without touching it.

[newbrain]

Okay. I'll check again, and be back. I will upload the code generated by CubeMx again without touching it.

Good!
In the meantime, I have tried the following:

• Generated the code for a Nucleo L476.
• Compared it with yours: see below for the findigs.
• Brought in the main loop and the HAL_ADC_Start().

Note:

• I had to use a different ADC channel, as channel 8 pin is connected to the UART
• I used the LED (PA5) and a toggle rather than a set in the main loop, to easily check on the scope/DMM that the loop was running.

Everything works as intended, and I found another issue with the original main.c you attached, in MX_ADC_Init():

Code: [Select]

  sConfig.Rank = 1;The value 1 is definitely wrong here, as that field contains an encoded indication of which SQRx register to fill, and at which bit offset.
The correct line is:

Code: [Select]

  sConfig.Rank = ADC_REGULAR_RANK_1; // evaluates to 6, the bit position of the first conversion channel in ADC1_SQR1

No other significant differences were found, apart the PLLM one.

HTH.

[XaviPacheco]

• In the SystemClock_Config() call there's one line missing:

Code: [Select]

...
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_MSI;
  RCC_OscInitStruct.PLL.PLLM = 1;  // <- This line is missing
  RCC_OscInitStruct.PLL.PLLN = 16;
...


The missing value will cause a later check to fail and invoke the error handler (an infinite loop).
Most probably, you have inadvertently deleted it, as I'm sure it is generated by CubeMX.

This has solved the problem! I included that line manually. Although I regenerated the code and I'm pretty sure (100%) that CubeMx didn't write that line. I will have to check my version or something similar.

Thank you so much for your support! I don't think I was going to find this solution by myself, by now.

[newbrain]

 
Glad to have been of some help!
 

But now...

[XaviPacheco]

My version is the problem. Mine is out of date. I will update it now.