Apalis carrier power fail

Presently designing a custom carrier for an Apalis TK1, using the board design guide, and have two main questions regarding power shutdown handling. I assume the guide applies generically to the entire Apalis SOM family and would expect all requirements and behaviors discussed in the Power Management chapter to be uniformly applicable.

First Question: Fig 58 of the guide shows a shut-down sequence initiated by the SOM CPU, however, no minimum time is provided between POWER_ENABLE_MOCI falling edge and the module internal rails shutting down, making it impossible to know how long main VCC must remain valid after the falling edge. Are there any IOs on the MXM3 card edge that provide the on-module status of its power rails, ideally a signal that indicates “all clear” to switch the main power off?

Second Question: There is no information regarding loss of main power. Since figures 59 and 61 seem to imply that neither the RESET_MICO# nor WAKE1_MICO# affect the internal rails, There doesn’t appear to be an early power-fail detect input that prepares the module for imminent power loss. If RESET_MICO# is designated for this purpose, presumably setting the stage for safe power removal once the internal reset is asserted, I need to know the minimum time between the RESET_MICO# falling edge and the internal reset active. Is there a specification for the maximum time I need to hold up the main VCC following the RESET_MICO# assertion?

thank you very much for the interest in Toradex products and for using the Developer Community website.
Regarding your questions:

  1. When we have designed the Apalis standard, we decided to keep the power up and down requirements as simple as possible. When the modules get the 3.3V VCC input, it starts to boot, and once the internal power rails are up, it releases the POWER_ENABLE_MOCI.
    This signal is used to notify the carrier board the peripherals 3.3V and 5V power rails can be enabled.

The Apalis standard does not provide a standard pin which shows that the module power rails have been powered off.

The shutting down behavior of the module rails depends also on the module type and this is why figure 58 does not specify this minimum time.

What I can say is that, if the module is not busy writing data on the flash, it is allowed to shut it down by simply removing the VCC input for the module, after the release of the POWER_ENABLE_MOCI signal.

  1. For the reason previously mentioned, the Apalis standard does not provide this power-loss standard pin. The recommendation we give to our customers is to detect this power loss on the carrier board and notify this situation to the module by using, for example, a GPIO.

The software will then start a shut-down and the carrier board needs to provide the Module VCC input for the time required by your system to complete the shut-down without any loss of data. This time depends also on the software application running on the module and therefore can really vary.

I really hope that the information provided helps, please don’t hesitate to write again if you need further help.

Hi Diego
For question 1, you are suggesting that our carrier system be aware of Flash write activity; I was hoping that there was a more direct way, through available MXM pins, to determine that the SOM has shut down it’s internal rails. It seems your customers are left to devise this power management function on their own and your reply to question 2 makes this clear. That’s OK but I had hoped there was a more elegant way using Toradex provided SOM management APIs and defined IO pins.

The scenario posed by question 2 gets into some murky waters regarding the on-SOM power system design. Suppose we develop an early power fail using a GPIO input that locks the Flash filesystem ASAP, then immediately jumps to the power shutdown API. Since that routine is likely SOM specific, it should be provided by Toradex, correct? If the SOM power system needs certain sequences and delays that are effectively hidden from your customers, what information do we have about the required power hold-over time that must be designed into our carrier system? We would at least need to know the amount of time required to maintain VCC from the moment the shutdown API is called. This information is not provided in either the Apalis carrier design guide nor the TK1 module datasheet.


  1. I probably picked the wrong example to explain to you that our approach is as simple as possible, to make our customers’ lives easier and to have a really flexible approach. I kept it too generic, sorry about that.

The message that I want to communicate is that you don’t really need to take care of the module power rails power down sequence because when you initiate the shutdown in software, it will close all the applications, it will unmount the file system, etc… and, on the Apalis module, it will also release the POWER_ENABLE_MOCI.

You can then use a GPIO to notify your carrier board that it can cut the module VCC without causing any issue.

The best way to implement this GPIO power off is described here:

This is a specific solution adopted by many Toradex customers and as you can see is quite flexible since you are not forced to use a specific pin for this purpose.

So the message here is that there is not a defined pin for that, but we do provide solutions for that.

  1. Also in this case, I was keeping the answer on a generic level. Sorry again.
    Toradex does provide to his customers a way to trigger through a GPIO (which simulates, for example, a power button) a system shout down.

More information about this concept can be found here:

We don’t’ provide yet (we kept this feedback) an emergency shutdown routine which would ensure that the system gets shouted down in milliseconds, but using the above-mentioned method, a normal shut down routine will be executed.

This normally takes about 5 seconds but it really depends on the module and on the specific customer application.

Let say, for example, that your system is recording a video; maybe you need to make sure that the video is saved on flash before the system shuts down. Then I would assume that you will definitely need to power the system for a longer period of time.

This is what I meant when I said that this time can really vary. Also here the message is that you are not forced to use a particular pin which is defined for this purpose, you can use a GPIO for that and this flexibility is normally appreciated by our customers.

Of course, our software engineers are here to help you, if possible, to fine-tuning these procedures and come up with a robust and safe system.

I hope I managed to explain what is the Toradex approach on this topic and to convince you that we provide to our customer a reliable system on which they can build their own specific applications.

Please don’t hesitate to reply if you need additional details on this topic.

