Hi
I observe a sudden shift of channels in my ADC-scans. It occurs very seldom - typically once every few days. Suddenly, the DMA-buffer fills with ch1..ch7,ch0 instead with ch0...ch7 and from then on, this mode sticks! Has anyone observed this before and what was the cause of the trouble in your case? Thanks for help.

My board is based on a AT91SAM7X (OS is eCOS). I have configured TC2 to produce a TIOA2-Pulse every ms. The ADC is configured to scan all 8 channels and to be triggered by TIOA2. It stores results to memory using its Peripheral DMA Controller (PDC). An RxBUF-Interrupt finally calls a routine that gets the results from the memory buffer. This works for hours, even days and suddenly - see above.
Roe

Hi Roe,

I am experience the similar behavior. That is what brought me over here....

WHAT I HAVE DISCOVERED, IS THAT THE PDC will perform X DMA's, so in this example below, it rotated back to the 1st ADC channel and started over to complete the count of 8. So it is going round robin thru this censored. Maybe your code has a glitch where sometimes the count you provide it is not the correct count ??????

I am able to get it to occur very regularly. To make it happen, I did following:
UINT16 adc_array[8];

ADC_PTCR = 0x0201; // xfer Control, disabe dma xfer, enable dma recv.
ADC_RPR = (UINT32) adc_array;
ADC_RNPR = (UINT32) adc_array;
ADC_RCR = 0x8;
ADC_RNCR = 0x8 !!!! THIS IS THE PROBLEM, I ONLY HAVE 7 CHANNELS !!!!!!

// Note: Usually channel 0 never has a conversion of less than 0x200, if it does, breakpoint
while ( 1 )
{

if (adc_array[0] < 0x200)
{
break point here and now compare this value with the hardware registers, you will see they are shifted.
}
ADC_RNCR = 0x8

}

Hi Roe,

Check out example code at : http://www.at91.com/Project/Controleurs ... sation=315 NOTE: password is adc.

I have 7 A/D's connected. Here is THE CORRECT code:


*********************************************************************
volatile UINT16 adc_array[80];

#define ADC_PDC_COUNT 7 // If you set this to 70, then 10 sets of 7 ADC will be performed.
ADC_PTCR = 0x0201; // xfer Control, disabe dma xfer, enable dma recv.
ADC_RPR = (UINT32) adc_array;
ADC_RCR = ADC_PDC_COUNT;

while ( 1 )
{
if (ADC_RCR == 0)
{
for (i=0; i<ADC_PDC_COUNT; i=i+7)
{
if (adc_array[i] < 0x200)
{
i=i; // never hit this breakpoint
}
}
ADC_RPR = (UINT32) adc_array;
ADC_RCR = ADC_PDC_COUNT;
}
}

Hi JamesM
I am not so sure I understand your code.
In the post of yesterday 16:16, you assign both PDC-counter a value of 8 and write: This is the problem, I only have 7 channels. Problem? You created a buffer of 8 and the adc of the SAM7 has 8 channels. If you only use 7 of them that's ok. So were is the problem?

In your later post you have the breakpoint at the statement i = i and write - it never hits this breakpoint. My suspicion: The compiler optimized this statement away and because there is no statement, the breakpoint is possibly nonexistent?

Did you find out more in the meantime on this issue? I did not. I have built in a dirty fix. Actually, one of "my" signals is always close to full-scale. Now I check each scan if this value is in its proper place or one later and if so, I trash the values and completely reinitialize the adc. I have not seen the problem again since then. My suspicion: Its a processor-internal noise-margin problem (retriggering of the scan by a noise peak while it is already under way). I just do not know.
Robert

Hi
it's quite some time ago this topic got an answer. However, the issue is yet unresolved.
I have included an output statement in the above described "shift-check" and I can see, that this channel-shift occurs once every few days. Hence, the event happens rarely, but it happens..... Still no news around about the reason for this effect?
Regards Robert

hi,
have you a speed problem ? if it takes about 1 ms to acquire 8 channels and you start conversion every 1 ms, you can have a new start of conversion before the end of previous set !!
Is it a good idea ?

[quote="GeorgesB3"]if it takes about 1 ms to acquire 8 channels[/quote]

No, the ADC is much faster. My ADC-clock is 1 MHz, hence conversion time is 10 us. Add the 13 us which I specified for the sample hold time (SHTIM). This results in a total of 23 us per channel or 184 us for 8 channels. Still far away from the 1 ms (TC2-based) periodic trigger I am using.

Completion of a 8-channel scan triggers an interrupt where I read the data from the memory. Ok, my ISR does a few more things and hence is a bit lengthy, but this does not explain this shift. Assume I still fiddle around in the ISR, reading adc data from memory and a new transfer is already started. I then would expect garbage data, but not clean shifted data. And do not forget: Once this shift happend, it persists. Its not self healing.....
Any other ideas?
Regards Roe