[AVR-DA] ADC doesn't trigger on negative runt pulse?

[T3sl4co1l]

Currently working on an application using CCL to trigger ADC.  CCL is set as a flip-flop, ultimately to implement a trigger delay and holdoff scheme (much as an oscilloscope timebase would use).  So, with async trigger events coming in, the flip-flop can be reset for as little as 1 clock cycle.

This should be sufficient to trigger the ADC, however it seems it is not.

I have not reduced this to a minimum test case, but my scope plots all show the trigger failing after a runt pulse, approx. 1 cycle low then going high again.

The ADC has long since stopped by the time this event arrives (the flip-flop is being cleared in the RESRDY interrupt, the ADC has been waiting about 1µs by this time), it's not being swallowed by an ongoing conversion.

Fix seems to be disabling the flip-flop trigger source (a timer) during the interrupt, then enabling it after clearing the flip-flop (thus adding hold-off time to the hold-off time, forcing the event minimum off-time to several CLK_PER cycles).

Also, in case you were wondering, this occurs regardless of CCL synchronizers being enabled (for either of the trigger or reset events into it).

tl;dr: An almost-always-high event signal, with approx. 1 cycle low, appears not to start the ADC.

Tim

[MK14]

Also, in case you were wondering, this occurs regardless of CCL synchronizers being enabled (for either of the trigger or reset events into it).

I suspect others on this forum, would have far more specific experience, with that chip than me.  But anyway, it would be easier to help, if you stated the EXACT part number (e.g. for checking the ERRATA), and considered publishing some kind of extract (possibly only a few lines) or more, of the problematic source code.

Also, it is NOT clear, which flip-flop mode settings, you used.

Code: [Select]

0x0 DISABLE The sequencer is disabled
0x1 DFF D flip-flop
0x2 JK JK flip-flop
0x3 LATCH D latch
0x4 RS RS latch
https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/AVR64DA28-32-48-64-Data-Sheet-40002233B.pdf

At a rather quick glance at the PDF(s), it seems there is also a filter as well as a synchronizer.

Code: [Select]

0x0 DISABLE Filter disabled
0x1 SYNCH Synchronizer enabled
0x2 FILTER Filter enabled

an unwanted glitch may trigger unwanted events and peripheral action. In removing these
glitches by clocking through the filters, the user will only get the intended output. Each Look-up Table (LUT) in the
CCL includes a filter that can be used to synchronize or filter the LUT output.

https://ww1.microchip.com/downloads/en/Appnotes/TB3218-Getting-Started-with-CCL-DS90003218.pdf

There also seems to be an ERRATA for the CCL, for some versions of the chip.
https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/Errata/AVR64DA-28-32-48-64-SilConErrataClarif-DS80000903D.pdf

[T3sl4co1l]

Oh I left that off didn't I, tut tut.  AVR64DA64, but I have no reason to believe it's device specific; probably family.

Have device's errata open beside the datasheet; this isn't one of them.

CCL is RS (sequencer type 4), though there are other ways to do that (a single LUT can be configured as RS!), and still other ways to generate one-clock non-events, which are worth trying too.

Note that CCL filters don't affect input synchronicity, so cannot have the effect of filtering the output of the flip-flop.  The ADC does not have an event filter (anyway, the usual case is a single-clock active event, inactive the rest of the time, hence why that would be a bad idea), and only says it should trigger on rising edge.  So I strongly suspect I have a bug here.

Still haven't taken the time to build up the test tho.

Ed: oh nice, new rev errata since I last looked.  Couple obvious typos, slightly looser specs, with the higher min ADC Vref, and reduced Flash lifetime, being the most notable.

Tim

[MK14]

Note that CCL filters don't affect input synchronicity, so cannot have the effect of filtering the output of the flip-flop.

Well, when I look at the datasheet  (  https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/AVR64DA28-32-48-64-Data-Sheet-40002233B.pdf  ), on page 449, specifically Figure 29-5. Filter.

It appears to show a diagram, as part of the 'output' section (what will be the output), which consists of 4 individual flip-flops.  Which also appears to agree with another part of the text, which says, words to the effect that there will be a 2 or 4 cycle (clock related delay), depending on the specific Sync/Filter bit selections.

