MCU measurement project

[ObviousInRetrospect]

I’m thinking about doing a calibration and data collection project against 10-50 samples for some subset of the following MCUs:

Avr32dd14
Attiny1614
Attiny3224
Avr64db32
Avr64dd32
Avr128db32
Attiny412

This will involve building a test board that has some programming sockets on it that connects some external reference hardware to the dut (device under test). Still in the brainstorm phase but since doing this is going to be a lot of manual work (putting chips in and out of the test sockets) I thought I would post the concept here and see what ideas others have for interesting measurements and importantly whether any of those ideas require additional hardware on the test board.

The current list of things I intend to measure are:
Serial#
Clock frequency error
Calibration step size
Best clkcal value
ADC reading of a precision voltage reference + a few divided down voltages against each internal reference
Test temperature via precision sensor
MCU temperature via internal measurement
(Temperatures are a control, the intent is to hold them as constant as I can without adding steps)

Things I am considering measuring are:
DAC output, unloaded
DAC output, loaded
BOD accuracy
VLM accuracy
Power consumption (over what workload?)
All of the above at 3.3v and 2.8v
All of the above across a wider range of voltages

This implies the following hardware on the test board:
Precision voltage reference
Divided voltage refeerence
GPS derived time reference
Temperature sensor
ADC if testing DAC accuracy
Control MCU + SD card
Either a pair of regulators with enable inputs or a more complex variable supply

I’ll store some subset of the data in the user row and/or EEPROM and full data in either JSON or CSV on a SD card. Going forward I intend to drop MCUs into this test rig before soldering them down to continue collecting data (and have calibration parameters).

Open questions:

1. does anyone have a working UPDI programmer sketch? The Adafruit one just gives me physical layer errors and I don't understand the protocol well enough to know what is going wrong. I'd rather have this be self-contained vs programming via a computer. Also testing multiple BOD levels would require automated fuse changes which would be far easier from the control MCU.
2. The decoupling is going to be sub-standard because of the test socket. How much will that affect the validity of the testing? I suppose I could solder more caps to the socket's PCB, is doing so worthwhile? I usually try to keep the cap within a couple MM of the supply pin, i'm always surprised when I see TH caps across the pins of a breakout.
3. Does the dac at 3FF output its reference or 1023/1024? Pros/cons on measuring the DAC output vs known input tests using the references?
4. What else should I collect? I’d rather not do this more than once
5. Any other references that I should include?
6. Should I bother supporting voltages above 3.3v (parts of the board won’t tolerate >3.3)
7. How interesting are measurements with varied VDD? I expect the clock calibrations to be the slowest to run and therefore most expensive to repeat. I am most interested in 3.3v and 2.8v but could include other voltages. I’m trying to decide whether the power circuitry is a 2.8 regulator, a 3.3 regulator, and a pair of fets or a dac output buffered through an op-amp. I’m torn on whether to bother going to high enough voltages to test the 4v reference and/or all the way up to 5.5v. The only thing I've built in the past few years that ran the MCU above 3.3v was a case where I wanted to run straight off a LIPO. Since I was planning on powering this off USB I’d either need a boost converter or maybe just a lipo connected to +3.3v and +6.6-7.5v to avoid switching noise.
8. Clock frequency could be measured most accurately against a GPS reference (1-second) but that is slow if it needs to be repeated. Is it worth using a 32k-4khz reference signal calibrated against a gps signal instead (and record the current ppm of the error during the test)?
9. Thoughts on pros/cons of self-clock measurement vs CLKO and external measurement?
10. How interesting is BOD accuracy? My best idea on how to test it is to use a DAC output off another MCU passed through a unity gain op-amp for VTarget (or higher gain as appropriate)
11. Thoughts on the MCU list? I am actively trying to determine whether the DD vrerfs are well behaved since their specs suck and understand why I keep hitting broken serial without tuning on attiny-1 and -2.
12. The tiny412 is “special” .Assuming 2 pins for i2c to send data to the control MCU and a pin for a clock reference I suppose that leaves the DAC output and one analog voltage to measure unless I get fancy and stick an external analog mux on the board (suggestions? I usually use analog muxes for digital data and have never thought hard about their milliivolt accuracy with DC signals).
13. Thoughts of pros/cons on using an ina226 as an ADC vs an ads1115 vs something else? This is primarily to measure the dac.

[SpenceKonde]

See the code I posted in your other thread - it's almost there for some (but not all) of the things on your list.

