• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 103 subscribers
  • Views 198 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VM: What is required to suspend and wake up a BBAI64?

Christopher Grey
Prodigy 25 points
Part Number: TDA4VM
Other Parts Discussed in Thread: SYSCONFIG

I'm working on the BBAI64 platform, however this is a question that is generic to the J721E/TDA4VM microcontroller.

One of the things I’ll need to accomplish is to put the BBAI64 into a low power mode, but wake it back up in a state similar to how it went to sleep, and preferably wake much faster than a complete reboot would. From the J721E TRM, these are the various powermodes supported by the chip:

image321×508 15.7 KB

My intention is to get as low of a power-signature from the device as possible, preferably <25mA while asleep. And with the assistance of a GPIO pin (likely from the WKUP domain), power back up to the same state it was in prior to being put to sleep including resuming Linux and any/all Linux applications from the position of execution prior to being put to sleep.

Reading through the descriptions of each, it’s not really clear what the consequences to each are. For instance, if the chip is put into a SuspendToRAM state, when being reactivated, will Linux have to be rebooted and all applications relaunched?

Or can Linux (and any applications launched) resume where they were?

Can the microcontroller be returned to active state via a GPIO pin while in this state?

If I had to guess the SuspendToRAM is not really an appropriate state for Linux. I suspect it would probably work better for an RTOS environment.
Looking deeper into the TRM, I find this:
image833×514 48.9 KB

The only state that shows it is transitioned away from due to GPIO is DeepSleep which further supports my suspicion that this is the best state for my intentions.

As I read further, Stand-by technically can also but that’s only because Stand-by is not a very low power mode. Everything is powered and remains running, just at a lower speed hence I suspect any GPIO pin could be used to trigger the system out of this mode, not just a WKUP pin. And while this is a "lower-power mode" compared to active, my guess is its power draw is still going to be significantly higher than a car battery could tolerate for long periods of inactivity. As stated earlier, ideally a draw of no more than 25mA would be preferred while asleep. My guess is this mode would be a few hundred mA.

This is BBAI64-specific info here, but I didn’t find any pins on P8 or P9 that are in the WKUP domain, however the UART0 pins on the tiny white connector labelled J2 along the edge of the BBAI64 are from this domain. Since I don’t need that UART, I’m fine commandeering one of its pins as a wakeup trigger. Out of lack of any other knowledge, I chose WKUP_UART_RXD (J29) and mapped it as a GPIO pin in my Sysconfig.

The plan is to be able to send a voltage into that pin and have the system come out of sleep and return to full function, no different than a computer would being woken from a sleep-state.

So given these intents:

  1. Is my approach on point or are there some caveats and details that I’m obviously not aware of that are going to require I alter my approach?

  2. Assuming this approach is possible, what else other than mapping the pin as a GPIO pin is necessary to trigger a wake-up behavior? I don’t know if it needs to be mapped in the DTB as an interrupt or if there’s some other more-specific incantation required.

  3. What command from Linux puts the BBAI64 into "the best target state" for my intentions?

  4. Are there any other details or caveats to transitioning in and out of this mode that I should be aware of that would be relevant.
  • 0
    TI__Guru*** 130930 points

    Hi,

    The hardware definitely supports the low power modes however in the SDK(Software) there is NO support for suspend to RAM and wake up from that.

    This is a heterogeneous SOC. R5F is the boot core which also runs the device manager, M3 runs the TI foundational security. A72 runs the HLOS.
    So entering low power mode from Linux will need to diligently save the context of all the multiple firmware that run on the multiple cores of SoC &
    restoring it back. In short this is a complicated feature and there is NO support in software. No plans for support in future.

    - Keerthy

  • 0 in reply to Keerthy J
    Prodigy 25 points

    This is what I suspected SuspendToRam was. And what you've detailed is what I would expect to be required for that level of sleep since the processor(s) pretty much all get shutdown and effectively have to restore themselves very much like a PC waking from Hibernate where all their state info is on the filesystem. And this would work fine for an RTOS that will reuse memory locations freely. However to support this in Linux, I'd think Linux itself would have to support this (similar to Hibernate on a PC/laptop).

    However the DeepSleep state, I would expect to NOT be nearly so complicated. The Processors would not be unpowered and thus their internal states & register values should be maintained...according to this from the TRM:

    Essentially their clock signal is just not ticking hence how low power consumption is maintained.

    In Sec 12.1.2.4.5, there lists steps necessary to perform to enable WKUP_GPIOu wakeup events prior to DeepSleep and what's required to wake back up. What I'm looking for is some guidance on how to implement these steps. Here's the section from the TRM:


    I believe I've done the first bullet by selecting a GPIO pin from the WKUP domain and included it in my Sysconfig-generated dtsi that will be used to rebuild the device-tree.

    However the other steps, it's not clear to me when and where these should be done in the context of a system that is up and running. For example, should it be Linux doing this running in the A72 or some other code that's  loaded into the MCU R5F? I have to believe TI tested this and thus has some example code that can be used, at the very least, for inspiration, if not verbatim. So, here are my questions.

    What's required?
    What's already developed? ...And how do I make use of these existing developments?
    What remains unsolved?

    It's my understanding that TI's intention for the TDA4VM is to target automotive applications. In that environment, systems need to be reactivated quickly after the ignition is ON, but consume minimal power when the ignition is OFF. So it seems reasonable that TI would want to make entering and leaving these kinds of states as standard and easy to implement as possible. The idea and concept of low power modes is not new. PCs and Cell Phone processors have support for these modes. So it doesn't seem like it would be a difficult thing to accomplish with existing open source developments in Linux/Android. I just don't know what those developments are hence my coming here asking the questions.

    However if support simply does not yet exist for what I'm trying to do with DeepSleep, perhaps you can tell me more about StandBy mode. That mode has ALL aspects of the system still powered, but running in a low power mode...presumably a much slower clock rate? Is this mode easier to enter and leave without a bunch of reconfiguration of the system? If so, maybe you should share details on how this low power mode is utilized.