QuadSPI AHB memory-mapped read triggers non-stop, repeated, identical SFM transactions

cancel
Showing results for 
Search instead for 
Did you mean: 

QuadSPI AHB memory-mapped read triggers non-stop, repeated, identical SFM transactions

Jump to solution
668 Views
beat
Contributor II

I am attempting to setup the QuadSPI for AHB reading.  I have one single-banked external flash attached to Flash A (A1).  I am attempting to use SEQID 0 with the power-on reset values for LUT0 and LUT1 (this is the Read command 0x03).  I am able to write and read registers to and from the external device (different sequence IDs), so I have the LUT setup correctly.  Also, the IAR debugger is able to read external flash, and I can see the flash transactions occur on my logic analyzer when it does so (transactions are 8 bytes of data long, but will be longer if I change QSPI_BUF3CR[ADATSZ] to a larger value).  I am assuming those are merely AHB memory-mapped reads, but I don't know for certain.

My problem is that when my application attempts to read a byte, the hardware locks up, and on the logic analyzer, I see consecutive, repeated reads sent to the flash.  Each read has the same address, which is correct.

Has anyone seen this?  Am I missing some part of the QuadSPI module setup?  Thanks.

Some relevant register values:

QSPI_BFGENCR[SEQID]0
QSPI_BUFxIND0
QSPI_LUT00x08180403
QSPI_LUT10x24001C08
QSPI_SFxxAD0x21000000
QSPI_BUFxCR[ADATSZ]0
QSPI_BUF3CR[ALLMST]1
QSPI_RBCR[RXBRD]1
Tags (4)
0 Kudos
1 Solution
275 Views
beat
Contributor II

Sorry to bump an old thread, but this problem was difficult to track down.

I experienced intermittent problems like this with odd behavior on the bus. In the end, I think it was all caused because I was testing my driver which read and wrote to external flash while reading from the external flash at the same time with the debugger. Don't do that. My previous post was wrong about the cause of this problem. The cause was inspecting external memory with the debugger while testing an external memory driver (which writes or erases) at the same time. I don't exactly know why this happens; I suspect the debugger gets into a confused state.

It's been a while now, but it's possible this only happens when the driver writes to memory addresses that the debugger is polling. Not 100% sure about that part, though. If you are writing to external flash, best not to use a debugger for memory inspection at the same time.

View solution in original post

0 Kudos
4 Replies
276 Views
beat
Contributor II

Sorry to bump an old thread, but this problem was difficult to track down.

I experienced intermittent problems like this with odd behavior on the bus. In the end, I think it was all caused because I was testing my driver which read and wrote to external flash while reading from the external flash at the same time with the debugger. Don't do that. My previous post was wrong about the cause of this problem. The cause was inspecting external memory with the debugger while testing an external memory driver (which writes or erases) at the same time. I don't exactly know why this happens; I suspect the debugger gets into a confused state.

It's been a while now, but it's possible this only happens when the driver writes to memory addresses that the debugger is polling. Not 100% sure about that part, though. If you are writing to external flash, best not to use a debugger for memory inspection at the same time.

View solution in original post

0 Kudos
275 Views
lydia_ziegler
NXP Employee
NXP Employee

Hi Russ,

What hardware are you using in this case?  Is it a FSL board like the TWR?  Who is the QSPI vendor and what is the part number?

Thanks,

Lydia

0 Kudos
275 Views
lydia_ziegler
NXP Employee
NXP Employee

Adding a note here as well. 

Per our discussion Russ noted that he, "switched to QOR read which is used in the example (instead of QIOR which I was using), and the problem seems to have vanished for now."


Thanks for the update, Russ!

0 Kudos
275 Views
beat
Contributor II

I witness some glitching when using quad pads to send the address to the external device.  I switched to using the command (QOR) which only reads in quad mode (sending the address in single pad mode).  Now the QuadSPI device is behaving reasonably, and the problem behavior is not occurring.

0 Kudos