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

[H.Darwish]

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

[Tesla DeLorean]

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

[H.Darwish]

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

[Tesla DeLorean]

>>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?

[H.Darwish]

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

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

[Tesla DeLorean]

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."

[H.Darwish]

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]

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]

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]

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.

[Tesla DeLorean]

My recollection with the F1+SPL is that I configured DMA in 32-bit wide mode and read the ADC CDR (Common Data Register)

I'm afraid I can't analyze CubeMX/HAL code in an unpaid capacity.