RESET_MOCI not pulled down on poweroff

On our custom carrier-board (based on the Ixora design) we want to implement powerdown functionality. We have everything in place, the kernel is configured correctly, and we see the GPIO that is supposed to trigger the LTC2954 kill signal getting pulled down after shutdown completes. However, this signal is being blocked by the NC7SZ126M5X buffer because the output enable signal, which is connected to the Apalis RESET_MOCI# signal, stays high.

When the exact same module is inserted into an off-the-shelf Ixora board, the board does power down completely, and we see the RESET_MOCI# signal getting pulled down.

Now, one thing we changed is that we attached the SGTL5000 audio codec to the 3V3 supply, as indicated by the Apalis datasheet, since we do not need audio functionality. Since both this codec and the PFO100 voltage regulator (which produces the RESET_MOCI#) are both on the on-module i2c2 bus, is there any chance the i2c2 bus is getting hung up during shutdown, causing some final communication with the voltage regulator from getting corrupted?

For my understanding, in a normal situation, what triggers the RESET_MOCI# signal to become low? Is this the result of an explicit command to the PFO100, or is this a result of the PFO100 powering down or is it something else?

Also, I see in the PFUZE100 driver there is a “shutdown” function which does some last-minute register updates on the i2c bus. What happens here? If this shutdown fails because the I2C bus is hung up, could that explain the RESET_MOCI# signal staying high? There is dev_err logging included in that driver. Is there an easy way to see if this logging indicates any errros?

Thanks in advance,


Dear @jeroen94704,
thank you very much for the interest in the Toradex products and for using the Developer Community website.
It is actually a bit weird that the RESET_MOCI# does not get released.
I also guess it has to do with the system hanging somewhere but I doubt it is due to the Audio Codec: the implementation recommended in the datasheet should work fine.

I think that it makes sense to measure with the oscilloscope voltages and signals involved in this behavior, in order to exclude a race condition.

Could you please be so kind to measure the signals POWER_ENABLE_MOCI, RESET_MOCI#, 3.3V_SW (carrier board) and module 3.3V on your carrier board and on the Ixora?

It also makes sense to check for error messages in the debug output.

I would also be happy to have a look at your pdf schematics, to check if I see anything suspicious. Feel free to share them with me on my personal email

I really hope this helps, please don’t hesitate to contact us again if needed.