Content originally posted in LPCWare by jonper on Mon Jun 25 16:21:26 MST 2012
I am seeing all of my LPC4350 I/O lines going into a high-impedance mode when I run the Pwr_DeepSleep, Pwr_PowerDown, or Pwr_DeepPowerDown examples; they then return to their previous state after wakeup. This runs counter to my experience with other non-NXP microcontrollers and hopefully I’m just doing something wrong. The standard Sleep mode behaves as expected.
I’m using IAR EWARM 6.4 and the PWR example from lpc43xx-2012-04-17.zip Peripheral Driver Library with an LPC4350FET256 (PFM906.04 10 ESD1149ZRY) on the Hitex LPC4350 Rev A4 board, though I’ve seen similar results on with earlier versions of IAR, the PDL, and (PFM906.04 15 ESD1148ZRY) parts on two Diolan DB1 boards.
The simplest demonstration is just running the PDL Pwr_DeepSleep project from internal ram and putting a scope on the CMOS-level TXD pin used by the debug_frmwrk (U0_TXD output on the SV1 pin 5-6 jumper near the DB9 connector for Hitex A4), or the equivalent TXD connector for a different board. For the Hitex A4, you also need to change the project’s lpc43xx_libcfg.h to #define _UART0 instead of _UART1.
Run the project and watch the scope trace. It will start out high, toggle when it sends the menu message and then settle high waiting for you to type ‘1’ to put it to sleep. When you hit ‘1’, the trace will drop. If you touch the scope probe pin or connect to 3V through a 1meg resistor you’ll see the pin is floating. When you hit the A4 wakeup button, the pin returns to its normal functioning state.
On the Diolan board I can also see all of the EMC address and data lines behave similarly at the parallel flash. The implication is that while the LPC4350 power drops just fine, any devices previously being driven will inherit floating inputs and unpredictable power demands. Setting outputs to inputs with on-chip pull resistors before sleeping doesn’t help because they also go full tri-state for the sleep period. Sprinkling four score pull resistors around our board seems a most unpleasant prospect.
Is this really the normal behavior for NXP micros in general and this one in particular?
If not, can anyone confirm or challenge what I’m seeing?
Any other suggestions?
