MC9S08QE128 - Fast Startup, Low Power 4MHz Clock Source

[ajacks504]

Hello,

A brief description of my application, the device communicates solely on the SPI bus (it is slave), wakes when slave selected (SS) via IRQ, process the SPI task given, then sleeps.  The SPI command comes within 100uS of slave select, the SPI SCK clock from the master is 1MHz.  The main issue I have is that I need to sleep in the lowest possible power mode while still being able to wake and have the bus clock running at, at least 4MHz (4 x 1MHz_SPI_SCK).  I need to wake and have the bus clock running at 4MHz within at least 120us.  The wakeup time is what I am most concerned with.

I need to wake up fairly frequently, the IRQ interrupt comes fairly frequently, about once a second.  I believe that I need to keep the oscillator (or xtal) running because the startup time of a 4MHz external crystal is ~5ms (datasheet pg. 21).  If I used the ICS clock source, its startup is 100us max (datasheet pg. 22), this may be fast enough.  The internal reference is ~31-39kHz, so I assume that I will have to step up the clock to at least 4MHz with the FLL.  The FLL acquisition time is 1ms (datasheet pg. 23), so this means that if I use the ICS, the max startup time from power up to 4Mhz would be 100us+1ms = 1100us, is this correct?

Any ideas on what the lowest power way to do this is?  So far, the only option that I can think of is to either use the FLL and leave the output enabled at 4MHz while I am in STOP2 or use an external 4Mhz crystal.

Any ideas?

Thanks,
Adam

[bigmac]

Hello Adam,

For a SPI clock frequency of 1MHz, the only requirement for a slave device would appear to be that the bus frequency should be a minimum of 4MHz.  If using FEI mode, I might assume that the FLL does not need to be locked to achieve correct operation of the SPI module, provided it is more than the minimum frequency limit.

Further, the specified maximum DCO lock period is likely to be a worst case value, based on power up conditions.  I would suspect that the period may be substantially less for a wakeup interval of one second, especially since I assume the DCO filter would retain the value that existed one second earlier.

Perhaps some simple tests could verify these suspicions.

It probably doesn't help with your current project, but when there are slowly responding slave devices, it is useful to provide a single "acknowledge" line back to the master for handshake purposes, rather than using fixed timing delays.  This way, each slave device can determine when it is ready to receive or send data.

Regards,

Mac

[ajacks504]

Mac,

Thanks for the reply.  Yes, its possible that the new FLL clock would be up sooner than the max acquisition.  There is absolutely no chance that my boss would go for it if the operation we require is not guaranteed by the manufacturer and I understand that.  Its also likely that you are correct that the SPI transaction would be RX'd even as the FLL was acquiring, asssuming that the frequency would first overshoot and be greater than f_bus/4.

I've looked recently and Linear Technologies has some great silicon oscillators that have <100us startup times and really low current, it might be possbile to use the module enable to enable the oscillator, then write a bit out that would keep the oscillator on after the module enable expired until the uC is done and ready to sleep.

Yes, I failed to mention it, but we do use a "module status" line on the slave module.  The real issue is that the SPI recieve register on the S12 / S08 uC are not purely dependent on SCK to get data into the SPI data registers.  They are not "dumb" shift registers like many PIC parts, this has advantages and disadvantages

Thanks for your reply.

Adam

[bigmac]

Hello Adam,

I don't believe that I was suggesting any departure from the limits imposed within the datasheet.  Let's assume that your DRS setting would give a DCO output range within the limits 16-20 MHz, independent of any FLL lock condition.  With a FDIV division of 2, the bus frequency must lie within the limits 4-5 MHz.

For a SPI slave, the operation is determined by the incoming clock from the master, and is not influenced by the local bus frequency, other than the bus frequency must be greater than four times the incoming SPI clock frequency.  For a 1 MHz SPI clock, this condition would be met for any bus frequency within the above limits, and quite independent of any FLL lock status.

