Reducing power on 5270/34 products

Post your example source code and application notes to share with others
Post Reply
User avatar
lgitlitz
Posts: 331
Joined: Wed Apr 23, 2008 11:43 am
Location: San Diego, CA
Contact:

Reducing power on 5270/34 products

Post by lgitlitz »

I recently created an example to reduce power on the network modules. This is meant for a future application note that will likely have more in depth power saving such as stop mode for disabling peripherals.

This example includes a functions to set the module to various speeds, there are also comments in the example indicating the currents recorded for each speed. All currents were tested with sub $100 multimeter in a series power circuit of 3.3V generated from a lab power supply... to be conservative I would give these results a 5-10% error.
void SystemClock147MHz(); // Ethernet Enabled - 263mA -> Disabled - 130mA
void SystemClock59MHz(); // Ethernet Enabled - 209mA -> Disabled - 75mA
void SystemClock29MHz(); // Ethernet Disabled - 55mA
void SystemClock14MHz(); // Ethernet Disabled - 46mA
void SystemClock2MHz(); // Ethernet Disabled - 38mA

The processor runs at all these speeds with full use of SDRAM. These functions also reconfigure the OS tick duration which will allow the OS to function correctly.... 20 ticks per second is still 20 ticks per second. These function also reconfigure the serial port to function at the correct baud. All of the tested speeds will work with 115200 baud except 2MHz, this has a max serial baud of 9600. The serial speed for the application can be changed in a define at the top of the example( SERIAL_BAUD 9600 ). The SDRAM is rated with a minimum speed of 1MHz, the external clock speed is half the CPU speed which is why 2MHz is the lowest we can run with use of SDRAM. Ethernet requires a minimum speed of 50MHz so the closest speed greater then this is 59MHz, any lower and Ethernet does not function. None of the other peripherals or drivers have been tested at these low speeds so they are not guaranteed for function properly.

Flash was not tested and I suggest bringing the CPU back to 147MHz before writing to on-board flash. It is possible to damage some flash ICs by writing too slow or fast so this is rather important.

This application was tested on the MOD5270. It should work as is on any product based on the MCF5270/34 CPUs. It can also be modified to work on the MOD5282 but the speed calculations must be redone since the crystal and CPU frequency is different. The MCF5272 products can not have the CPU speeds reduced since there is no internal PLL or clock peripheral but 140mA can be saved by powering down the Ethernet.

- Larry
Attachments
main.cpp
Low Power Example for MCF5270/34 products
(7.8 KiB) Downloaded 571 times
Last edited by lgitlitz on Wed Nov 04, 2009 2:27 pm, edited 1 time in total.
Reason: Modified example, maximized SDRAM refresh before switching speed
v8dave
Posts: 333
Joined: Thu Dec 31, 2009 8:31 pm

Re: Reducing power on 5270/34 products

Post by v8dave »

Nice work. I was just going to post asking about how to do low power on the MOD5234 when I did a search and found this. As my app is batttery powered and not needed to be on full speed all the time, this will be perfect.

Thanks a lot. I am beginning to see the Netburner light now!! :o)

Dave...
User avatar
tod
Posts: 587
Joined: Sat Apr 26, 2008 8:27 am
Location: Southern California
Contact:

Re: Reducing power on 5270/34 products

Post by tod »

Terrific. Exactly what I was looking for. We often do low power projects and don't consider the NB, now that may change.
v8dave
Posts: 333
Joined: Thu Dec 31, 2009 8:31 pm

Re: Reducing power on 5270/34 products

Post by v8dave »

I get an error when trying to compile this under debug.

It reports DisablePHY(), EnablePHY() and StopEnet() as undefined.

Looking at the library files, the above functions Disable and Enabled are not included in the debug version but only in the release. Looking at the source code, there is no #defines preventing them from being included?

StopEnet() is not found anywhere?

Any clues on what do to other than doing a #define around the Ethernet calls when in debug mode?

EDIT: Actually, shutting down Ethernet in debug mode is probably not a good idea anyway!

Dave...
Post Reply