2025-04-01 11:29 PM
Hi,
I'm encountering a couple of issues while using STM32CubeMX version 6.13.0 to generate code for a project involving an STM32G0B1 MCU. The project utilizes one ADC, DMA, and TIM6 as the trigger conversion source. I'm comparing the generated LL driver code with the HAL driver code generation.
My first issue concerns the TIM6 configuration. When setting the Prescaler to 64-1 and the Counter Period to 125-1 in STM32CubeMX, the generated code includes something like "64 - DEFINE...". I had to manually modify the TIM6 configuration in the generated files to set the Prescaler to 63 and the Counter Period to 124 to resolve this.
The second issue relates to a difference in runtime behavior. The same function, which is called after each ADC value conversion, takes approximately 30 microseconds to execute with the HAL driver generated code. However, with the LL driver generated code, the same function takes around 39 microseconds. I'm trying to understand why this function takes longer to execute with the LL driver code, as it's the same function with same code.
Could you please provide some insight into these issues?
Thank you for your time and assistance.
2025-04-10 3:34 AM
Hello @Kadir,
Thank you for bringing this to our attention.
For the first issue, I'm able to reproduce the described misbehavior. I reported it internally.
But in the meanwhile, you will need to change the cell parameter to "No check" as described in this post and shown in the screenshot bellow.
>I'm trying to understand why this function takes longer to execute with the LL driver code, as it's the same function with same code.
For the second issue, Could you give more details about this behavior? What function did you talk about? Is it a HAL, LL... function?
How did you calculate these times 30 microseconds and 39 microseconds? Could you please share codes and results?
Also, I recommend you to test these behavior with latest STM32CubeMX 6.14.0 version.
Internal ticket number: 207328 (This is an internal tracking number and is not accessible or usable by customers).
Thank you.
Kaouthar
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-04-10 4:27 AM
Hello Kaouthar,
for second issue here more details:
so the execution time should be the same. but it is not.
BR
Kadir
2025-04-10 6:55 AM
Hello @Kadir,
Thank you for this explanation.
I couldn't find any LL_ADC_ConvCpltCallback function in STM32CubeG0 firmware.
Could you please share your projects (with HAL and LL drivers) and results screenshots?
Thank you.
Kaouthar
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-04-14 2:00 AM
Hi,
yes there is no generated LL_ADC_ConvCpltCallback. I have added it, similiar to the "HAL_ADC_ConvCpltCallback", which is called from DMA1_Channel1_IRQHandler.
I wanted to measure it again but I realize another issue now, when I run the application in debug mode the function "DMA1_Channel1_IRQHandler" is triggered every 250 us and it calls LL_ADC_ConvCpltCallback and there I measure the execution time with a GPIO. When I run it in Release-Mode it does not work anymore. So, the Out-Pin is not toggling anymore.
So, I have to solve this issue first. What could be the reason?
Please find the attached cubemx-config-file.
BR
Kadir
2025-04-14 2:24 AM
with the following code I have checked again with debug and release binaries. Debug OK, Release no toggle.
void DMA1_Channel1_IRQHandler(void)
{
/* USER CODE BEGIN DMA1_Channel1_IRQn 0 */
//extern void LL_ADC_ConvCpltCallback(void);
if (LL_DMA_IsActiveFlag_TC1(DMA1))
{
LL_DMA_ClearFlag_TC1(DMA1);
// Datenverarbeitung hier (z.B. adc_buffer auswerten)
//LL_ADC_ConvCpltCallback();
LL_GPIO_TogglePin(GPIOA, LL_GPIO_PIN_8); // TIMER-ISR 250 us intervall
}
// Transfer Error Interrupt
if (LL_DMA_IsActiveFlag_TE1(DMA1))
{
LL_DMA_ClearFlag_TE1(DMA1);
Error_Handler();
}