changing the qspi mode mcf52259

Showing results for 
Search instead for 
Did you mean: 

changing the qspi mode mcf52259

Contributor II

From the data sheet for the mcf52259:

Changing CPOL and CPHA during operation is not supported.


Does anyone know anymore about this?  This is kind of surprising for such a capable chip.  Requiring that all SPI devices are the same mode seems silly.

Has anyone been able to work around this?  I can do it fine when I single step through the code, but when I just let it run, it goes all afoul.

BTW I'm using CW10.4 if that matters.



Labels (1)
0 Kudos
1 Reply

Specialist I

That's interesting. That warning doesn't appear in the MCF5329 that we use.

Searching Freescale's site for "CPHA may be modified only once" gets matches on the following manuals only:

MCF52235RM, MCF52223RM, MCF52110RM, MCF52211RM, MCF52259RM, MCF5213RM.

> Does anyone know anymore about this?

The FULL quote from the Reference Manual is:

Because of the implementation of the QSPI module on this device, CPOL

and CPHA may be modified only once, typically during software

initialization. Changing CPOL and CPHA during operation is not


Not surprisingly, searching for "Because of the implementation of the QSPI module on this device" shows up exactly the same manuals. So those chapters are probably cut-and-paste because the silicon modules have also been cut-and-pasted to make that range of chips.

You have to believe them. Flipping those bits must do something "nasty" inside the chips, causing some internal clock glitches or something.

The Manual states that setting QMR[BAUD] to zero disables the QSPI. I'd suggest you try writing the QMR[BAUD] bits to zero, waiting for a while, changing CPOL and CPHA and then setting QMR[BAUD] bits again.

But note that if that was a workaround for this restriction then I'd expect Freescale would have mentioned it, So I'd expect it might still go wrong. But worth a try. Watch out that the problem inside the chip might be temperature/voltage/production/timing sensitive (these things usually are) so a workaround that works on the bench for one chip once may not work reliably on all 10,000 units you've sold world-wide.

As a designer I couldn't guarantee something like that would work unless I got confirmation from Freescale through my local sales rep. That's the only way to get this information - you're very unlikely to get that through this forum.

Freescale have other modules that don't work all that well. For instance he LCDC (LCD Controller) they have in some chips has to be disabled before some essential registers can be changed. But it doesn't have a "disable bit". The only way to stop it is to stop the clock to that module. If you do that WHILE it is in the middle of a DMA Transfer, then you stop it in the middle of that bus access and it never lets go! That results in a total lockup of the whole chip, The only way out of this is power cycle or Watchdog. The only way around this problem is to sit in a tight loop with interrupts disabled waiting for the next Vertical Retrace, then wait a bit, THEN stop it:

Re: MCF5329: Disabling LCDC can crash the CPU

Manuals are assembled from the versions of the module chapters that were current when the manual was assembled. Sometimes the later manuals are more up to date for the earlier chips, but you have to do your own "archaeology" on this. It is possible that the QSPI modules in chips other than those with that warning are affected, but the manuals didn't get updated.

There are some nasty traps in programming the ubiquitous PIT modules. This is compounded by the Header files they supply which don't allow essential byte-writes to one of the registers. Search for "Bear PIT" if you're interested.

> Has anyone been able to work around this?

External inverters in the clock line for the chips that are reversed would be an obvious solution.

You can always dynamically reprogram the QSPI pins to GPIO and bit-bang the chips that are the "wrong way around" while switching back to using the QSPI for the other ones.


0 Kudos