STM32F7 + QSPI (QUADSPI): Sporadic failure with memory-mapped flash memory. Disabling timeout does not help.

[auraner]

Hi everyone,

We have an issue when using QUADSPI (memory-mapped) on a STM32F7 microcontroller. The controller sporadically runs into a watchdog reset. Investigation showed that the crash always occurs during a LDM instruction from the memory-mapped flash. When disabling the watchdog, the program execution can only be stopped in an interrupt and a stop in main code execution is no longer possible. Most of the peripheral registers can no longer be read either.

We are aware of the issue stated in the errata sheet:

2.4.3 Memory-mapped read operations may fail when timeout counter is enabled

The proposed workaround is as follow:

Disable the timeout counter. To raise the chip select, perform an abort at the end of each memory-mapped read operation.

The timeout counter (TCEN bit in CR register) is disabled, but the issue still occurs. What we do not know is how to implement the second part of the workaround: "To raise the chip select, perform an abort at the end of each memory-mapped read operation."

Does anyone has an idea on how to implement this workaround?

We are also aware of this thread, where the explained behavior coheres with our findings.

Already many thanks!

UPDATE (20-01-15):

Since we do not care about power consumption, the chip select does not need to be raised after the read operations and therefore the disabling of the timeout counter should be enough as a workaround.

Do you have any ideas why the issue still occurs, although the timeout counter is disabled?

Our setup:

• STM32F767NIH6
• J-Link Debugger (Segger)
• IAR Embedded Workbench 8.32.3
• Flash Winbond W25M512JVFIQ used on memory addresses 0x9000000 - 0x90FFFFFF

[JYeh.9]

Hi,

Not 100% familiar with this issue, but is the abort action mentioned related to the HAL_QSPI_Abort API?

[auraner]

Thanks for the answer. As far as I understand now, the raising of CS after read operations is to lower power consumption of the flash and not a crucial step of the workaround. Since, we do not care about power consumption, this additional step should not be necessary.

[Tesla DeLorean]

Seem to recall there being a time-out setting on the interface. Will observe that the H7 has an issue at the end of the memory space, within 32 bytes, as I recall.

Seen the core stall indefinitely

If you have specific concerns you should take them up directly with ST, via your local sales office, and your FAE / support engineer.

[auraner]

Thanks for the answer. As described in the errata sheet, disabling the timeout should solve the issue, but it does not in our case. Could you elaborate the issue at the end of the memory space?

We are in contact with ST, but the communication speed is rather slow and there is much pressure on the project.

[auraner]

We received a working solution from ST support team:

"

Based on description of the issue it seems it is famous combination of <7+QSPI+MPU.

The M7 core can do a speculative reads to memories.

Unfortunately it can also read the area of QSPI where is no memory. Result is that the read from this area is not possible to finish. Probably interrupt routine is in FLASH so this part works. But reading in main loop will no finish.

So the basic need is to configuration MPU on M7 core.

Solution

For the areas which are not used, the MPU must be configured to not access this sections.

Recommended configuration is to set one MPU section like this:

Start address 0x0

Size 4GB

Disable sub section: 0x87 (this will exclude the core registers and periphery registers and RAM+FLASH)

Acdcess: NOT ACCESSIBLE

Cachable: NOT CACHABLE

Buffereble: NOT BUFFERABLE

Sharable: NOT SHARABLE

Then configure the one the QSPI area for access which you like.

"

[HMcKi]

Hi Auraner,

I have the same issue with STM32F765 + W25Q128JV in a dual QSPI configuration. With memory mapping (XIP) enabled, we get intermittent crashing under load. The memory mapping has no timeouts enabled. The crash quits the debugger and crashes the micro so has taken me a long time to track this down. The issue seems more prominent with I-Cache & D-Cache enabled but can be generated either way under load. Could you please share a little more information around the solution provided? Perhaps a screenshot in cubemx if thats what you are using?

Thanks.