Voltages set with 30 V calibrator (Advantest R6144) and read out in parallel with Keithley 2001 multimeter.

On both ports the measured voltages swing by +- 2 LSB. The median is within 0.02% of the voltage measured with the multimeter.

Matches the spec of the INA233, much better than what is required for Glasgow.

I coupled hi freq noise into the Vsense pins. While on most frequencies no aliasing was measurable, on some frequencies (e.g. 370 kHz, 680 kHz) I could measure aliasing up to 50 mV with my (very improvised) setup. Will have to improve my test setup to better quantify the results.

Today I improved my noise injection setup. I used this coupling network, derived from similar setups used for various EMI measurements:

The noise was a triangle signal, tuned with the oscilloscope to result in 200 mVpp noise on the output, overlayed over the reference voltage that was set with my calibrator. The LC network shields the noise from the calibrator to not affect it's feedback loop. A 200 mVpp ripple/noise figure is a realistic value for an unfiltered switching PSU. A triangle noise shape is also very common for switcher ripple.

With most frequencies the noise was completely filtered by the INA233. But with some select frequencies the results were significantly affected:

I tested the frequencies by letting the freq generator sweep in 1 kHz steps up while watching the results that were read out in a loop. So I could have missed some peaks. Unfortunately I don't have the software tooling ready to create a proper graph with smaller steps.

These frequencies are something that can very well be created by a common switching PSU. Even PSUs switching at a much lower frequency will create harmonics that easily go in these regions.

Increasing the built-in averaging in the INA233 only partially helped, 0.026 V std. dev and 0.050 V max at 1.014 MHz with 64 averages.

I tested several RC combinations with R and C values that are already on the Glasgow BOM. Unfortunately 100 nF doesn't work as they usually aren't specced to the 40 V we need in 0402. Even if they were, the capacitance would be gone at that voltage. Also 2k2 as resistor is too high, the INA233 begins to read low by about 1% with this, even without noise.

A RC filter with 470 Ohms and 1 nF gives good results though:
0.016 V std. dev. and 0.026 V max dev at 1.014 MHz with just 4 averages. I couldn't see any noise at all the other frequencies listed above.

1 nF is available in 0402 as C0G up to 50 V.

So the question is: do we want to increase the BOM by 2 parts for making the ADC immune to noise at specific frequencies?

Idle current:

The idle current varied by 0.2 mA from the theoretical value given by the load resistors (2 resistors of 2k2 in parallel). For example I measured 4.5 mA at 4.78 V instead of the expected 4.3 mA. Or 2.4 mA measured at 2.55 V instead of the expected 2.3 mA. The difference percentage was constant across the set voltages, so it could be caused by load resistor values being out a bit.

Another reason could be idle current draw by devices connected to the Vio rail, e.g. the level shifters or the IO-expanders for the pull resistors.

Calibrating out this offset requires knowing the Vio voltage and the measured load resistor value. Using the set Vio voltage (instead of the measured actual voltage) should be enough for the precision expectations of Glasgow. This is realistic to be done in firmware.

Current measurement accuracy:

I used a electronic load set to CC mode in series to my Keithley 2001 multimeter. I dialed in the currents on the e-load and compared the measurement on the multimeter with the values read out from Glasgow.

The idle voltage of Glasgow was measured first with disconnected load and subtracted from the following measurements.

I measured currents in 50 mA steps from 50 mA to 400 mA. The measured values were higher by between 1.3% and 1.5% than the values expected by ideal shunt resistors with 0.15 Ohms. This difference was constant between both ports. It could be both shunts being out a bit.

This difference could be calibrated out by firmware.

With calibration the measured error would be 0.1%, which is totally acceptable for Glasgow.

Aliasing/Filtering of current measurements:

I connected a 47 Ohm base load resistor between Vio and GND. In parallel I connected a 470 Ohm pulse resistor in series with a N-MOSFET. The gate connected to my function generator. I set Vio to 3.3 V, yielding in about 70 mA with just the base load and 77 mA with the FET conducting.

I swept the frequency of the function gen in 1 kHz steps between 400 and 600 kHz and 900 and 1100 kHz, as these are the ranges the ADC is most sensitive to noise in.

I could not find any frequency that caused the measurement results to produce aliasing. So the implemented filtering seems to be adequate.

Overcurrent with capacitor:

Tested with Vio = 3.3V, 100 µF polymer capacitor (ESR in the 0.01 Ohms region)

When first activating the Vio, then connecting the capacitor, a current limit of 130 mA was enough to not trigger.
When first connecting the capacitor, then activating the Vio, it needs a 300 mA limit to reliably not trigger.

This means the current in the first scenario is such a fast spike that the filtering and ADC timing doesn't let it register the current well.

