Question
Help with odd STM32F765BI QSPI behavior? We're seeing what looks like an extra or spurious read transaction.
We're seeing what looks like an extra or spurious read from the QSPI block on our STM32F765BI. As yet, we're not able to pinpoint the cause and could use some ideas of where else to look. Sorry that this gets a bit long.
Background:
- We're using the QSPI interface in Quad mode with a 1Gb Micron MT25QL01GB part.
- We're using HAL with our own EEPROM and NVM code modules to create storage for configuration data and log files.
- There's no OS, but we've written the NVM and EEPROM layers to be non-blocking during a block erase.
- Reads are always blocking.
- Each foreground loop we check that the NVM, EEPROM, HAL_QSPI, code and QSPI block are all coherent: either idle and OK or Busy with an erase.
- Reads and writes are from a few bytes to < 16kB.
- We're using the indirect access mode, not interrupt or DMA.
- The log files are by far the bulk of our NVM accesses. The sensor log reads/writes 1280 bytes at a time and has 100MB of dedicated space.
- Writes have never been a problem.
- About 1:10,000,000 reads to the sensor log will cause a problem.
The problem:
- All requested read transfers complete successfully and we don't see any data corruption or issues.
- After the read completes the QSPI block bits show: not BUSY, TCF is high, no errors and 0 data in the FIFO (FLEVEL = 0).
- About 1:10M reads when we come back around in the foreground, the NVM, EEPROM, and HAL_QSPI code status is idle and OK, but the QSPI block indicates it is busy with a read. The FIFO is full and the read is suspended waiting for room in the FIFO.
Diagnostics:
- We didn't see anything in the Errata that looked like this. Close, but not exactly.
- Using the debugger we can consume data from the FIFO (each display update while viewing the QSPI registers consumes data from the FIFO). Eventually the FLEVEL count counts down 20 -> 1C -> 18 ... 8 -> 4 -> 0. At 0 bytes in the FIFO the TCF bit goes high and the BUSY bit clears.
- We don't clear out the QSPI registers after a read. It seems to be repeating the last read - which already finished successfully.
- We created a MPU region for the QSPI registers and enabled/disabled it as needed to access the QSPI block. It never hit and we still see the extra read. The QSPI block is already full and blocked when we come back in to NVM.
- ARM Trace doesn't show any function calls that would access the QSPI block from the previous successful completion to detecting that the QSPI block is in the middle of a read.
- We do have some DMA running, but it doesn't look like we're getting hosed down with a wild DMA. All of the configuration, size, read command, etc. register settings and data appear to be just as the last read.
Work Arounds:
- We're able to prevent the issue by one of two things.
- First is to disable/enable the QSPI block only when we're using it. We essentially substituted the MPU enable/disable for setting/clearing the QSPI enable bit.
- Second is to clear out the last read register settings. By issuing a 1-byte read to the chip status register we don't see the problem anymore.
- The problems and work arounds replicate on multiple boards.
Analysis:
- All appearances, it's like the QSPI block thinks it's getting a write strobe and then it repeats the last read.
- We don't think it's coming from a wild FW or DMA access, but....
- In theory, we think the chip SR read should also be susceptible to a spurious read and while it won't block on the FIFO full, should still leave an extra byte in the FIFO. We'd catch and flag this as an error, but all seems happy.
Our best guess at this time is that a specific set of register conditions makes the QSPI block susceptible to a glitch on the write line. We're not stuck, but would like to root cause the problem. We'd appreciate other ideas and techniques that can help us further identify the problem.
Thanks!!
Mike Nelson