SAM4L ADCIFE window mode using PDCA

Discussion around product based on ARM Cortex M4 core.

Moderators: nferre, ncollot

bptech
Posts: 25
Joined: Fri Jul 18, 2014 3:08 pm

SAM4L ADCIFE window mode using PDCA

Tue Nov 18, 2014 5:45 pm

The SAM4L ADC seems to have a feature that I cannot get working. Maybe it does not really have the feature I need, or maybe I have failed to understand it, but if anyone has been able to use it I could use a little direction.

The issue is with multichannel ADC conversions in Window mode. The Window mode generates an interrupt when the converted channel goes out of a specified range, either higher, lower, inside a window or outside. This would seem to be perfect to monitor a battery voltage, for example (as long as you don't need a lot of accuracy, as in battery present vs battery absent). No processor time required at all unless the battery is removed, then you get an interrupt. It can be done even when the processor is asleep, called sleepwalking.

So far so good, and there are example programs that do exactly that, ADCIFE WM EXAMPLE.

My issue is that I have five channels I need to monitor. There is an example ADCIFE EXAMPLE that seems to show that working, using PDCA dma transfers, except that the results go in the wrong memory locations. At any rate, that does work, but requires too many processor cycles as you need an interrupt for every conversion cycle.

In the data sheet there are additional configuration words that can be added to the PDCA to invoke the Window mode. So I added these to the ADCIFE example and created a callback for the Window mode interrupts, just like the one in the ADCIFE WM example. The interrupts are triggered, but seemingly at random with no corresponding change in input. A change in one channel triggers an interrupt for a different channel. The result buffer has one channel's result in several locations.

I tried a all the triggering methods, none make a difference except I get lots more bad results faster in the continuous trigger mode. In the software trigger mode I get no results at all. With the itimer the results occur at the correct timing but are not correct. In the configuration word for the PDCA adc_first_config there is an unexplained bit called strig, I hoped that would trigger the conversion at the right time so it does not get overrun by the next dma transfer, but this bit seems to have no effect in any trigger mode.

It really seems like the ADC conversion and window comparisons are happening at the same time that the multiplexer and configurations are changing, resulting in a scrambled output. I can't just hang a scope probe on it as it is happening in hardware inside the chip, but I put a bunch of diagnostic pulses in that show when the window interrupts are happening in relation to the PDCA reload callback. The window interrupt happens right before the callback, not one conversion time after it. So instead of "set up conversion with PDCA TX transfer, convert, wait for timer trigger for next setup" as implied by figure 38-2 of the data sheet, it does "setup up conversion with PDCA, wait for timer to trigger, setup next conversion and try to do current conversion at the same time, output whacky result, repeat".

This system would be great if it would work, there would be just a reload interrupt every 5 conversion cycles that could be safely deferred if the system is busy and no other interrupts unless a condition has occurred that needs attention by the system.

Has anybody actually tried this?
bptech
Posts: 25
Joined: Fri Jul 18, 2014 3:08 pm

Re: SAM4L ADCIFE window mode using PDCA

Wed Nov 19, 2014 2:16 am

Update: the PDCA is not triggering the ADC correctly. It takes two words of transmitted data to set up the converter, but both words trigger the ADC and result in a value in the result buffer. One word is the setup word, the next is the Window mode limits and mode. So I guess I get one conversion with the last channel's Window mode setup, then another conversion with the correct Window mode setup.

I put in a diagnostic save of the PDCA TCR values (breaking the program does no good, the PDCA just runs on even when the CPU is stopped so you cannot just break and look at values). This was placed right before the reload that starts a new round of readings. The Rx PDCA TCR is zero, as it has to be for the callback to trigger, but the Tx buffer has only used half of its data. The Tx buffer always has twice the data because two words are required to set up one reading. But it is supposed to use both words, so both buffers should be zero when the reload happens. Instead, it is initiating a conversion on every word.

I am going to try ignoring all the odd conversions, sending every setup twice. This is going to give me a lot of spurious interrupts, and I am not sure how to sift out the good from the bad, also I will have to quadruple the size of the receive buffer so all the conversions actually occur. It is starting to look smarter to give up on window mode and just do a bunch of comparisons after each round of conversions.

This really looks like a hardware errata now that I see that half of the setup words are being ignored.
bptech
Posts: 25
Joined: Fri Jul 18, 2014 3:08 pm

Re: SAM4L ADCIFE window mode using PDCA

Wed Nov 19, 2014 7:51 pm

Update 2, definitely a hardware issue, abandoning PDCA with Windows mode, it Just Doesn't Work.

I set up the PDCA settings so each TX word has a corresponding RX read. 2 TX transfers per setup, and two RX reads as well. Now I get a wrong result value on the first read but the right value on the second read. But the WM interrupts are not disabled on the first read, so I get spurious interrupts and there is no way to filter them out. Useless.

Return to “SAM4 Cortex-M4 MCU”

Who is online

Users browsing this forum: No registered users and 2 guests