MC9S12C - AD, restarting scan in continuous conversion mode

[robswan]

[Edit -- formatting lost when first posted]

I'm on the trail of a gremlin in an application. The problem is that an implausibly low value is read from ATDDR0 very occasionally (once in ~15e6 samples). The other channels look fine. There have been bandaids applied to hide the low values, but I'm not happy with that. I suspect the values might due to something wrong in how we're talking to the ADC.

The unit is configured in continuous conversion mode (ATDCTL5 = 0xb0), but in the RTI ISR (running every 128us) ADTCTL5 often gets 0xb0 rewritten to it, aborting the current conversion and immediately latching a new sample from channel 0.

I wonder if there might be an occasional problem with aborting/restarting the conversion cycle when it's already in scan mode. I'm thinking that if the ISR writes to ATDCTL5 at (say) just the moment that it has started a new cycle anyway, grabbing the analog value for channel 0, might lead to some sort of partial latching of the voltage which is then correctly converted to a low digital value.

One piece of evidence that it might be something like this is that I've temporarily disabled the section in the RTI ISR where ATDCTL5 is written to and the spurious values no longer occur. OTOH, I've read and reread the ATD section of the manual and can't see anything to suggest that there's anything wrong with what we were doing. And I've written small test programs trying to trigger misbehaviour -- they didn't.

I'd be very grateful if someone can tell me that there is a known problem, or that what we're doing is simply wrong, or that I must be from some other planet 'cause this works fine.

Have fun,

Rob.

[kef]

I wonder what is purpose of this "ADTCTL5 often gets 0xb0 rewritten to it, aborting the current conversion and immediately latching a new sample from channel 0.". I would understand if you were restarting conversion and waiting until complete, for example to make data sampled at equal intervals to do FFT or something. But what is purpose of restarting conversion and not waiting until conversion is complete? Also, if you restart ADT cycle sometimes in RTI interrupt, then what about doing it on each RTI interrupt?

CCFx bits description tells that data is available in corresponding ATDDRx when CCFx bit is set. Write to ATDCTL5 clears all CCFx bits .. and may make data not available in ATDDRx

[robswan]

Thanks for the reply.

My wording was confusing -- I meant that we want to latch the analog value right now for reading later.   As a consequence, because it is in continuous conversion mode it will be in the midst of a conversion, and whatever conversion it was in the midst of will be aborted.

That said, I think that it is strange usage.  FWIW, this code is in the MegaSquirt engine management controller.  The RTI wants to sample ATDDR0 at a particular section of the engine rotation cycle.  The RTI is used essentially to poll until that zone is reached, then the restart sequence comes into play.  Seems pointless to me because the full conversion cycle (@1.5MHz) is 96us -- finer granularity than the 128us period of the RTI.  For my testing I just removed the code that initiated the restart and the spurious values disappeared.  While, the first sample may now be a fraction before the sampling section is actually in play, the sampling window is a pretty fuzzy thing anyway.  On average the RTI will occur 64us into the sampling section and the value wating in ATDDR0 will be closer to the start of the window than we get now. 

The code is open to read, but it's up to the core developers whether to accept changes, and they don't seem receptive to the above reasoning.  So I was hoping for some sort of reference that might caution against what we're doing.  Is there any "official" caution along the lines of your last warning -- about reading an ATDDRx register if its CCFx flag isn't yet set?  I didn't spot anything in the datasheet, and one of my "try to make it fail reliably" test programs did try reading data registers at many intervals just after ATDCTL5 had been written to, with no dodgy values appearing.

Thanks again,

Rob.

[kef · Accepted solution]

•  The RTI is used essentially to poll until that zone is reached, then the restart sequence comes into play.

Above should cause no problems when

- data is read from ATDDR before the restart.

- sequence is restarted and no data is read from ATDDR until CCF is set

Datasheet doesn't mention what happens to old ATDDR values on restart of sequence, is data destroyed or not. I only see in datasheet that data is available in ATDDR when CCF is set.

[robswan]

Thanks kef, I think that's probably as close to an answer as I'm going to get.  The code certainly isn't checking the CCF, it just goes ahead and reads the ATDDR.  My test programs tried this and couldn't make it fail, but there's plenty more going on in the real application and that may trigger some interaction that where ATDDR ends up with an invalid value.

Thanks again,

Rob.