Can the definition of a HAL_ADC_ConvCpltCallback interfere with the DAC/DMA?

[Clem1]

I am experimenting with an STM32F3348-DISO board. A waveform is generated using the timer TIM6 update event and DMA channel 3 (cyclic mode). At the same time, I am using an ADC to read the same waveform into a dedicated buffer (DMA channel 1), and the events are triggered by the same timer, TIM6. I run the HAL_DAC_Start_DMA() only once and the HAL_ADC_Start_DMA() in a loop, every two seconds.

So far so good. The only problem is that as soon as I even just define the HAL_ADC_ConvCpltCallback(), the DAC stops outputting the waveform, and I can just see a constant DC value. Could it be that defining (and consequently calling) the callback interferes with the DMA, even on other DMA channels? Does the HAL_ADC_Start_DMA() "think" something like: All right, we call back the function (because it is defined) and have done the job sampling all data, so let's stop the DMA globally?

I wonder what is happening here...

[KnarfB]

No, the definition should have no influence, because it just overrides the weak definition of the very same function already present in stm32f3xx_hal_adc.c.

Don't have any clue except for the general: could it be a buffer overflow, wrong interrupt priorities, and: compare the register settings before and after.

hth

KnarfB

[waclawek.jan]

Cube is open source, so you can look at its sources and single-step whatever calls HAL_ADC_ConvCpltCallback(). You can also read out and check/compare registers of TIM, DMA and DAC, for the working and non-working case, to find out, what has changed. You can use data breakpoints (watchpoints) to find out, what code changes any register.

JW

[Clem1]

Thank you for both of your inputs. I have looked into the  stm32f3xx_hal_adc.c source file and I did find a weak definition for the HAL_ADC_ConvCpltCallback, which does nothing, so it is surprising that overwriting the function in the main.c file has any effect whatsoever, especially if the function does nothing.

I actually figured out how to solve the problem, I know the how but not the why:

It seems that the program requires a definition (i.e. overwriting) for the Half Conversion callback. It does not matter whether the full conversion callback is defined or not, but the half conversion is required as an absolute necessity for the DAC to continue.

void HAL_ADC_ConvHalfCpltCallback(ADC_HandleTypeDef* hadc)

{

//HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_7);

}

Why redefining an empty function does anything is really beyond me as a) the weak function doing nothing is simply overwritten by another function and b) although the overwritten function is not located in the same memory location within the .text flash memory section (0x8001A88 instead of 0x800153E in my case) it should not really matter as the function does nothing.

I am familiar with the live expressions, but to be honest, I simply do not have the time to study the MCU's datasheet and study make sense of what each and every SFR register is supposed to be doing during the debug. I need to work on a higher level and be partly ignorant of the MCU's inner workings, that is what I thought the (hopefully tried and tested) HAL framework was for.

So for now I know about the how but not the why. I just have to leave it there as there are many more functions that are left to be implemented.

Thank you for your help

Clem