100 µF polymer is quite a lot for something that is not expected to draw more than about 300 mA total, so this testing the limits. If cap charging leads to too many false OCP triggers, we could add a firmware option to slowly step up the Vio. This would also prevent shorts or bigger caps on the output from resetting Glasgow.

When testing with Vio set to 5V and then connecting the 100 µF I experienced some resets of Glasgow due to the 5 V rail dropping down too much. This isn't unexpected when comparing the 150 µF bulk cap on Glasgow with the 100 µF load cap. So a slow start option would be good.

I tested the overcurrent protection reaction speed:

Current limit set to 50 mA, ADC speed to max. (140 µs interleaved, 280 µs current sampling speed).
The results varied a lot, so the following is the slowest reaction from 20 tries:

Current drawn 70 mA (3.3V, 47 Ohm):

Current drawn 330 mA (3.3V, 10 Ohm):

Yellow is Vio, magenta the gate of the FET that switches the current.

Since the worst time is just a bit above two sample times (560 µs), this means that unless there is a dead short on the rail, at least two samples are needed before the OCP triggers. If the drawn current is just a bit over the programmed limit, it takes about 5 samples. This indicates that the filtering is the reason for this.

In the 330 mA case I would have preferred a faster reaction time, since for example the integrated protection diodes of a DUT with the power pins reversed could already be damaged by then.

Further experimentation showed that most likely the datasheet of the INA233 isn't detailed enough regarding when/how the limits are compared:

Figure 23 reads "Current Limit Detect Following Every Shunt Voltage Conversion". I understood this as that the actually read last is compared to the limit. This is most likely wrong.

The above measurements were taken with averaging set to 4. Once I switched down to 1 number of averages, the reaction times improved to a bit more than 280 µs. Since 4 averages would take 1120 µs, what most likely happens is that the INA233 calculates a moving average and that is compared against the limit value.

So for a fast reaction, any averaging in the INA233 itself has to be switched off. For less noise the firmware in the FX2 could take care of averaging.

Vsense overvoltage test:

INA233 equipped with the filter from #221 (comment)
(a sample IC on a protoboard, no Glasgows were endangered in this test)

3v3 supply applied, Vbus voltage slowly increased, current into Vbus measured

• until 42 V: nothing happens
• at 42 V: current begins to increase slowly, most probably the TVS that begins to conduct
• 56 V: about 50 mA flows through the TVS
• 60 V: the TVS fails short

Desoldered the TVS, inspected the INA233:

• No increased supply current drawn
• No reduced impedance on Vbus (the voltage measurement pin)
• I2C comms works
• Voltage sense accuracy not reduced

-> protection circuitry performs as planned

SMBus Alert Response Address:

I changed the i2c address of the port A dac with a bodge wire, just like I plan to change it for revC3.

Accessing the DAC on port A, port B and ports AB simultaneously worked (i2c address changed in firmware of course).
Also querying the Alert Response Address cleared the ~ALERT line of the INA233s as planned.

So there are no negative consequences to be expected when changing the dac address in revC3 and the wanted outcome of being able to query the ARA is achieved.

But after being more familiar with the state mechanisms and requirements of the firmware, I think the current solution of using a state cache and reset for the INA233 is the better solution than using the ARA, at least until we get muxed i2c busses as planned for revD and maybe later revC.

Consider the following case:

• There is an alert on port B
• The INA233 of port B pulls low it's ~ALERT line, thus disabling the voltage regulator on port B through the diode logic
• The firmware sees the alert and begins to handle it
• The INA233s on both ports are queried for alerts, it is found out that port B triggered the alert
• Firmware switches off the enable line for Vio B, so the diode logic isn't required anymore to keep Vio B off
• There is now an alert on port A too
• The INA233 of port A pulls low it's ~ALERT line, thus disabling the voltage regulator on port A through the diode logic
• Firmware continues to handle the previous alert on port B. The next thing to do would be to disable the ~ALERT line for port B
• The Alert Response Protocol is not directed at a special device. If multiple devices have an alert situation, the device with the lowest i2c address will win the request and thus disable their ~ALERT line. The other devices with alert situations will respond to subsequent Alert Response queries.
• The INA233 with the lowest i2c address is the one on port A. When it disables it's ~ALERT line, the voltage regulator on port A will now be re-enabled, because firmware hasn't gotten around to disable it's enable line yet

The cache and reset logic used now is better in that regard, because it only affects the one INA233 that is addressed through it's i2c address. So there is no risk of accidently reenabling a already disabled Vio.

I still think it makes sense to fix the i2c address clash for revC3, but keep the cache & reset logic from revC2 firmware.