Keep in mind that a FLL operates quite differently from a PLL.  When the FLL is "locked", this means only that the DCO frequency (and bus frequency) will currently lie within certain limits.  However the frequency will still be subject to substantial short term variation, as evidenced by the jitter specification.

Using the internal oscillator, you could eliminate the startup time (100us max) by running the oscillator in stop mode, with the penality of an additional 70uA current draw.  There would appear to be little benefit in using stop2 mode, over stop3.

Regards,

Mac

[ajacks504]

Hi Mac,

Excellent!  This is just the info that I needed.  So, let me see if i understand you perfectly....

I need to wake from sleep with ~120us of slave select (SS) in order to RX a 1MHz SPI slave CMD.  To RX a command a that speed, f_bus must be > 4Mhz.  BUSCLK = ICSOUT / 2^n, so if n=0, ICSOUT min is 8MHz.

To meet the above conditions and be low power, I could use an external 32.768k watch crystal, leave it on in STOP and draw ~70uA, upon IRQ (SS), wakeup and enable the FLL to run at say, 16-20MHz.  Even though the FLL freqency would not be "aquired" (guarnteed within limits), it would be well above FBUS_min to RX my 1MHz SPI slave message, from this point, I could wait until the FLL aquired to do my timing critical tasks and I would have the message in the SPI data register?

I guess the only real question is how long it takes for the FLL output to be released to DCO out from enable?  The DCO's have to have some startup time, right?  Please excuse me, I dont really understand the operation of a FLL.

Thanks again for the info

I'm looking at the reference manual figures 11-2 and 1-2, pages 206 and 24 respectively.


Message Edited by ajacks504 on 2008-07-24 09:35 PM

[bigmac]

Hello Adam,

---

ajacks504 wrote:

To meet the above conditions and be low power, I could use an external 32.768k watch crystal, leave it on in STOP and draw ~70uA, upon IRQ (SS), wakeup and enable the FLL to run at say, 16-20MHz. 

I had previously thought that you would be using the internal oscillator.  However, the external reference can also remain enabled in stop mode (ICSC2_EREFSTEN = 1).  In this case, the additional current draw penalty would seem to be typically 0.5 uA for a 32kHz crystal.  This is substantially less than for the internal oscillator.

You would select FEE mode for the ICS, possibly with a bus frequency of 4MHz (but could be higher if required).  Then enter stop mode with the EREFSTEN bit set, and the crystal oscillator should continue to run.

---

I need to wake from sleep with ~120us of slave select (SS) in order to RX a 1MHz SPI slave CMD.  To RX a command a that speed, f_bus must be > 4Mhz.

---

The SS signal would go low to wakeup the MCU, but then must remain low for the whole period of each SPI byte transfer.  I trust this is the situation with the master.  Depending on the CPHA setting in use for the SPI module, the SS signal may need to be raised between two successive bytes.  I presume you have connected the SS signal to two pins, the IRQ pin and the SS input pin.

Regards,

Mac

[ajacks504]

Hi Mac,

Thanks again for the reply.

Yes, I was thinking that an external 32.768k crystal would be the way to go as the frequency would be more precise (not that i really need it) and the added benefit of lower power.  We operate off batteries where I work and getting the quiescent down is kind of like a competition between engineers

I haven't really given you all of the details.  I'm using the uC in a board that interfaces with a digital compass, its sole purpose in life is to read the compass then send its heading back over the SPI bus.  There are a few tasks involved to read the compass, enable a switching PS, check the status of a comparator to see then the PS has fully risen, then request a compass heading.  When all of this is done, the slave signals for the value to be read from the master by hitting a "module status" line.

Yes, the SS line is bracketed for SPI transactions.

Next thing to do is test it.  The DCO's in the FLL must have some startup time associated to them, just hope that its short!

Adam

[JimDon]

For what it is worth, the internal low power oscillator draws less current that the external xtal.
If accuracy is not a concern and power is that is a better choice.