AnsweredAssumed Answered

Any condition that needs to be polled for Accelerated STANDBY Exit? (MPC5748G)

Question asked by Gonzalo Victorio on Jul 5, 2016
Latest reply on Jan 26, 2017 by Gonzalo Victorio

I have configured the MPC5748G to enter from DRUN into STANDBY, taking care of shutting down clocks for peripherals that were in use, clearing interrupts, disabling 2nd core, etc (anything that would prevent the transition to STANDBY in the 1st place). I also have my wakeup sources configured for a couple CAN Rx pins and activity on an input pin. My intent is also to use the Accelerated Low Power Exit so in ME_DRUN_MC I have the system clock set to the PLL and PLLON and FXOSCON are set.

 

So, entering into STANDBY works... and exit out of it was working, but after moving the following functions (based from the Freescale Eval board examples) early to the __start.s file before ECC, stack and .bss/.data initialization (to reduce boot time) I started having a problem, which only happens if the debugger (Lauterbach) is not connected:

  • memory_config_160mhz
  • crossbar_config
  • bridges_config
  • peri_clock_gating
  • system160mhz

 

Basically when the debugger is not connected (i.e. target connected stand alone) and I let the target enter STANDBY mode, if I trigger a wakeup condition (I/O pin or send CAN msg) the MPC5748G seems to hung somewhere during the startup code. Unfortunately if I reproduce the issue and try to attach with Lauterbach debugger Trace32 gives me a debugging error so it does not allow me to connect to the system (I was hoping to look at registers while on that condition) so I have only been able to debug this by toggling debug pins in different phases of the init sequence.

 

So far I've discovered that when the target HW wakes up from Standby the MC_ME.GS.B.S_FXOSC field is reported as not stable so I added a delay before memory_config_160mhz to make sure that it doesn't continue unless MC_ME.GS.B.S_FXOSC and MC_ME.GS.B.S_PLLON are set but still the target HW is getting stuck somewhere. It takes ~1.86ms to report a stable FXOSC.

 

I tried skipping memory_config_160mhz and system160mhz if the system clock reported in MC_ME.DRUN_MC.B.SYSCLK is already the PLL (since it is supposed to exit from STANDBY using the PLL) but the problem still occurs.

 

It puzzles me that the issue does not occur when the debugger is attached and I run the sequence like that... I don't know if somehow the debugging session is making conditions more stable or adding some delay(s) that allows the STANDBY exit to work correctly. If I move the functions listed above to run after entering main() then things work again.

 

Additional info:

  • PLL is set to 160MHz (based on 16MHz crystal)
  • Execution is from FLASH
  • For STandby configuration, Flash is configured to stay on and No system clock (since they're all reserved):
    • MC_ME.STANDBY_MC.R = 0x0001000F;

 

Questions:

  1. Is there any condition that I need to poll when the code starts before I can continue with normal init process?
  2. Is it safe to assume that the memory and system do not need to be configured for 160MHZ PLL if DRUN was already configured for that before entering STANDBY? Any clarification of what and what should not be re-configured is appreciated.

Outcomes