Reset behavior not per Apalis Design guide

When the TK1 SOM is reset by asserting RESET_MICO# or invoking software restart in the Ubuntu GUI, the SOM de-asserts the POWER_ENABLE_MOCI signal. Consequently, the system power shuts down since the POWER_ENABLE_MOCI signal falling edge signifies commanded power shut-off in our design. This is contrary to the Apalis Carrier Design Guide V1.5, Figure 59, where POWER_ENABLE_MOCI is shown to stay steadily high through the SOM reset sequence. The system is properly designed to mask the POWER_ENABLE_MOCI at power ON for enough time to allow the SOM to assert the signal, so power-up is not an issue. Is this a software/version thing, or does the power manager on the SOM module drive the POWER_ENABLE_MOCI signal with hard logic?

An amendment to this: Just noticed that there is a sneaky little comment in the paragraph above fig 59: “Some Apalis modules may implement a power cycle during reset”. This needs to be in BOLD text and reference to where one can find out which modules behave this way. For modules where this
is the case, the specific timing parameters of the reset cycle initiation should be detailed and fig 59 amended to indicate that possibility. In the case of the TK1, the module appears to consistently de-assert POWER_ENABLE_MOCI around 15msec following RESET_MICO# assertion.

I fully understand your frustration. It is indeed not very well documented. Unfortunately, we cannot change the behavior. The RESET_MICO# signals goes into the XRES_IN input of the PMIC (AS3722). This reset input is doing a full power cycle, not only resets the module. This makes sure that all voltages are in the correct state for booting up the module. Without doing a such cycle, it could be that the SoC was in a sleep state and had disabled some rails when the reset button was pressed. The POWER_ENABLE_MOCI signal is driven directly from the PMIC. It is a representation of the on-module 3.3V rail.

OK, since we can’t get around this, you need to clearly specify the timing parameters. For instance, I can see on scope that the POWER_ENABLE_MOCI de-asserts around 15msec pretty consistently after the RESET_MICO# assertion, and stays low for around 60msec irrespective of the reset input state. Please provide max-min times for these. Also, can IOs of the SOM remain driven (pullups, default states, etc.) to valid logic high level during the 60msec OFF window?

The POWER_ENABLE_MOCI is enabled together with the on-module 3.3V rail. This rail is switched by the GPIO2 of the PMIC. In the power up sequence of the PMIC, the GPIO is fused to be in slot 7 while the slot interval is set to 4ms. This means the POWER_ENABLE_MOCI is released 28ms after the power up sequence has started.

The XRES_IN of the PMIC starts a power down cycle. The timing of this power down cycle is set by the OS. The 15ms delay you are measuring are coming from this power down cycle. After the module is powered down, there is a off_delay setting in the register. This setting can be set by the OS between 0 and maximum 32ms. Unfortunately, I am an hardware engineer and cannot tell you to which value the power down sequence and off_delay are set. But the maximum for the off_delay is 32ms and the power on sequence is fused and therefore fixed to 28ms.

