2020-03-27 02:58 PM
Hello! I discovered STM32CubeIDE recently and I've really been enjoying using it. The device configuration tool makes it easy to set up the parameters.
In my project I want to decide at startup whether a certain pin should be an ADC or GPIO_Output. I tried to do this by setting up the pin as ADC in the normal way using the device configuration tool, copying the appropriate code into my 'user code' sections, and then removing the configuration.
I also had to copy the stm32f4xx_hal_adc* files into the 'Core' section, and define HAL_ADC_MODULE_ENABLED for the preprocessor. Although it compiles, the result is that it hangs inside HAL_ADC_PollForConversion waiting for the ADC_FLAG_EOC (end of conversion) flag to be set. My code is very simple, this works nicely when using the definitions generated by the tool:
HAL_ADC_Start(&hadc1);
HAL_ADC_PollForConversion(&hadc1, HAL_MAX_DELAY);
uint16_t val = HAL_ADC_GetValue(&hadc1);
Looking into this a bit deeper, it seems the first difference in behavior between the two setups is in HAL_ADC_Start, where (in my setup) this condition is not met so a __HAL_ADC_ENABLE is attempted:
if((hadc->Instance->CR2 & ADC_CR2_ADON) != ADC_CR2_ADON)
{
/* Enable the Peripheral */
__HAL_ADC_ENABLE(hadc);
Following this, the next condition is also not met:
/* Start conversion if ADC is effectively enabled */
if(HAL_IS_BIT_SET(hadc->Instance->CR2, ADC_CR2_ADON))
This causes HAL_ADC_Start to exit leaving the handle locked by __HAL_LOCK, and giving HAL_OK as the return value (which doesn't seem right).
Is there some other setting I'm missing that's required to enable the ADC, without needing to set it up in the configuration tool? Or perhaps there is a better way to achieve what I'm trying to do here....
Solved! Go to Solution.
2020-03-27 03:32 PM
As usual, I spend hours struggling with something and then figure it out immediately after posting a question.
It's simply because I did not also copy these functions from stm32f4xx_hal_msp.c in the tool-generated version (I did not realize that files other than main.c were being automagically modified):
void HAL_ADC_MspInit(ADC_HandleTypeDef* hadc)
void HAL_ADC_MspDeInit(ADC_HandleTypeDef* hadc)
The reason this problem was so stealthy is because there are 'weak' versions of these which will be used by default, so I never noticed anything missing.
2020-03-27 03:32 PM
As usual, I spend hours struggling with something and then figure it out immediately after posting a question.
It's simply because I did not also copy these functions from stm32f4xx_hal_msp.c in the tool-generated version (I did not realize that files other than main.c were being automagically modified):
void HAL_ADC_MspInit(ADC_HandleTypeDef* hadc)
void HAL_ADC_MspDeInit(ADC_HandleTypeDef* hadc)
The reason this problem was so stealthy is because there are 'weak' versions of these which will be used by default, so I never noticed anything missing.
2020-03-27 03:34 PM
STM32CubeMX is not very well set up to handle dynamic changes to pins. It assumes a pin has a function that never changes.
If you want to get around this, you need to implement that logic in user code somewhere to duplicate the initialization that CubeMX would otherwise do. This includes enabling the clock, initializing the pins, and initializing the peripheral.
HAL_DAC_Start aborting and leaving the handle locked sounds like a bug, but one that is only caused by an improper initialization.
> Is there some other setting I'm missing that's required to enable the ADC, without needing to set it up in the configuration tool?
You haven't provided your initialization code, so it's hard to know what you're missing.