How to avoid a boot loop when a Cube Orange gpio has the ability to terminate system power

Hello, I am using a cube orange in a system which is intended to land far away and ‘camp’ in low power mode for a long time. The cube has control of a solid state relay which cuts power on active high command from FMU Channel 2 (could be any channel I guess). All I thought I would have to do is map (in this case) FMU channel 2 as GPIO to a button on my controller, and it will boot with all GPIO in a low state, and they cannot go high until the button is pressed.

This works fine on the pixhawk1 autopilot.

But on Cube Orange the FMU CH2 never goes low, ever, even without me pressing the button. It boots high and stays high. It’s mapped as a GPIO to the same button on the controller. So it stays in a boot loop.

I added a little buffer that uses the n_5V_peripheral_enable signal. Now the boot loop waits until the n_5V_peripheral_enable signal, which extends the boot loop to 5 seconds.

Edit 1: My problem is visible in this scope shot. Yellow is FMU CH2 output, Red is the signal I was planning to use as a sort of ‘enable’, the nVDD_PERIPH_5V_ENABLE signal.

The GPIO’s are high on reset, probably due to the buffer circuit in the cube orange. Having a buffer that disables the GPIO action until Ardupilot is in control of the GPIO state should work, but it requires my enable signal to assert after the GPIO’s are under ardupilot control (yellow GPIO FMU_CH2 needs to drop before red nVDD_PERIPH_5V_ENABLE signal). Is there a way to set nVDD_PERIPH_5V_ENABLE low later on in the boot process after the GPIO’s have been set to the desired operational state? Or is there a different pin I could use as my “GPIO’s are ready now” signal?

Hi Nick, did you get it resolved?