The power cycle not only disables the POWER_ENABLE_MOCI signal, it also disables the 3.3V rail for the IO blocks. Therefore, the IOs cannot remain their states during this cycle. After the IO rail is back, the GPIOs are set to their default reset state (for most of them this is input with an enabled up or down resistor. The first time the pins can be controlled is in Uboot.

Sounds like the 60msec width I observed is the summation of the maximum 32msec programmed OFF-delay, plus the 28msec power-on sequence delay.

So not only do we have to deal with the module briefly shutting system power down on reset, since the 3.3V IO power on the SOM also goes down, I have to ensure that any off-SOM logic also stops driving IOs on the SOM, correct? Luckily, we don’t use many ports of the SOM; please confirm the ports in the following list that need to be disconnected or powered down during reset:
ETH1_MDION/P {7:0}
ETH1_ACT (LED pullup)
ETH1_LINK (LED pullup)
UART1 through UART4 all inputs
I2C1 thorough I2C3
USB01 D/SS and all inputs

This issue came to light recently due to a proposed design change to our carrier to simplify power control. The design uses an integrated pushbutton controller that has a power-kill input. Initially, a companion microcontroller that watched POWER_ENABLE_MOCI would assert the power-kill. The coding for that has just started, but is being regarded as an unnecessary software complexity with negative regulatory impact. The simple solution is to drive the power-kill signal with POWER_ENABLE_MOCI directly. Unfortunately, power-kill is latching so the system fully shuts off on reset, requiring user action to turn the power back ON. This was unexpected based on Fig 59 in the Design guide.

There is an alternative method that can shut power OFF without the latching kill signal, and is being explored. Even if that works, however, my hope to eliminate the 3.3V peripheral power switch in fig 55 of the Design Guide appears to be futile, given that IOs cannot be driven while POWER_ENABLE_MICO is low.

I fully agree, the 60ms are caused by the 32ms off_delay and 28ms power up sequence delay.

The Ethernet part is powered with its own rail in order to be able to switch it off independently. The Ethernet rail is not part of the fused power-up sequence. The rail remains powered off until U-Boot turns it on. Therefore, the rail is low for around 700ms, depending on the loading time of U-Boot. -This means all Ethernet related signals (ETH1_xx) are undefined for around 700ms.

The rest of the signals are IO ports of the SoC. The power up sequence of these pins are set by the PMIC fuses. Therefore, the power rails of these rails is going down for the time the POWER_ENABLE_MOCI is down (around 60ms).

Thank you for letting me know the motivation for your investigations. Maybe there is another solution I can share. On the Apalis evaluation board, we have a power button circuit with a kill input (see page 4 on We blank the kill input with the RESET_MOCI# signal. This signal goes low before the power rails are removed and will not go high until the U-Boot has fully initialized all IO pins. On the evaluation board, the kill input signal (FORCE_OFF#) is connected to a pin header. The intention is to use any free GPIO to connect to the FORCE_OFF#. In the software, this according pin should be then driven low in the shut down routine just before the shut-down command is sent to the PMIC. This will actually kill the supply before the PMIC is shutting down the power rails. However, this is not an issue, since it is allowed to remove the power rails from the Apalis module without executing a PMIC power down.

Peter, Our design uses a power button controller of the same series as that on the Eval board. I have solved the pulse masking problem with an external one-shot circuit since figure 59 does not detail the timing of RESET_MOCI with respect to POWER_ENABLE_MOCI (can’t assume identical timing to that shown in fig 58) so I could not trust to use it for blanking as done in the Eval. An external one-shot works on POWER_ENABLE_MOCI alone, eliminating any inter-dependencies with other control signals.

Even if RESET_MOCI is guaranteed to fall before and rise after the edges of POWER_ENABLE_MOCI, another fundamental problem arises. On legitimate power shutdown, RESET_MOCI also asserts before POWER_ENABLE_MOCI, but never returns high, permanently masking the shutdown request. I believe this is why you suggest a GPIO to drive FORCE_OFF; unfortunately, this returns additional software handling of shutdown that we are trying to avoid in the first place. Unless you’re aware of any on-SOM configuration options that are customer accessible and could change the RESET_MOCI behavior, the external one-shot seems to be the best hardware-only solution.

Thank you for sharing that information. Indeed, my suggested GPIO solution requires additional changes in the software. It seems I cannot offer you a better solution than the one you already implemented.

Peter, can you please clarify the suggested approach you had made regarding FORCE_OFF driven by a GPIO. Does the Linux distro presently made available for the TK1 have the suggested shutdown code, or is that left up to your customers to develop?

The Ixora boards we have used for early development appear to power down on commanded shutdown from the Linux GUI. Does the board fully shut off or does it also come to rest in an intermediate state where the 3.3V converter remains active and powering the SOM? Have I missed an additional on-board connection to FORCE_OFF from the SOM or some control logic on the board?

Please have a look to this article which describes the implementation of the GPIO power off under Linux. Unfortunately, it has not been tested with the TK1 so far. However, according to my college, it should also be working.

The Ixora implements the same circuit as on the Evaluation Board. Since the FORCE_OFF is not connected by default to a GPIO, I highly doubt that it works on Ixora out of the box. Are you sure that the carrier board was completely powered down and nut just the module and peripheral rails?

We never really checked but just assumed the power was all OFF when the Ixora shuts down. I guess it likely also sits in the intermediate state like our present carrier. I’ve confirmed that the SOM starts the system back up from this state when RESET_MICO is asserted, at least on our carrier, but I suspect the same of the Ixora given you have confirmed that nothing else drives the FORCE_OFF.

Given the end use is for a medical lab instrument, my client is understandably extremely sensitive to software versions and features. Unless a function is already included (and tested/assured) out-of-the-box, a hardware only solution is much preferred.