MCF52259 QSPI / Chip select issue

[FridgeFreezer]

I'm currently trying to get the QSPI module on the MCF52259 (EVB52259 eval board) working. While the data transfer part of it seems to work OK, the chip select lines (CS0, CS2, CS3) are not behaving as they should.

I'm using CodeWarrior 7.2 and the QSPI init & example code from the Freescale examples (QSPIinit, qspi_spif, etc.).

There are two problems I'm seeing:

The first is that between every byte transfered, the CS line goes back to its idle state - due to the chip we're trying to talk to, this resets the chip's Rx buffer and hence the transer fails. I have MCF_QSPI_QDR_CONT set in the command data of every command (again, using a copy of the example routine qspi_spif() but with different data in the packet) and have tried the full range of delays in MCF_QSPI_QDLYR for QCD and DTL. If I set the module for 16-bit transfers the CS line seems to still blip every 8 bytes.

The second problem is that no matter what I set in the command data, the chip select lines do not work as they should:

If I set MCF_QSPI_QWR_CSIV to 0 in QWR, the lines are low all the time even if I write different values to MCF_QSPI_QDR_CS - I have tried everything from 0x00 to 0x0F and none of them make the CS line move.

If I set MCF_QSPI_QWR_CSIV to 1 in QWR, the lines toggle to active low when a transfer is in progress, but they do so regardless of what is in MCF_QSPI_QDR_CS - I have tried everything from 0x00 to 0x0F and whatever I write, all of the CS lines go low during a transfer and then return high. They also blip high between bytes as mentioned above, which corrupts the transfer.

The changes I've made to the original example code are minimal:

I call QSPIInit(QSPI_BAUD, QSPI_CLKATTRIB, QSPI_BITS, QSPI_CLKDLY, QSPI_DLYAFT, QSPI_CSPOL) with my own values, typically QSPIInit(200, 0, 8, 1, 1, 1);

I have modified the qspi_spif() routine from qspi_example.c to populate the test data with my own data by removing the incremental write (MyBuf->pu16TxData[j] = j) and writing directly in to locations MyBuf->pu16TxData[0]...[16]. The rest of the routine, and the ISR which runs the transfer, are completely unchanged.

I don't know if this is a problem with the way I'm programming this (as I said, I'm using the example QSPI routines with minimal mods) or if there is some bug in the example code that means my mods can never work.

Loading M52259EVB_qspi.mcp from the 52259EVB example code pack will show you all the routines I'm using.

[aersek]

I have found QSPI on MCF5282 wery useful for transfers shorter transfers. I sucssesfuly communicate with 4 SPI devices, each connected to diferent CS line. All device CS lines should have negative polarity logic. Using QSPI I can transfer up to 32 bytes (16 transfers of 16 bits). My configuration is QMR = 0x8318, QDLYR = 0x0101, QIR = 0x9000, speed 1.5MHz. For transfer of 4 bytes to CS0 you need to run this code:

int rec1, rec2;

QAR = 0;                // set address to transmit ram

QDR = 0x1234;    // send 0x1234

QDR = 0x5678;   // send 0x5678

QAR = 0x20;        // set address to command ram

QDR = 0xCE00;  // send 16 bits, keep CS asserted, CS0

QDR = 0x4E00;  //send 16 bits, deassert CS transfer, CS0

QWR = 0x1100;  // CS inactive high, start quenue 0, end quenue 1

QDLYR |= 0x8000;  // start QSPI transfer

while ( QDLYR & 0x8000);   // wait to transfer complete

QAR = 0x10;   // set address to receive ram

rec1 = QDR;   // read received data

rec2 = QDR;

Exactly these code isn't tested, I'm writing in assembler, but this is logic which I use. This code should assert CS0, send 4 bytes (0x12, 0x34, 0x56, 0x78) and then deassert CS0.

Regards

Andrija Ersek

[FridgeFreezer]

Cheers guys,

Partly as an experiment and partly for simplicity/expediency I am going to try these much simpler bit-banging routines from Maxim's website:

http://www.maxim-ic.com/app-notes/index.mvp/id/4184

Some may find them useful.

Frankly all this junk with data, command, address buffers and stuff not-quite-working makes me very wary of relying on the inbuilt QSPI, even though it is less than ideal to have to bit-bang it. I'm thinking if the Maxim routines work I will modify them so the main loop is in a DMA timer interrupt.

[mjbcswitzerland]

Hi

In many cases it is simpler to control the CS lines as GPIO outputs, especially when the code needs to wait for transmissions to complete. Using the CLEAR and SET port commands (CLEAR before starting transmission and SET after transmission has successfully terminated) usually results in far less configuration code that when setting up automatic CS control.

In all of my own uses of the QSPI (eg. SPI FLASH file system, SD card FAT file systems, controlling external SPI peripherals (most with the requirement of stable CS during messages as in your case) there has been no obvious benefit of the automatic control and this also explains why I can't otherwise give any insight into its actual setup and pitfalls along the way, since it was simpler an no less efficient to just toggle ports....

Regards

Mark

[FridgeFreezer]

Thanks Mark - that does seem to work but it seems like a bit of a poor way to have to do things when the QSPI module is supposed to handle all this by itself kinda seems like they have tried to be too clever and ended up with something that doesn't work at all.

[mjbcswitzerland]

Hi

I can't comment on the limitations of the automatic support since I didn't find a use until now where there were any benefits - although there will certainly be some cases where someone will be pleased to have the capability. I just realised that the amount of instructions that were required to set-up the simple case (clearing at the start and setting upon completion of all data Tx and Rx) was many times greater than simple  port clear and set commands. In my cases the code always has to wait before the last data bit was clocked in anyway so this could also simply do the port set at the correct time anyway.

Looking at it in a more possive way; if there is an easier way to do it then why not do so - the simpler solution will often also be the most reliable one too...

Regards

Mark