the GPIO state in LPC4350

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

the GPIO state in LPC4350

583 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by david_sh on Fri Jan 11 01:59:07 MST 2013
Hi,

All GPIO pins in lpc4350 default to inputs with pull-up resistors enabled, it means that it can provide a high level to the peripheral connected with it, such as led, vibrator?

I have tried using the Hitex 4350 dev board, found that the GPIO state is maintained when i call PWR_Sleep() function; the GPIO state can't be maintained when PWR_DeepSleep() is callled, is it right? but i need the maintanied GPIO state when LPC4350 is in deep-sleep state, would you like to provide several suggestions?
thanks in advance.

Regards,
David
Labels (1)
0 Kudos
6 Replies

537 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jonper on Mon Apr 08 11:42:08 MST 2013

Using LPCOpen V1.02, I observe that same lost GPIO state behavior when running the app_pmc_states example in the "lcpopen\applications\lpc18xx_43xx\examples\misc" directory which references the "pmc_001.h" file in "lcpopen\software\lpc_core\lpc_ip"; in which the macros defining the power modes still uses the same PMC hex constants as the pre-2013-01-17 as the LPC43xx CMSIS driver library.


As a workaround, I can use brute force methods to override with the post-2013-01-17 CMSIS constants and see runs of the app_pmc_states example maintaining GPIO state in Deep Sleep and Power-Down modes.


Is LPCOpen going to follow suit with LPC43xx CMSIS driver library and replace the PMC hex constants in a future release? Thanks

0 Kudos

537 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by samc77 on Wed Jan 30 09:12:09 MST 2013
Hi Dave,

thanks a lot, fixing the driver did it!

Now I am happy and can use the chip as expected!

Simon
0 Kudos

537 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by nxp21346 on Thu Jan 24 09:05:45 MST 2013
Sorry- I made a mistake. GPIO state should be maintained in Sleep, Deep Sleep, and Power-Down mode. They are only shut off in Deep Power-Down mode. In addition, there was a bug in the DeepSleep example that has been patched in the git repo. Here is a link to the fix:
http://sw.lpcware.com/?p=lpc43xx.git&a=commitdiff&h=6ed0a6486b23886e327cd81790bb0e09d85107de
The following macros were defined with an incorrect value:

#define PWR_SLEEP_MODE_DEEP_SLEEP 0x3000AA
#define PWR_SLEEP_MODE_POWER_DOWN 0x30FCBA
#define PWR_SLEEP_MODE_DEEP_POWER_DOWN 0x30FF7F

-Dave @ NXP
0 Kudos

537 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by samc77 on Fri Jan 18 08:03:36 MST 2013
Hi,

So why does the manual mention, that in Deep-Sleep:

"In Deep-sleep mode the CPU clock and peripheral clocks are shut down to save power;
logic states and SRAM memory are maintained."

What is ment with "logic states" if not the logic states of the pins?

Ok, if it is still like this, and I need to use Deep-Sleep. I will have to make sure, all GPIOs that cannot be tristate during deep-sleep must have a pullup or pulldown, right?

That can work if the GPIOs always keep at the same state for every deep-sleep. If a GPIO sometimes must be high, sometimes low, how to do this??

Please, can anybody comment on this?
I didnt expect it to work like this, the LPC17xx are different..and I didnt find this to be mentioned in the docs anywhere.


Thanks
0 Kudos

537 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by david_sh on Tue Jan 15 19:55:13 MST 2013
i see, thanks a lot!
0 Kudos

537 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by nxp21346 on Tue Jan 15 14:38:00 MST 2013
Hi!
GPIO state is not maintained during Deep Sleep. You will have to use the Sleep mode instead. To further reduce current consumption in Sleep, you can change the system clocks to use the Internal RC oscillator (12 MHz) and a divider (like IDIVE which can divide by 256) to achieve the very lowest current consumption before entering Sleep instead of running at 204 MHz or something high speed during Sleep.

-Dave @ NXP
0 Kudos