Nick Wright

I think your best course of action is probing the system to look for spikes or unexpected voltages. There are no obvious issues in the schematic, but I would focus on the high voltage portion around U3 and the switch. You may find unexpected behavior from things like the leakage current through the clamp diode in the ULN2081A on O5.

Some things seem odd in the design unless I misunderstand something: LED D1 is always off (has GND on both sides) The ULN2801A O5 is tied to GND There is no current limiting component for the U2 diode (unless the capacitive pushbutton switch limits current) However, I do not see anything that would damage the MCC 152 if the connections on J7 are made correctly to the 152. What is the pin mapping from J7 to the 152? If you are using the 1x10 header footprint on the 152, the pinout is:

@Donk Is GND1 a different ground than the other ground symbols in the schematic? is it at the same potential or separated?

Yes. We mainly need to check that the freewheeling diode output from the ULN2801 is connected back to the coil supply so you don't get large spikes when turning the coils off. You can also check the MCC 152 outputs with a scope while switching the solenoids to look for spikes.

It is likely that the IO interface chip has been damaged, most likely due to some form of over or under voltage spike similar to what was reported here. A system schematic would be helpful for further analysis to avoid future damage. Are you driving relays with the ULN2801

@Display Name The 152 should not interfere with other devices using the I2C bus on GPIO2/3 unless they happened to use the same I2C address as the 152. The I2C components on the 152 support up to 400 kHz, but we do not change the I2C speed from the default value in the library so it is likely running at 100 kHz. It is possible that the extra bus capacitance of having the 152s along with your devices is slowing the edges enough to have issues. Are you using any additional pull-up resistors on SDA / SCL? You could try capturing the I2C comms on a scope in both scenarios to see the difference, and adding additional pull-ups may improve the communications.

Yes, that is correct. For best accuracy read the CJC temperature reported by the USB-TC because it could be different from ambient.

I think the voltage reading function in mcculw only applies to the USB-TC-AI and not the USB-TC. I do not know of a way to get a voltage reading from the USB-TC directly. You may be able to get it in a roundabout fashion in this manner: Configure the USB-TC to a similar voltage range TC type such as J. Read the thermocouple temperature T1 and the appropriate CJC sensor temperature Tcjc Calculate the corresponding type J CJC voltage using the J thermocouple data (Vcjc) Calculate the thermocouple voltage using the J thermocouple data (V1) Calculate the raw thermocouple reading voltage Vraw = V1 - Vcjc You can then calculate the type C thermocouple temperature: Calculate the type C CJC voltage using Tcjc and the C thermocouple data (Vcjc2) Calculate the type C thermocouple voltage V2 = Vraw + Vcjc2 Calculate the thermocouple temperature T2 using V2 and the C thermocouple data

@Display Name could you also please capture an analog scope trace on one of the encoder signals to check for the voltage levels, spikes, etc?

The MCC 152 is different from the other MCC HATs in that it uses an I2C IO expander on the Pi I2C bus to implement the digital I/O. The other HATs all use SPI only. If the IO expander on a 152 gets damaged it can cause issues on the I2C bus, which would show up as problems communicating with other MCC 152s but not different models of HATs. The HAT detection is performed by reading the EEPROMs on a dedicated ID I2C bus (separate from the one used for the IO expanders) so a damaged board can still be detected but communications do not work. The most likely causes for damage to the IO expander are voltage related, due to things such as: Overvoltage on an IO pin (like connecting a 5V input signal when the MCC 152 is configured to 3.3V) Undervoltage on an IO pin (such as connecting signal and ground backwards)