PLL on MOD5213

[stockel]

It appears the MOD5213 is setup up with an external crystal oscillator feeding the PLL with a 3.686 MHz signal and the PLL is set up for x18 to generate the 66.355 MHz system clock. Has anyone used the PLL to set the MOD5213 for lower clock speeds? Any tricks to setting up the PLL? I haven't found any application notes on this.

Thanks in advance for any help.

Regards, Jim

[lgitlitz]

I suspect you are looking to save some power... We have a low power application note in the works but it is temporarily hold. I have done quite a bit of experimenting with the MOD5213 clocks and low power modes. Here are some of the main software/hardware points I was planning on putting in the future application note.

First thing I would do for power sensitive applications on the MOD5213 is make sure your hardware is efficient. You should be using an efficient 3.3 switching supply and not the on-board 5V regulator. You should set all unused pins to be GPIO inputs and tie them to 3.3V. You can also remove the regulator and the two voltage divider resistors to save about 10mA. The voltage divider resistors used for the on-board regulator are R1 and R2 located right next to the regulator (U2), all three components are really easy to remove. A change has been made in these resistor values for future builds to reduce their current draw but it is still wasted current if you are not using the regulator.

Now for the software. There are many options for power savings on this processor. You should read the Power Management and Clock chapters of the MCF5213RM to see all the options available to you.

1)
Reducing clock speed and disabling the PLL has a significant effect on the power consumed by this processor. The following code only focuses on the actual changing on the PLL can clock settings. You will also want to adjust the timing of any peripherals that are clock speed dependent. One important peripheral to adjust is the Coldfire Flash Module timing for writing to Flash. The Flash memory in the processor can be physically damaged if the timing parameters are wrong. Another peripheral that should be changed is the Programmable Interrupt Timer 0 (sim.pit[0]) settings to be 50ms, this is the timer that triggers system ticks for the OS. Any other communication peripheral will need to be changed for the proper baud rates, this includes UARTs, I2C, QSPI, CAN... ext.

// To reduce clock speed and disable PLL
sim.clock.lpdr = 0xF; // Clock low-power prescaler to slowest clock speed
sim.clock.syncr = 0x7003; // Disconnect PLL
sim.clock.syncr = 0x0702; // Shut down PLL and decrease system speed with prescaller

// To bring clock speed back to default 66MHz
sim.clock.lpdr = 0x00; // Clock prescaler to default clock speed
sim.clock.syncr = 0x7107; // Connect PLL and increase system clock speed RFD+1 to avoid overclock
while( ( sim.clock.synsr & 0x8 ) != 0x8); // Wait for PLL to lock at set multiplier
sim.clock.syncr = 0x7007; // Now it is safe to increase speed to full 66MHz


2)
The other major area you will have software is the Low Power Peripheral. This is where you can disable the clocks to various peripherals and even disable the clock to the CPU(stop mode). The code attaching to this post will make the CPU enter STOP mode which disables all clocks and processing. The only way to wake from stop mode is with a level sensitive IRQ interrupt. In the latest release there are new functions in the real time clock driver (rtc.cpp) that allow for configuring the alarm and timer functions of the RTC. The RTC alarm will then trigger an IRQ after the time specified which can be used to wake the CPU from stop mode. The functions are only for the newer NXP RTC and a jumper wire may be required from the RTC IRQ pin to the MOD5213 IRQ. You may want to use the dose or wait modes as they allow for other peripherals to wake the processor.

3)
Use the OS functions over polling, especially when using peripheral. When your application uses OS functions to wait for an event, the idle loop will be reached while waiting for an interrupt to occur. While in the idle task a tight loop of nop instructions will be run from the CPU cache. If polling is used instead, the code will likely be run from Flash memory. Polling peripherals may also consume addition current. The attached example will wait for an event on UART0 at the initial getchar() function. When using #include <serialirq.h> the current draw in the getchar() is about 72.5mA, when the UART driver is changed to #include <serialpoll.h> the current goes up to about 83.5mA... about 15% higher current draw.

4)
You can disable the pst/ddata signals for the BDM. This is a bit tricky since you can only write to the CSR register with a special assembly instruction. Look at the WRITE_CSR function in the posted example.

-Larry

[stockel]

Wow, thanks Larry for the detailed reply. My initial requirement is to change the clock speed to get more flexibility in generating frequencies with the DMA timers, but we are definitely trying to reduce power as well, so your other suggestions will be very helpful.

Thanks a bunch!

Jim

[tmcneill]

I use a program called CFInit to get the PWM values.

http://www.microapl.co.uk/CFInit/cfinit_main.html

It gives you code to set up almost any function on the coldfire.