QSPI peripheral MCF52233 on Multiple Device

[keithtan]

Hi All,

As the subject above, I wish to know more on the QSPI peripheral MCF52233 ColdFire Chip.

1. Did anyone ever come into a multiple SPI slave with using different clock speed to communicate with different slave on this chip? It is feasible to perform this?

2. Should the chip reinitialize the QSPI peripheral every time when it perform a communication?

3. Is there any limitation in the chip hardware that restrict from having multiple speed in SPI Slave?

Hope can get some advice on these questions.

Thanks in advance.

Keith.

[TomE]

> Did anyone ever come into a multiple SPI slave with using different clock speed

> to communicate with different slave on this chip? It is feasible to perform this?

Haven't done that. You can have different delays after each "word" (normally 8 or 16 bits) if you need to slow the "average" speed down. What are you fast and slow clock rates?

If you have two very different peripherals you might consider "bit-banging" the slower one, or the lower data rate one.

I'd check to see that the "slow" device doesn't have problems when hit with a high-speed clock even when not selected. That might cause problems (or you may need to gate the clock with the chip-select).

Otherwise it looks like you should be able to change the baud prescaler as long as the QSPI is idle. You might want to change it to zero (and wait a bit) between changing it to a different value, as zero disables the device.

Tom

[keithtan]

Hi Tom,

Thanks for your reply,

This design is for 2 very different peripheral but I just hope to use the bus for both device. It is because of the specification in different device. One device supports up to 15Mhz and the communication speed is concerned thus will be setting this device to 15Mhz bus speed. Another device only supports up to 6Mhz bus speed. This results speed changing is required during board operation. Would large difference between device speed causing problem to the system?

After setting the baud prescaler baud rate to 0(disabled the SPI), is it required to reinitialize the SPI with the full configuration?(assume both device have the same SPI configuration but just different bus speed) or just set the baud prescaler to desired speed?

Keith.

[TomE]

> Would large difference between device speed causing problem to the system?

For that you have to analyse all the components in the system. First check that the devices aren't using the SPI clock for any other functions. It is possible to make devices that use the SPI clock to clock logic other than the SPI interface, and expect a continuous clock. Make sure you don't have one of these. I don't think this matters as "Figure 30-3. QSPI Clocking and Data Transfer Example" implies non-continuous clocking.

Secondly, what will happen to the "6MHz Device" if you feed it a 15MHz clock, but don't access it during this time? I suspect the Data Sheet wont answer this question. You may not be able to get a definitive answer that this is OK, in which case you can't do that. As I said before, you may need to add some logic to gate the clock to that chip so the clock is only driven when Chip Select is asserted. Make sure the "idle state" of the clock is the right one and the programming and logic doesn't allow any narrow clock glitches when turning it on and off. You may want to gate the clock with a spare GPIO pin if you can't guarantee the timing.

> After setting the baud prescaler baud rate to 0(disabled the SPI), is it required to

> reinitialize the SPI with the full configuration?

The easiest answer is to ask the hardware. Write some code to find out. Given that the QMR[BAUD] bits are a prescaler reload value, after writing zero you should wait long enough for the previous count to finish. I'd suggest waiting at least 1us before loading it with the new value.

Looking at the Reference Manual, the "Reset Value" of QMR[BAUD] is "4". So the chip must handle loading a different value as part of normal initialisation. So you shouldn't have to "change via zero" but I'd try it anyway.

Tom

[keithtan]

OK, Thanks for your help!