Couple of points for those who may run into some issues with following the exercise: 1. In a newer version of a HAL library call to the function HAL_ADCEx_Calibration_Start() requires another argument of ADC input configuration. For reading the temp sensor I use the following call: HAL_ADCEx_Calibration_Start(&hadc1, ADC_SINGLE_ENDED) 2. The function for starting the DMA requires second argument (pointer to the buffer) to be of the type uint32_t and in the exercise we define ADC_buffer[] as uint16_t. There are two workarounds: casting the value to be 32-bit: HAL_ADC_Start_DMA(&hadc1, (uint32_t*)&ADC_buffer, ADC_BUF_SIZE) Another way is to declare ADC_buffer[] as uint32_t, but then it is necessary to change DMA settings to send data in words and not half-words. 3. The example which is provided in the session stops DMA in HAL_ADC_ConvCpltCallback(). If you want to continue with measurements, you need to either delete the DMA stop call from here or restart DMA after processing data in the while() loop in main.
I've been using NUCLEO-F446RE with this series of videos and it works fine. Some functions are not available but apparently incorporated into other functions. Only issue: At the '10 ADC DMA TIM HAL lab' I find I have no access to the LL_ADC functions as they are all grayed out. Is there some info or settings missing from the video to get these activated in the IDE? Just seems like there's a missing step or two. Can't seem to make it work. The LL .h and .c files are there, just not available.
Hello, same problem for me with a L073 MCU. I have check in the sources. and I do not know why, but stm32g0xx_hal_adc.h include stm32g0xx_ll_adc.h, while stm32l0xx_hal_adc.h does not include stm32l0xx_ll_adc.h (must be the same for yours MCU family) In fact, every informations I found is that HAL and LL should not be mixed. So I do not know why it is done (and even possible) in this example. Except to have a "nice example"?!
@@antoinenauzet1568 Yes, there are indications that we shouldn't use HAL and LL drivers together, BUT, it needs to be done to use the Temperature Conversion macro used in this video tutorial. I posted and searched on the ST site and had some help and also found some information. First, the manual for the chip or board has a section on using both drivers together and provides two ways to do it. First, add the USE_FULL_LL_DRIVER symbol to the C preprocessor configuration in CubeIDE. This didn't work for me for some reason. The other is to include the LL .h files in the main.h file. In this example they would be stm32f4xx_ll_adc.h and stm32f4xx_ll_rcc.h . This worked for me and generated the necessary LL files to make the example work. Another suggestion that I found was to go back into CubeMX and activate another ADC but check the box so no code is generated, then rebuild the file. This generated all of the LL driver files, not just the two files shown in the video, and this made all of the LL code accessible to the program. I'm not sure why the suggestions in the manual for the MCU didn't work as presented with the USE_FULL_LL_DRIVER symbol. I just assume that I have something configured incorrectly. No further response on the best way to do it from ST and no response from the presenter of the video.
@@gtgarage Indeed, after more research, I also found information about mixed HAL and LL used together. I tried to include the files in my main.h, but as they are not in the project (STM32CubeMX copy only used files in the project), it generate an error. Do you copy them manually?v For me, adding the USE_FULL_LL_DRIVER does not work either, again because the files ll are not included in the project. And I have only one ADC on my Micro, so I cannot use the other solution. Still searching!!
@@antoinenauzet1568 Yes, add the .h files for the LL drivers into the main.h file manually and make sure they are in the /* Private Includes */ section and between the /* USER CODE BEGIN Includes */ tags otherwise the lines will be removed the next time you rebuild the code.
@@gtgarage A little more information here: community.st.com/s/question/0D53W00000IpJGNSA3/how-to-have-both-hal-and-ll-driver-files-for-the-same-component?t=1600932250371 No possibility to have automatically HAL and LL for the same driver. You have to do it mannualy.
With STM32Cube_FW_G0_V1.4.1 and CubeIDE V1.6.0 the ADC DMA TIM HAL Line ~50 uint16_t causes a warning unless changed to uint32_t. With or without that during the debug session I never hit the break at line 304: void HAL_ADC_ConvCpltCallBack(ADC_HandleTypeDef* hadc) - it reads the ADC but never does the break point. The basics videos need to be redone with the current CubeIDE and professional sound engineers, if the CC doesn't work that is a good indication of sound issues.
The break point is never hit because your function's name is not exactly (case sensitive) the same name as the function in the HAL library (...Callback and not ...CallBack as in your case). The HAL framework defines a __weak function in its library (search the file ...hal_adc.c) and then calls it whenever the ADC conversion is completed. Your work in the main code is to redefine (and thus override) this function to implement the logic of your application, in this case HAL_ADC_Stop_DMA(&hadc1). If you analyze the main function, you can see that it never explicitly call the HAL_ADC_ConvCpltCallback function. The function is still called indirectly (through the interrupt mechanism, I guess). When you write your ...CallBack function it does not override ...Callback function because of case sensitive and the compiler recognizes it as a new function and does not throw error when compiling. However, this function is never called in the main function and that is why you never hit the break.
You probably figured it out by yourself by now but I will leave this comment here for other people as there is no explanation in the video. The ADC buffer type really should be uint32_t to not trigger compilation warnings but in order this to work you have to change the configuration of the DMA in ADC1. Particularly the Data Width on Memory side should be changed from Half Word to Word. Then there are no warnings after compilation and the temperature values are measured correctly.
Hi. Thanks for a great series of tutorials. I've been using a Nucleo L053 for this. So far so good. However on last part of this tutorial, I always end up with an abort error from the HAL_ADC_DMA_Stop function: hdma->ErrorCode = HAL_DMA_ERROR_NO_XFER;. Hence it does not go to pre-processing part . Could you maybe pointing to what I may be doing wrong?
@STMicro tmin of the temp sensor is 5us and Tmin(ADC config) = 79.5*0.125 = 9us , the minimal value is 5us to sample temp sensor , we should go faster than that , not slower with 9us !!!
I'm confused how to get it done for multichannel adc. Like i only need one conversion per channel and i have 3 channel. So the destination buffer should be size[3] OR the will be a two dimensional array with size[3][1] Can anyone help.
Couple of points for those who may run into some issues with following the exercise:
1. In a newer version of a HAL library call to the function HAL_ADCEx_Calibration_Start() requires another argument of ADC input configuration. For reading the temp sensor I use the following call: HAL_ADCEx_Calibration_Start(&hadc1, ADC_SINGLE_ENDED)
2. The function for starting the DMA requires second argument (pointer to the buffer) to be of the type uint32_t and in the exercise we define ADC_buffer[] as uint16_t. There are two workarounds: casting the value to be 32-bit: HAL_ADC_Start_DMA(&hadc1, (uint32_t*)&ADC_buffer, ADC_BUF_SIZE)
Another way is to declare ADC_buffer[] as uint32_t, but then it is necessary to change DMA settings to send data in words and not half-words.
3. The example which is provided in the session stops DMA in HAL_ADC_ConvCpltCallback(). If you want to continue with measurements, you need to either delete the DMA stop call from here or restart DMA after processing data in the while() loop in main.
cant believe this is an official st video
The áudio quality might be better. It is whispering and with some pulsing into the Mic.
Very helpful video. Thank you.
I've been using NUCLEO-F446RE with this series of videos and it works fine. Some functions are not available but apparently incorporated into other functions. Only issue: At the '10 ADC DMA TIM HAL lab' I find I have no access to the LL_ADC functions as they are all grayed out. Is there some info or settings missing from the video to get these activated in the IDE? Just seems like there's a missing step or two. Can't seem to make it work. The LL .h and .c files are there, just not available.
Hello, same problem for me with a L073 MCU. I have check in the sources. and I do not know why, but stm32g0xx_hal_adc.h include stm32g0xx_ll_adc.h, while stm32l0xx_hal_adc.h does not include stm32l0xx_ll_adc.h (must be the same for yours MCU family)
In fact, every informations I found is that HAL and LL should not be mixed. So I do not know why it is done (and even possible) in this example. Except to have a "nice example"?!
@@antoinenauzet1568 Yes, there are indications that we shouldn't use HAL and LL drivers together, BUT, it needs to be done to use the Temperature Conversion macro used in this video tutorial. I posted and searched on the ST site and had some help and also found some information. First, the manual for the chip or board has a section on using both drivers together and provides two ways to do it. First, add the USE_FULL_LL_DRIVER symbol to the C preprocessor configuration in CubeIDE. This didn't work for me for some reason. The other is to include the LL .h files in the main.h file. In this example they would be stm32f4xx_ll_adc.h and stm32f4xx_ll_rcc.h . This worked for me and generated the necessary LL files to make the example work. Another suggestion that I found was to go back into CubeMX and activate another ADC but check the box so no code is generated, then rebuild the file. This generated all of the LL driver files, not just the two files shown in the video, and this made all of the LL code accessible to the program. I'm not sure why the suggestions in the manual for the MCU didn't work as presented with the USE_FULL_LL_DRIVER symbol. I just assume that I have something configured incorrectly. No further response on the best way to do it from ST and no response from the presenter of the video.
@@gtgarage Indeed, after more research, I also found information about mixed HAL and LL used together.
I tried to include the files in my main.h, but as they are not in the project (STM32CubeMX copy only used files in the project), it generate an error. Do you copy them manually?v
For me, adding the USE_FULL_LL_DRIVER does not work either, again because the files ll are not included in the project.
And I have only one ADC on my Micro, so I cannot use the other solution.
Still searching!!
@@antoinenauzet1568 Yes, add the .h files for the LL drivers into the main.h file manually and make sure they are in the /* Private Includes */ section and between the /* USER CODE BEGIN Includes */ tags otherwise the lines will be removed the next time you rebuild the code.
@@gtgarage A little more information here:
community.st.com/s/question/0D53W00000IpJGNSA3/how-to-have-both-hal-and-ll-driver-files-for-the-same-component?t=1600932250371
No possibility to have automatically HAL and LL for the same driver. You have to do it mannualy.
Cant even see the code. Atleast increase the font size or use the zoom feature of the screen recorder. And the audio is low and wisphering sometimes.
Do we need to make conversion continuous?if not, why?
if I use DMA with Adc , Don't I need to use ADC_GetValye and poll_for_conversion?
hello, wondering if anyone can tell what do I need to do if I want to keep reading the temp sensor. thanks
If you stil need an answer, you can call HAL_ADC_Start_DMA(&hadc1, ADC_Buffer, ADC_BUF_SIZE) at the end of the callback function.
Does this do any good when setting up ADC and takes 30 minutes to do so.
With STM32Cube_FW_G0_V1.4.1 and CubeIDE V1.6.0 the ADC DMA TIM HAL Line ~50 uint16_t causes a warning unless changed to uint32_t. With or without that during the debug session I never hit the break at line 304: void HAL_ADC_ConvCpltCallBack(ADC_HandleTypeDef* hadc) - it reads the ADC but never does the break point. The basics videos need to be redone with the current CubeIDE and professional sound engineers, if the CC doesn't work that is a good indication of sound issues.
Hi there, thanks for your question - may we point you towards our community.st.com, where you will find a team of people who can answer you directly ?
The break point is never hit because your function's name is not exactly (case sensitive) the same name as the function in the HAL library (...Callback and not ...CallBack as in your case).
The HAL framework defines a __weak function in its library (search the file ...hal_adc.c) and then calls it whenever the ADC conversion is completed. Your work in the main code is to redefine (and thus override) this function to implement the logic of your application, in this case HAL_ADC_Stop_DMA(&hadc1).
If you analyze the main function, you can see that it never explicitly call the HAL_ADC_ConvCpltCallback function. The function is still called indirectly (through the interrupt mechanism, I guess). When you write your ...CallBack function it does not override ...Callback function because of case sensitive and the compiler recognizes it as a new function and does not throw error when compiling. However, this function is never called in the main function and that is why you never hit the break.
You probably figured it out by yourself by now but I will leave this comment here for other people as there is no explanation in the video.
The ADC buffer type really should be uint32_t to not trigger compilation warnings but in order this to work you have to change the configuration of the DMA in ADC1. Particularly the Data Width on Memory side should be changed from Half Word to Word. Then there are no warnings after compilation and the temperature values are measured correctly.
Hi. Thanks for a great series of tutorials. I've been using a Nucleo L053 for this. So far so good. However on last part of this tutorial, I always end up with an abort error from the HAL_ADC_DMA_Stop function: hdma->ErrorCode = HAL_DMA_ERROR_NO_XFER;. Hence it does not go to pre-processing part . Could you maybe pointing to what I may be doing wrong?
Hi there, thanks for your question - may we point you towards our community.st.com, where you will find a team of people who can answer you directly ?
Ya lo optimice, quitándole las interrupciones del DMA y poniéndolo en continuo para hacer un muestreo de 1Mhz gracias, unos amos
@STMicro
tmin of the temp sensor is 5us and Tmin(ADC config) = 79.5*0.125 = 9us , the minimal value is 5us to sample temp sensor , we should go faster than that , not slower with 9us !!!
@Virtex AlphaThanks
Hello please Tell the difference between RESET (UG bIt FROM TIMx_EGR) AND UPDATE EVENT because it seems both are the same.Thank you in advance
Hello, Visit our online community to find answers to your technical questions and share ideas with your developers and ST experts : community.st.com
Nice video.
The documentation "10 ADC DMA TIM HAL lab.pdf" is incomplete
would you be referring to the availability of the LL driver macros?
I'm confused how to get it done for multichannel adc.
Like i only need one conversion per channel and i have 3 channel. So the destination buffer should be size[3] OR
the will be a two dimensional array with size[3][1]
Can anyone help.
Hi there, thanks for your question - may we point you towards our community.st.com, where you will find a team of people who can answer you directly ?
Nice video, keep it up, thank you :)
Thank you.
try using AI for your voice next time