MAX78000: issues with external SPI RAM (aps6404l) in quad mode

[alessandro-montanari]

I'm using an external SPI RAM (aps6404l) connected to SPI0 and it works well when I use it in standard 4-wire SPI mode. I can read and write data fine. I am using the sync Master Transactions API.

However, when I enable Quad mode the write operation seems to work but the read operation hangs in the SDK functions.

I did a bit of debugging and it appears that the Master Done flag bit in the SPI0 INTFL register doesn't get set. This means that the function MXC_SPI_RevA1_MasterTransaction never returns since there is this loop while (!((req->spi)->intfl & MXC_F_SPI_REVA_INTFL_MST_DONE)) {}.
This is strange because if I inspect the request it seems that all the data has been read: rx_len is what I expect and the buffer seems to contain the data I expect.

I then noticed that if I try to read 75 bytes or less the Master Done flag gets set correctly but if I try to read more bytes it doesn't. This doesn't happen in 4-wire mode where I can read different buffer sizes just fine.

All of this happens using an SPI frequency of 24MHz, if I increase it to 50MHz I can only write data to the RAM but I cannot read anything, not even buffers smaller than 75 bytes. Again, in standard 4-wire mode, this is not an issue, I can use 50MHz and read/write just fine.

I'm a bit confused on what's going on, especially because it seems the transaction is completed but the flag is not set. And also, why it only works for buffers smaller than 75 bytes.

[Jake-Carter]

Hi @alessandro-montanari,

Are you using the APS6404 that's on-board the MAX78002EVKIT? If so, see the PR linked above. I've had some drivers written for it that have been living in the QSPI example project, but they've needed some cleanup for a while. I've just updated them in the PR to expose them universally.

Regarding the flag not being set - it's difficult to say exactly what this could be. I have some experience with a couple quirks in our SPI drivers I gained while writing the APS6404 drivers. At a high level our SPI API was not compatible and I had to rewrite a highly optimized "fastspi" implementation.

See this block in the QSPI read implementation. Essentially we have to issue two separate transactions to comply with the timing requirements of the APS6404 QSPI reads - one for the TX side and one for the RX side. We hold the SS line in between the two transactions so that the IC sees them as one. The previous SPI API was not fast enough to do this. You need less than about 12uS in the gap. The updated drivers should be functional, and they expose a simple aps6404_read/aps6404_write/aps6404_enter_quadmode interface. See the updated example.

Regarding the speed - I've only been able to communicate with the APS6404 reliably at 24Mhz. On some EVKITs I can get 30Mhz, but this seems to be an issue with the hardware layout and design of the board itself. Since we have exposed every pin with a jumper, the higher speeds seem to degrade due to layout and/or noise injection issues. The SPI0 pins also share connections to the TFT display on the kit, which further introduces some potential for impedance and interference issues. I've updated the BSP to disable the TFT on startup and forced the highest drive strength for the pins in the drivers. This helps significantly, but it still seems that a more optimized layout would be needed to get speeds up to the fullest capability of the SPI peripheral (60Mhz).