So, I’m going to be upfront and honest with you: that major software bug from the Christmas update still hasn’t been fixed.  Not for a lack of trying, mind you.  What I thought was the DMA controller not being triggered during a short interrupt actually turned out to be a hellish clock skew problem that stems from an incorrect assumption about the Xmega’s DFLL that I’d been making for over two years.

I’ve managed to force the assumption to be true by building a software routine that recalibrates the Xmega’s system clock on the fly based on integral error between it and the USB start-of-frame signals.  After receiving n USB signals, the routine ensures that the system has run for a total of 24000n ± k cycles, where k is a small constant (~150).

This has been tested for long periods of time, with instructions to halt if k ever became too large- yet the error still persists.  An error of about 0.004% from ideal, mind you, but that’s still enough to cause the board’s buffer to become corrupt after about 25 seconds.

I’m looking into solutions to this.  The easiest involves running a similar calibration routine on the DMA’s counter directly, in addition to the current one running on the system clock.  This would likely make the problem go away, but it doesn’t explain why it was there to begin with.  In theory, the steady state error should be zero, and this has been tearing me apart for days.  Perhaps it’s time to move on…

Either way, whether the problem gets solved in two hours or in two weeks, the whole of China will be closed from the 22nd until the 4th due to the Spring Festival.

*This means that the boards won’t ship until the end of February, or perhaps very early March.*

I’m truly sorry about that, especially after the last update made it seem like the hardware was ready to go.  As explained above, I just didn’t see this becoming such a large problem.

There are a couple of upsides, though:

• When building the calibration system, I found out that there’s a second oscillator and PLL on the Xmega.  The current code actually uses this second oscillator to generate the system clock.The reason why the scope runs at 750ksps is because its sample rate must be scaled down by a binary factor from the system clock, and the system’s clock source was the 48MHz USB oscillator.  With a separate oscillator, it should be possible to run the system clock at 32MHz or and scale that down by a factor of 32, meaning that the scope could run at 1Msps, with nothing more than a software update.  Of course,the current focus is simply to get it working at the nominal speed of 750ksps.
• Assuming there aren’t any issues with manufacturing and this bug can be killed quickly, there shouldn’t be any further delays with the hardware.
• By the time the boards rock up, there should be some Android software ready to go.  ;)

As always, if you have any complaints, comments or suggestions, you’re welcome to contact me by email at admin@espotek.com.

Have a fantastic 2017,

~Chris