Closed ryan-summers closed 4 years ago
Are you sure that IOs were properly initialized - they have special open drain configuration? What is the voltage on these pins? 0.00V or 0.05V? The only external device is Kasli and IC6. Do you use it with Kasli?
This occurred with powering Stabilizer via PoE and there were no other external connections (e.g. no Kasli at all) outside of a logic analyzer hooked up to the EEM header pins for I2C.
The I2C IO pins were configured in an open-drain configuration and set to be automatically managed by the I2C peripheral. The I2C peripheral indicated (via status registers) that it could not initiate a transaction because the bus was held.
Unfortunately due to the issue described in #74, I can no longer program the Stabilizer I have to measure the voltage on these pins until I get a new board or resolve the issues with this one.
didn't you kill these I2C pins by chance?
There are no TVS diodes, so such I2C can be killed by ESD
It is unlikely (although possible) - I didn't notice any ESD emissions when connecting the logic analyzer. As noted in the original post, the pins appeared to behave normally after a power-on reset (pulled high) and would only go low after the I2C peripheral took control of the pins.
if you connected pins first, then GND, you could kill them. I2C is very sensitive. Even 30V can kill them since they are open drain. What is the voltage when CPU is in reset state?
@ryan-summers what's the conclusion? Can I help somehow?
I added a TVS. It happened a few times that I2C was killed just by toucing the boards.
During firmware development, I've hit a snag where the I2C2 SDA and SCL pins appear to be continually pulled low on the bus, which prevents the CPU from initiating an I2C transaction.
Observations:
The end result of this is that the firmware will wait indefinitely on the I2C transaction because it believes the busy to be busy.