Hello again.
In last months I received two more PicoCOMA9X modules with this problematic behaviour and here are my observations and findings.
It seems to be the same problem as before, but it manifests itself a little differently - immediately after startup (already in U-Boot) the signal of the internal I2C3 bus SDA is held in 0.
The result is that neither the RTC nor the audio in linux work (audio - via the sgtl5000 driver - is connected to the same I2C bus).
The situation appears after resets typically performed by mechanical disconnecting and connecting the power supply - hence there appears some kind of trembling or oscillations on the supply voltage. I tested whether the behavior changes if the battery for the RTC is connected or not - but there was not difference.
I also checked the /RESET input signal on the oscilloscope and it seems to be correct.
I managed to find a workaround for this situation - in U-Boot it is necessary to generate artificial pulses on I2C3 SCL (in U-Boot this is just GPIO) and by this the bus can be "unblocked" and both RTC and audio are then working in Linux.
Apparently when disconnecting and connecting the power supply, some participant on the I2C3 bus does not perform a correct reset and remains somewhere "in the middle" of the transmission. It gets out of this with help of artificially generated clock pulses.
If this only happenes when the RTC battery is connected, it could be the caused by RTC circuit, which could interpret some disturbing pulses (generated during the power off/on) as an I2C communication. However, the problematic behavior could be seen even without the RTC battery connected.
Currently - with the workaround in U-Boot - the I2C3 bus does not stop working in Linux anymore (at least on the two PicoCOMA9 modules mentioned above).
However, the workaround is done more or less blindly - it tries to generate enough SCL pulses to bring SDA back to 1.
It is questionable whether this will work under all circumstances. Therefore I would like you to check the PicoCOMA9X module behaviour - wheather reset of I2C3 participants is performed correctly in such situations.
Thank you,
Kamil