Is it possible to suspend and quick-wake the BBAI64 (or BBB) via input/power pin?

It’s my understanding as I read through the TDA4VM documentation that the platform has 5 or so power modes (tda4vm.pdf Sec9.1):
• Full Active
• MCU Only low power mode
• DDR Retention (Suspend-to-RAM or S2R) low power mode
• MCU Island safety monitor
• Extended MCU safety monitor

For the long-term application I have in mind, I would like for the entire part to be able to transition between a low power “sleep” mode and quick-wake back to full active duty. I’m assuming the state, as described above, would be the DDR Retention low power mode.

The specific application being targeted with this project is to replace the PROM of an Electronic Engine Controller (EEC) amongst other things. So while it may be perfectly acceptable for 1st boot to take upwards of 1 minute, the device needs to be able to be put into a low power mode so as not to drain the vehicle battery when the vehicle ignition is OFF. And likewise wake as quickly as possible when the vehicle ignition is turned back ON…ideally in the amount of time it takes a person to turn an ignition key from the OFF position to the ENGINE CRANK position.

However since this would be used by mostly enthusiasts, a slightly longer-than-OEM delay may be acceptable, but it’s not reasonable to expect that a user must turn the key to the IGNITION ON position, wait for the entire BB to completely boot before attempting to crank the engine.

The main point of this question is if the TDA4VM is capable of putting the A72s into a low-power mode and quick-waking them from this mode in a matter of, lets say, 100ms?

And is the BBAI64 wired to support transitioning between these power modes?

If anybody has actually done this and has real-world low-power mode current draw numbers, I’d be interested in hearing them as well.

I haven’t found any info on whether the PRUs can also be transitioned between low-power and full active mode. The only mention I can find that is close is in the J721E PRU Users Guide (spruj61.pdf Sec 5.2) where it talks about transitioning between idle and active operation. But in this case, I interpret idle as not the same as low-power mode. More importantly, I haven’t found any indication that the PRU RAM will be held up while in any of the various low-power modes although I would HOPE that since PRUs use internal RAM (primarily) that it along with their various registers (special and general purpose) would be held up during this mode. If they are, that’s great. However it’s not the end of the world if each time the platform returns to “Full Active” mode, the PRUs have to be reinitialized as well as transitioned from idle-to-active. Their programming, will be quite small (few kB), and capable of being loaded and ready for execution well within that 100ms window.

If the BBAI64 isn’t wired to support a low-power suspend & quick-wake, then my next-best hope is that the MCU R5F cores can be coded to load PRU RAM and transition each PRU core needed to Active mode (not via remoteproc or uio from Linux), then that’s also an option if a full powerup mode is all that’s really available on the BBAI64. Although I suspect I’ll be trail-blazing to figure out how that’s done as I suspect nobody’s actually used the R5Fs to bring up PRUs.

Note the inverse scenario is not a problem, where the user turns the ignition OFF. The BBAI64 will be supplied with “always-on” power even with the ignition OFF. Thus it should be able to perform an orderly active-to-idle transition of all PRUs as well as prepare other aspects of the system to be suspended.

A far more concerning aspect for me is where the BBAI64 can be held since it produces a non-trivial amount of heat but yet it needs to be kept relatively close to the EEC to minimize bus-line capacitance on a memory bus that could operate as fast as 12MHz (although typical is 5-8MHz).