One of the key points for processing is output one chip per line, with a comma and no space between each datapoint. Copy paste it it of HTerm, regex away the CRLF sequences, save as CSV, open in excel and graph to your hearts discontent.
VDD has little impact on anything other than pin drive strength. Especially on Dx-series. On Dx-series, there's a slight change around2 v when it switches from the VCore regulator to direct. But otherwise, when I was testing autotune, I would ramp voltage between 2.5 and 5.5v and the autotune came out the same. Wasn't till I hit it with freeze spray or a blow torch (gently, and after letting the freeze spray vapor dissipate - it's not nonflamable, despite claims to the contrary, and one of the combustion products is the florine homolog of the wargas phosgene) that I saw any difference. The tinys are nearly as good, VDD has a very small effect on clock speed on tinyAVRs, but virtually none on AVR Dx

I have basically been stunned by how good the internal oscillators are on the new parts. Virtually no voltage depenmdance and very little temperature dependance

[SpenceKonde]

Oh, and I'm going to be producing a standalone programmer. Gonna use W25 flash IC's to store data, so you can have more sketches than yuou can shake a stick an on it,

If I went balls to the wall, could have screw the math i keep getting different answers but way the hell more than you need,

[ObviousInRetrospect]

Do you have a working UPDI library or sketch for avr or esp? I tried Adafruit AvrProg and got nothing but physical layer errors. It looks like UPDI is now documented at least. (when I couldn't get UPDI to work I wrote an optiboot library, I'd prefer UPDI).

[ObviousInRetrospect]

if you are mounting multiple W25's I'd almost think about a microSD slot instead. Might be more convenient for getting them onto the device.

[SpenceKonde]

If microsd cards weren't the least reliable electronic device I had used, yeah they'd be an obvious choice. But they crap out if you look at them cross-eyed. I had one in my phone literally die in the middle of playing a song from it - like, the music just stopped - and last time we worked on my raspi for my old room automation project we found that the sd card had failed, replaced it with a new one, trashed that one and had to grab another one (and we were working under the gun, cause see, I needed to go to bed, but the lights were on, but it was too late to drag furniture around to reach outlets to unplug everything, and we couldn;t turn off the breaker because my minifridge had an iceberg in in that would damage the floor, but moving it would disturb the downstairs neighbors....) So yeah I kinda hate micro SD cards. They crap out for no good reason all the damned time. LadyAda claims hers works, somewhere there was a thread where she tagged me and asked how I made pymcuprog-based code upload fast, and we discussed it, and she reported success. I was uninterested in using her code because I needed something that ran on an AVR, so I didn't investigate further.

My plan for getting files into HyperUPDI (which would use a new, very basic, serial protocol to obliterate the usb latency problem, you know, there'd by a HyperUPDI.py)) was that you'd upload to it and it would pretend that you were programming a device not a flash chip.

[gordonthree]

The jtag2updi sketch under File -> Examples "works for me" using a clone Nano with a Mega328p on board. That nano lives on a breadboard and is my backup plan if I get frustrated with pymcuprog / serialupdi.

Check out the NAU7802 ADC... it's not very fast but it has a lot of features and comes in very hand-solder friendly SO14 package, or even DIP for that old school vibe, plus it is SUPER cheap.

[SpenceKonde]

jtag2updi is incredibly unpleasant to work with. It was written, IMHO to demonstrate that the author was better at C++ than the rest of us. (speaking as the guy who hacked 24-bit addressing support required for Dx-series onto it). Check my repo for it though - I froze it and declared that I will do no more work on it because of how awful it was

That thing needs to be burned to the ground, bulldozed over, and completely rebuilt on a new foundation. Everything was done the Wrong Way there, right from the first decision of using jtag as the base protocol.

[ObviousInRetrospect]

interesting. I thought the NAU7802 was largely designed for use with strain gauges. Any particular warts as a general purpose ADC? What is with that 1024 point calibration?

[ObviousInRetrospect]

hmm do you have another working UPDI implementation and if not is the code in jtag2updi worth stealing or is it sufficiently bad as to be worse than an empty file?

[gordonthree]

interesting. I thought the NAU7802 was largely designed for use with strain gauges. Any particular warts as a general purpose ADC? What is with that 1024 point calibration?

I just picked it mainly due to price, package, having 2-channels and supporting single ended mode. I noticed it does have a bunch of different calibration routines, I'm planning on only using the internal one. I have the Vin- for both channels grounded, and feeding the output of my current transducers into the Vin+ pins.