There is apparently a way of disabling that section, but I'm NOT clear how it behaves, under those circumstances.  But it does also specifically say "Forbidden state", in the table on page 451.  But without any specific details, such as the source code, I can't really tell, if that applies or not.  But, maybe it explains your issues. if it applies.

[T3sl4co1l]

Yeah, that's the optional filter in the CCL, go up a few pages to see where it's placed -- the chain goes LUT, optional filter, synchronizer or edge detector, sequencer.  And the sequencer is only common to the even (and even+1) LUT channel.  So, no filter after seq, nearly-overlapped edges can propagate through everything and still generate positive or negative runt pulses after the sequencer.

...I've noticed, in general, these documents to be fairly confusing; you have to read each section up and down, piecing together every little bit about it, until you eventually gather the whole picture.  You would hope that finding such a clear diagram as Fig. 29-5 is something to take in confidence; but in fact, it's merely an option, and section 29.3.1.5 doesn't say what its place is in the chain. 

The same is true across the document; I found TCA and TCD quite poorly organized as well.

USART, at least is mostly familiar.  ADC, is different, but doesn't have many options to screw up and is functionally straightforward.

Tim

[MK14]

Yeah, that's the optional filter in the CCL, go up a few pages to see where it's placed -- the chain goes LUT, optional filter, synchronizer or edge detector, sequencer.  And the sequencer is only common to the even (and even+1) LUT channel.  So, no filter after seq, nearly-overlapped edges can propagate through everything and still generate positive or negative runt pulses after the sequencer.

Yes, lots of ways and mechanisms, that could easily cause your issues with the (apparent lack of) reliable ADC triggering, in the OP described situations.  Things like meta-stability, or even that the edge detector gets out of whack, and causes issues.

Sometimes it is because the exact chip part used, is an older version (pre-latest bug fixed revisions).

But you can accidentally damage these chips or mis-program the code (bug), and sometimes cause apparently similar issues.

It could also be, the datasheet itself needs updating, which could then explain weak/unreliable/forbidden ways of programming those CCLs etc.  E.g. Maybe the RS latch, selected was NOT suitable for this situation, and it needed another flip-flop type, which gives more reliable asynchronous timings.

I.e. They seem to have put a lot of effort and at least some, silicon space, into giving it all those different mechanisms, such as synchronizes, filters, selectable flip-flop types, etc.  Presumably/possibly they have been supplied, because without their correct use, in the right circumstances.  Issues like you have been experiencing, can occur.

[T3sl4co1l]

Well...yeah... they're there because you can for instance bring in dirty completely asynchronous signals from timers, general port pins (via events), or direct LUT inputs (on applicable port pins)... there are many places you would want that feature.

Indeed I'm using that on this very same project, as part of a sigma-delta decimator which works very nicely; synchronization is required, else the count shifts by a bit position or so, +/-, due to temperature dependent delays in the external signal path.  A perfect example of using it.

But that's inapplicable here... the whole point is the race condition.  I measured it myself, I saw the waveform, it fails to trigger following an approx. 1-cycle-low pulse.  This is completely after all the sync and filter stuff, at the f/f output, at the LUT output, on the event routing that signal to -- in this case -- the ADC event input AND the port output.  Give or take internal propagation delays, I suppose, that's entirely the beginning and end of what the ADC is seeing.  It triggers on the rising edge after longer low-pulses, I saw pulses of several clocks in duration triggering normally.

It only fails on the narrowest pulse.  And it doesn't trigger at all on a "zero" pulse ("forbidden" state), I don't know why they don't say it's R or S dominant.  The result is simply no state change and it waits until the next trigger, functions as intended.

I don't get... what's your point here, look, I described the situation, the only thing left to do is test and confirm, or otherwise modify to get a minimal test case.  I read the datasheet, I did the measurement, I removed the race condition and it works reliably, you're just speculating on cause..?  I get wanting to be helpful, but the OP isn't really a question, it's information in need of confirmation.  Not trying to be rude here, but this is beyond the stage of pointing at the datasheet and hmming loudly, additional "hmm"s aren't being helpful.

I do appreciate the thread-bump though; perhaps someone with some free time and an AVR-DA will see this and give it a spin.

Tim

[MK14]

I'm sorry if my last post has upset you in some way.  As far as I know, it was NOT intentional.
Anyway, I guess it is best for me to leave this thread, for now, at least.