Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
DISCO_F746NG QSPI WriteEnable might Fail on IAR8 #10049
Following https://jira.arm.com/browse/IOTSTOR-798 tickect
When running storage tests on DISCO_F746NG with IAR8 it fails on test:
Same board and test pass ok on IAR7 , as well as on GCC_ARM and ARM.
The test fails in this line :
When drilling down the failure is on sending write_enable to QSPI Flash, which eventually fails on timeout:
Data can not be written afterward to the device… until reset.
The test uses kvstore file system to add key/value pairs which hold the values:
For some strange reason, the combination of “name_o” followed by “name_p” causes the bug.
Issue request type
referenced this issue
Mar 14, 2019
There is also something related to the toolchain. Does someone knowing IAR can see what can be the issue ?
Regarding optimizations, I made a test in develop.json file. We do not see the problem if we remove optimizations on C++ parts : (-On option instead of -Oh)
I've noticed there's a known issue for this device in IAR:
@VVESTM - please note the problem is reproduced on my env using: IAR ELF Linker V126.96.36.199/W32 for ARM .
And with a bit of code variation, reproduced the problem, this time when trying to set "name_b"
Although the STM32F7 is vulnerable to cache issues that other boards don't see, I don't believe there's any direct reason for this interface to be vulnerable. It's not being used as a bus-mastering interface like Ethernet, it just has a FIFO you access as programmed memory/mapped I/O, right? Should be no more problematic than the UART. (On the other hand #9934 is quite likely a cache issue).
So the optimisation and cache effects smell to me like a timing issue - maybe you're just slowing it down.
Alternatively, it could be that the cache change is a red-herring, and that it's just the act of inserting the call that moves code around again. :/
It's possible there's a compiler bug, or some code triggering undefined behaviour only in this compiler, but we'd need to pin down a bit closer what's actually going wrong.
There must be one initial transfer that times out - for that transfer we'd want to see how the peripheral had been programmed. Did we program incorrect values? If so, where did those incorrect values come from? Is the hardware signalling something that we're missing? We're waiting for the TC flag - is it signalling TE?
If there ever is a timeout, as was pointed out above, the state gets locked into "error", so it never works again. Is that reasonable? Is this supposed to be a reliable interface?