Does AM335x standby power mode involve Cortex M3?

Thanks for the link so far.

That means the wording from section 8.1.4.3.2

Wakeup in Standby mode is achieved using any GPIO. GPIO wakeup is possible by switching the pad to GPIO mode and configuring the corresponding GPIO bank for generating an interrupt to the MPUSS.

is a bit misleading?

It reads like it would require a INT to the MPUSS only, which seems to point to solely the A8.

Regards

Wolfram Stumpf

See also section 8.1.4.6.

Wolfram Stumpf16 said:

• • PD_MPU = OFF

I'm pretty sure the cortex-a8 can enter this state on its own, but without external assistance it will never be able to exit it.

External assistance would normally mean the cortex-m3, which is after all included specifically for that purpose. But, with PD_PER and the main oscillator still enabled, the task of reenabling the cortex-a8 could in principle also be done by DAP (JTAG), a PRU core, or even EDMA.

Wolfram Stumpf16 said:

That means the wording from section 8.1.4.3.2

Wakeup in Standby mode is achieved using any GPIO. GPIO wakeup is possible by switching the pad to GPIO mode and configuring the corresponding GPIO bank for generating an interrupt to the MPUSS.

is a bit misleading?

It reads like it would require a INT to the MPUSS only, which seems to point to solely the A8.

That does sound a bit odd. It would make sense if PD_MPU is kept on, since then the intc could generate an MPU_WAKE request to the cortex-m3. But as far as I know the cortex-M3 does not directly receive irqs from GPIO banks other than GPIO0. This isn't very clearly documented though.

On the other hand, the TRM section does seem to strongly imply special arrangements have been made to allow all GPIO banks to wake up the system via irq even though MPU power is lost.

Wakeup in Standby mode is achieved using any GPIO. GPIO wakeup is possible by switching the pad to GPIO mode and configuring the corresponding GPIO bank for generating an interrupt to the MPUSS.

Is this valid for for standby? I'm using SDk 2.0.0.2.11 , 4.1.18, EVMSK board and cant find a reliable source to set to wake up from Standby using GPIO1_x pins. GPIO0 works but I'm interested in GPIO1 or GPIO2. I have tracked down the cortex m3 commands and it corresponds to the "standby" from  when a standby is sent. But looks like the sources to wake up are similar to DS0 and DS1 hence I cant find any difference for stanby wakeup. 

So, in my previous post I expressed confusion about how irqs to the cortex-a8 would be of any use when PD_MPU is switched off. Now that I've looked at it again the reason turned out perfectly clear: the Cortex-A8 interrupt controller is not part of PD_MPU, but rather PD_WKUP. (I'm not sure whether I managed to overlook that last time or whether the documentation has improved since then.)

This means that the cortex-A8 can leave irqs enabled that it wants to wake up on, then enter suspend. Even with subsequent disabling of PD_MPU the irq controller will still detect if an irq is asserted and lets the cortex-M3 know about this instead via its "MPU wakeup" irq (interrupt line 32), which can then proceed to exit suspend. I have done a quick test and confirmed that indeed irqs such as from gpio2 results in the MPU-wakeup irq being asserted to the cortex-M3.

(In fact while testing this I noticed the output of the interrupt controller also seems to assert a wakeup request to PRCM, causing the MPU to resume even if its MODULEMODE is set to disabled and the clock domain to SW_SLEEP, and maybe even if the power domain was off. I have to qualify this with a "maybe" since I eventually noticed I was accidently still connected to the cortex-A8 via JTAG, which overrides prcm thus tainting the results. This would need to be double-checked without JTAG but I ran out of time. If true, this seems to suggest the M3 isn't even needed for standby.)

I haven't observed any special behaviour w.r.t. the GPIO controllers, this works for any IRQ as long as the source module is enabled and whatever clocks it needs are available.

If it's not working, then my checklist would be:

• Are the irqs enabled in the peripheral and in the interrupt controller?
• Is the peripheral enabled (modulemode = 2)?
• Is the clock domain awake? This may not be required for all modules, since sleeping the clock domain only cuts interface clocks. For the GPIO modules however the interface clock is also used as functional clock, hence if the l4ls clock domain enters sleep the gpio modules are frozen and unable to generate any irq.
• Are relevant clocks available and usable? The GPIO controllers don't care really what frequency they're clocked at, but some other peripherals are timing-sensitive, which may preclude putting all PLLs in bypass. If debouncing is used in the GPIO controllers make sure the debounce clock is not accidently disabled.

Hi Matthijs,

Thanks for response. I just would like to ask a couple of things about your setup. Did you run your test on a AM335 EVM board? How did you set up the GPIO irq? Did you use a linux kernel and set it up through a device tree ?

Like i mentioned earlier setting up through device tree works only for GPIO0 so far. I havent been able to replicate that with GPIO1-3. Its possible that the GPIO1-3 modules are frozen, but I m not sure how it will be setup differently froom GPIO0 to GPIO1 since the earlier on works.

I used baremetal code on a BeagleBone Black, a little test I already had that toggles a led in response to a button (essentially the functionality of this tiny demo, but written in C++ in the framework of my own baremetal codebase). I used JTAG to upload a deadloop to cortex-m3 memory and release it from reset, allowing jtag attachment to it to inspect its irq registers as well as granting direct l4wkup access to ensure I could safely play with PRCM. For a few tests where I was disabling interconnects I also connected to the cortex-a8 to halt it, to make sure it wouldn't try to perform some access and get a bus error. Instead I then inspected its irq controller registers to check under which circumstances the irq becomes visible (revealing e.g. that the gpio modules do not function in "interface idle" mode that results from sleeping the clock domain).

GPIO0 is a completely different story since it's on the l4wkup and has direct irq lines to the M3. Moreover it is async wakeup capable so it doesn't even need to be enabled/clocked afaik.