2019-01-02 04:35 PM
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:
The problem:
Diagnostics:
Work Arounds:
Analysis:
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
2019-01-03 12:36 AM
I don't use the 'F7 nor the QSPI module, but some random, probably not helpful, thoughts:
JW
2019-01-04 09:47 AM
Hi JW,
Thanks for the response. There are some really good ideas in your list. As a follow up, we've implemented the 'read chip status register' work around and downloaded 40GB worth of log files (ran all night) with out a hiccup.
Point by point..,.
Thanks again for the ideas. Considering that this only happens on reads and not writes, reads are rare, service related events and not a customer facing issue as writes would be. Plus now we have some confidence in the work around.
I'll keep working on this on the side just to see if I can further identify where it's coming from. The biggest clue right now is that the main difference from the memory read to the status register read is the lack of an address. That kind of points to the address register as the potential source of the issue.
Kind regards
Mike Nelson
2019-01-21 07:30 AM
Hello @Community member ,
Thanks for sharing these details about issues you are facing and workarounds you applied.
For your information, and for other members who may face issues with QSPI on Cortex-M7 devices, there are 2 things that should be considered:
Regarding the first possible reason: some speculative read accesses may cause high latency or system errors when performed on external memories like SDRAM or Quad-SPI. This is Cortex-M7 issue and the workaround is to properly configure MPU.
You find more "Special recommendations for Cortex®-M7 (STM32F7 Series)" in a dedicated section with this title in AN4861 (https://www.st.com/resource/en/application_note/dm00287603.pdf).
You have also a dedicated application note for QSPI (AN4760) entitled "Quad-SPI (QSPI) interface on STM32 microcontrollers". It is available from https://www.st.com/resource/en/application_note/dm00227538.pdf.
Regarding the second possible root cause: Where possible, Arm recommends that you use the MPU to change the attributes on any Write-Through memory to Write-Back memory. If this is not possible, it might be necessary to disable the cache for sections of code that access Write-Through memory.
Hope this bring some help.
-Amel
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2019-01-23 01:00 PM
Hi Amel,
Thanks for the pointers. As I read back through my original post, it's definitely not as clear as it seemed when I wrote it. A summary of the problem would be:
An EEPROM read restarts without an explicit FW write to the QSPI block registers.
or
A phantom write strobe to the QSPI block registers appears to restart an EEPROM read.
That said, I don't know that the Data Corruption errata (#1259864) is a close match. We're not seeing corruption in the read data, but that an unexpected EEPROM read happens and we can't account for its origin. The EEPROM read is a side effect of something else gone wrong.
We're using the default MPU settings for QSPI register space. It is device, so it shouldn't have caching turned on. JW mentioned accesses to the QSPI memory mapped region. We're not using memory mapped mode, but I've not tried to trap wild accesses to that area to see if that's what's launching the extraneous read.
Thanks for the QSPI application note. I didn't have that one and I'll look through it. In general though we don't have any cached access to the QSPI so I don't know if it's applicable.
Thanks again
Mike Nelson
2019-02-01 10:59 AM
Hi Mike,
The memory mapped region is Normal memory type in the default memory map. That means even if you don’t actually access it, it could be prefetched speculatively by the CPU. Setting the memory mapped region to no access through the MPU will not generate any faults in this case, but it will prevent the speculative accesses. So bear in mind, even if you don’t see actual faults happening, making the memory mapped region no-access may actually fix the problem.
2019-02-07 08:12 AM
Hi Chead1...,
I can't begin to express enough thanks for your comments.
I've worked with ARM and ST for quite a few years and I'll have to admit your note put a new wrinkle in my forehead. When JW first mentioned this I tried blocking the memory mapped region with the MPU, but did it as a diagnostic for wild FW writes and not as a solution. Then when it didn't cause a memory fault I discarded the region settings. I should have paid better attention, but I did not know that the MPU would block a speculative fetch without causing a fault.
So this appears to solve the problem: turning off access to the QSPI memory mapped region stops the spurious QSPI reads. I've implemented this as a root cause solution and removed the other work around (enable/disable the QSPI block) we were using.
This seems like a QSPI block bug to me. If we're not configured to use memory mapped mode, I don't think memory mapped region accesses, speculative least of all, should initiate a QSPI transaction. At a minimum, it should be added to the QSPI Application Note to warn others of the side effects.
Thanks again to all for your help. I hope at some point to be able to de-wrinkle my forehead over this one. :):)
Kind regards
Mike
2019-02-08 12:38 AM
Hello @Community member ,
I confirm that QSPI application note will be updated in order to add recommendations on how to properly configure MPU.
-Amel
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2019-02-08 07:13 AM
Thanks Amel!!
Mike