Very frustrating. I'm using AS7 and a jtagicemkII and debugWire to develop a 168 system. Try as I might I cannot get ADC interrupts. I'm getting timer interrupts so I know interrupts are working. I can go into I/O View and manually fire a conversion and see results that all look okay, even in interrupt flag. But the ADC ISR never gets hit. I have tried breakpoints and toggling a pin as a sanity check.

https://www.avrfreaks.net/comment... Post a complete test program that demonstrates the symptoms. Tell AVR model, and clock speed. Tell language, toolchain, version, and optimization settings. Tell what you expect to happen, and tell what >>is<< happening.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

With the wait loop in there >>with global interrupts turned off<<, it could explain your situation. 1) No need to turn off interrupts for SPI work; 2) The commented-out call is in the other ISR. Global interrupts are already disabled. Your fussing with cli/sei is enabling nested interrupts. But that call is commented out...

Also in that routine, I looked at /SS handling. If that reverts to slave from master, that would explain the failure with the SPI loop. But PB2 is an output...

So, examine all paths through the timer ISR to make sure it indeed completes always.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

FIXED!! The issue was timing. My timer routine is taking so long that as soon as it ends it gets another timer ISR. The ADC never had a chance to run. The next rev of the board will have a 20M crystal. that should fix it.

My timer routine is taking so long that as soon as it ends it gets another timer ISR.

I didn't dig through fully, so I don't know how often you are running the ISR.

Atmel app notes run a 3-phase motor sine generator at fairly modest clock rates. I don't know your app, but 2048 points sounds like way overkill. There is an awful lot of stuff in that ISR. If it were me, I'd try to streamline setting the next value with pre-calculated indices at least, and maybe even pre-fetched values.

But these are going to a DAC. The SPI service time is going to keep adding microseconds as well.

Within parameters, AVR8s have good throughput. I can't help thinking that an Xmega model with twin DAC channels and DMA would make child's play of that. Load up the DMA buffer(s) when parameter(s) change, then tell it to "go" and no further processor intervention.

I'm speculating that 20MHz will not be a cure-all.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.