cancel
Showing results for 
Search instead for 
Did you mean: 

the adc result in dual mode are not in the right order

H.Darwish
Associate II

hello

i am using stm32f103 for reading a 10 adc channels and i am using Dual mode regular simultaneous with DMA , the result are loaded in a buffer.

the problem is the loaded data from the ADC1 are in the right order (1st data is from 1st channel)

but the data from ADC2 are in the right sequence , for example : the last register in the buffer array is corresponding to the rank 3 of ADC2

how i can fix this

10 REPLIES 10

You know you could have just edited your original post/question.

Not using CubeMX+HAL+F1 combination here.

Couple of observations about F1:

Should not enable DMA until after calibration.

If lighting off another transfer in the callback consider using continuous mode, with circular DMA, with a double size buffer, managed the the DMA HT and TC interrupt/callback to manage in the inactive half.

The samples should be in interleaving pairs. With 5 samples on each it is going to be calling the IRQ a lot.

Don't view this functionality in the debugger. If you want to observe output values, use a non-volatile buffer and print to terminal. Or record much larger datasets.

Have previously post SPL examples

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
H.Darwish
Associate II

I had tried the same code without the callibration of the ADC, same problem appears,and also iam not using the adc in continuous mode, i make trigger after each DMA callback.

So why do you think that the saples of the adc2 overlaped.

Thanks for your help

>>and also iam not using the adc in continuous mode, i make trigger after each DMA callback.

Yes, I know, I wouldn't do that.

>>So why do you think that the samples of the adc2 overlapped.

How are you inspecting/logging this data?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
H.Darwish
Associate II

>>>How are you inspecting/logging this data?

the adc buffer in initialized as volatile uint16_t monitored using st-link debugger.

I said this earlier "Don't view this functionality in the debugger. If you want to observe output values, use a non-volatile buffer and print to terminal. Or record much larger datasets."

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
H.Darwish
Associate II

i had tried also to print the values to treminal ,same result.

its really strange the values sampled by the adc1 are in right sequence , and the samples from the adc2 are not.

the steps that i am doing is :

in main function :

 1-HAL_ADC_Start(&hadc2);

 2-HAL_ADCEx_MultiModeStart_DMA(&hadc1,(uint32_t*)adc_buff,5);

in HAL_ADC_ConvCpltCallback function :

1-HAL_ADCEx_MultiModeStart_DMA(&hadc1,(uint32_t*)adc_buff,5);

am i missing anything?

AvaTar
Lead

I don't do Cube/HAL either.

With multi-channel ADC and DMA, I used validate the setup the following way:

- Set consecutively on ADC channel to about 1.5 .. 3.0V, the others to GND.

- Set a breakpoint in the DMA TC routine.

- Check the values of the channels.

- Swap the channel setup.

H.Darwish
Associate II

thanks for your help AvaTAr , but still not having solution 🙂

the result sampled from adc1 are loaded in correct order in the buffer ,

but the result from adc2 are not .

i dont know why , maybe some ovelapping , as i know the adc data of ADC1 and ADC2 are loaded in same register after a complete conversion , so i dont know what happen when the DMA load these value into variable array,and why only the data of ADC2 are not in sequence,

AvaTar
Lead

I don't know what Cube/HAL is doing here, and honestly, my trust is limited.

I suggest to check the initialization code, and compare the result (the ADC config register settings) with the expected values, reading the reference manual.

I used the ADC a lot (with SPL / register code), and never had such problems.