Diego, thanks for the further info. I appreciate that Toradex tries to make the power handling simple.

Regarding question 1, I am curious about the need for a user defined shutdown GPIO. As you stated, the POWER_ENABLE_MOCI will be released on initiated shutdown, presumably the very last action after all local activity is closed down. I interpret this statement as meaning that POWER_ENABLE_MOCI release is the final “all clear” to shut off VCC power. Is there really any purpose then to having a separate user defined GPIO? When would that user code run; before, or after the POWER_ENABLE_MOCI release? Are there any system states where the POWER_ENABLE_MOCI is de-asserted but power is expected to remain? The Reset and Suspend state diagrams figs 59 thru 61 in the Apalis design guide show that POWER_ENABLE_MOCI remains asserted. Can you see any problem in using POWER_ENABLE_MOCI as the “shutdown GPIO” signal?

The reason I originally raised the point about a final power-off all-clear was the depiction in fig 58 of the internal rails removed some undefined time after the de-assertion of POWER_ENABLE_MOCI. From my experience with complex CPU and FPGA devices, power-off often requires a specific sequence and sometimes even a defined delay between rails. Can I safely assume that the on-SOM power system has been designed to safely execute proper power-down sequence and delays if VCC power is removed in a hardware delay timeframe (<1usec) following POWER_ENABLE_MOCI de-assertion?

Regarding question 2, the use of filesystems such as JFFS2 rather than FAT really hardens against sudden power losses, however, many smaller systems can’t afford the luxury (and Flash wear) of a journaling filesystem. Since our system will not use a mechanical disk drive, we don’t need to worry about completing a block write and parking the head, which can require upwards of 16-20msec of power hold-up time. It is still good design practice, however, to design for a hold-up time that allows any Flash write cycles in progress to complete, which typically requires less than a millisecond. Combined with an early warning detection (DC input drops >25% from nominal) and enough local energy storage to maintain system power for a few milliseconds after detection, all we need is a high priority interrupt GPIO to the CPU. I guess this is something we will have to develop on our own, given that you don’t provide an emergency shutdown API.


the idea behind the signal POWER_ENABLE_MOCI is to notify the carrier board that it can start powering up the carrier peripherals. The main purpose of this concept is to avoid back-feeding from the carrier board to the module.

During the shut-down, the POWER_ENABLE_MOCI is de-asserted somewhere in between the module power rails power-down sequence (it is not always the same for all the Apalis modules, it really depends on which module power rails it is linked).

The shutdown GPIO is instead released/triggered on the place of the module power rails power sequence.

I will explain a bit better this sentence: when, in Linux, the power off sequence is triggered, the systems close all the applications, makes sure that all the partitions are unmounted and when it is all done and the system is basically running on RAM, launches a function which notifies the PMIC that it needs to initiate the power down sequence.

The shutdown GPIO is basically replacing this function and, therefore, instead of going to the road of PMIC power down, it, if connected to the external PD/DC, cuts the power to the module.

This is perfectly legal and allowed for our modules, we propose this solution because we know it does not give any issue.

Said that, of course, it is perfectly fine to use POWER_ENABLE_MOCI as “all clear” signal, but you will then make sure that you don’t have a problem when you are starting your system.
The POWER_ENABLE_MOCI is low when the module is booting and therefore you need to blank this signal when the module is booting, otherwise, you will kill the main DC/DC.

The Power OFF GPIO, on the other hands, is only triggered when the system is powered off, the value is not changed during the booting and therefore it is a bit easier to be handled. This is probably the main difference between the two approaches.

Regarding the second questions, any GPIO could be used as interrupt, but we highly recommend using a TK1 pin and not one of the K20 microcontroller.
Since some of the Tegra K1 signal pins feature a unidirectional level shifter, it is important to check whether the pin can be used as input. The best choice is probably GPIO1 to GPIO8.
You can find more information about GPIOs, in sections 4, 5 and 6 of the Apalis TK1 datasheet:

Please write us again if needed! I wish you a nice day!

If I understand correctly, the POWER_ENABLE_MOCI would actually occur later than a GPIO signaled " OK to power-OFF" as it is de-asserted during the on-SOM rail shutdown sequence rather than at the power-down routine entry point. Your point regarding careful use of the MOCI signal was already well understood; it would be used only as a mask when asserted to prevent accidental user power switch-off before the system is commanded to shut down. Once the signal de-asserts, removing the mask, the state of the power switch is let through to the power manager. If the switch happens to be OFF, the shutdown will initiate with very little delay on the falling edge. What I interpret from your reply is that any internal sequence delays required in the SOM power system have been executed prior to the MOCI de-assertion, thus safe to power OFF immediately.

The only risk in our approach is that if something goes wrong and MOCI stays asserted, you may not be able to switch the power OFF. In that case, pulling the plug would be necessary, and if the system is still sane enough to receive and handle the early power fail warning interrupt, may still be able to safely power down without memory corruption.

yes, you understood correctly, the the POWER_ENABLE_MOCI signal would actually occur later than a GPIO signaled " OK to power-OFF".
You also interpreted correctly the other part: “any internal sequence delays required in the SOM power system have been executed prior to the MOCI de-assertion, thus safe to power OFF immediately.”
It has been really interesting to discuss with such a well competent customer! I wish you a nice weekend!