New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DISCO_F746NG QSPI WriteEnable might Fail on IAR8 #10049
Comments
@jeromecoutant , @adustm : I'd appreciate your inputs |
Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-990 |
@TuomoHautamaki - my analysis currently is that after several successful program commands to QSPI flash, a new program command fails on Write Enable. All further program/read/erase commands fail on HAL_BUSY. We need ST and HAL support on this case |
@ARMmbed/mbed-os-maintainers - Please assign this issue to STM people |
@VVESTM , @jeromecoutant , @adustm : hal qspi get stuck at certain stage of the test at:
Eventually the 5[sec] timeout expires and error state is set:
The QSPI hal then is stuck, and no read/program/erase commands can be made until the device is reset ! |
cc @ARMmbed/team-st-mcd |
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) |
@kjbracey-arm @pan- Could you have a look on questions we have around C++ and IAR ? |
One more point. On @LMESTM side, the test is passed. The difference is the IAR version : |
I've noticed there's a known issue for this device in IAR: http://supp.iar.com/FilesPublic/UPDINFO/013240/arm/doc/infocenter/ewarm.ENU.html |
@VVESTM - please note the problem is reproduced on my env using: IAR ELF Linker V8.32.1.169/W32 for ARM . And with a bit of code variation, reproduced the problem, this time when trying to set "name_b" |
CC: @screamerbg |
@ARMmbed/mbed-os-test @ARMmbed/mbed-os-core @ARMmbed/mbed-os-maintainers Fyi: #10049 (comment) |
@VVESTM - Disabling Data Cache with a call to: SCB_DisableDCache() at begining of the test case resolves the problem. (could it after all be related to: #9934 (comment) ?) |
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? |
@VVESTM We see that this issue is reproducible but also is fragile, meaning small changes to the test, like adding prints, or playing with the cache, will "fix" the problem. We need your help in the investigation of the root cause why the QSPI get stuck. |
@dannybenor, I am working on this issue. I come back when I have news. |
ST_INTERNAL_REF 64387 |
This patch is missing in F7 HAL. Fix ARMmbed#10049 Signed-off-by: Vincent Veron <vincent.veron@st.com>
This patch is missing in F7 HAL. Fix #10049 Signed-off-by: Vincent Veron <vincent.veron@st.com>
On the STM32769NI at least this patch is required for stable QSPI use. Enable it uncondtionally in case other boards need it too. Further discussions: ARMmbed#10049 ARMmbed#15108 STMicroelectronics/STM32CubeF7#52 STMicroelectronics/STM32CubeF7#82
On the STM32769NI at least this patch is required for stable QSPI use. Enable it uncondtionally in case other boards need it too. Further discussions: ARMmbed#10049 ARMmbed#15108 STMicroelectronics/STM32CubeF7#52 STMicroelectronics/STM32CubeF7#82
* STM32F7: Unconditionally enable QSPI workarounds On the STM32769NI at least this patch is required for stable QSPI use. Enable it uncondtionally in case other boards need it too. Further discussions: ARMmbed#10049 ARMmbed#15108 STMicroelectronics/STM32CubeF7#52 STMicroelectronics/STM32CubeF7#82 * QSPIF: Attempt 4-byte addressing on Macronix chips mbed-os PR 11531 introduced 4-byte addressing in the QSPIF block device: ARMmbed#11531 During testing it was found that this code broke on the NRF52840_DK and DISCO_F769NI. The NRF52840_DK controller seems unable to handle 4-byte addressing at all and has been disabled entirely in another code section. The DISCO_F769NI breakage was attributed to the flash chip but after more research I believe this is related to the QSPI controller, not the 4-byte addressing itself. Now that the QSPI controller has a workaround, enable 4-byte addressing again and hope it works fine this time.
On the STM32769NI at least this patch is required for stable QSPI use. Enable it uncondtionally in case other boards need it too. Further discussions: ARMmbed#10049 ARMmbed#15108 STMicroelectronics/STM32CubeF7#52 STMicroelectronics/STM32CubeF7#82
Description
Following https://jira.arm.com/browse/IOTSTOR-798 tickect
When running storage tests on DISCO_F746NG with IAR8 it fails on test:
features-storage-tests-kvstore-static_tests
Same board and test pass ok on IAR7 , as well as on GCC_ARM and ARM.
The test fails in this line :
https://github.com/ARMmbed/mbed-os/blob/master/features/storage/TESTS/kvstore/static_tests/main.cpp#L296
When drilling down the failure is on sending write_enable to QSPI Flash, which eventually fails on timeout:
mbed-os/targets/TARGET_STM/qspi_api.c
Line 301 in 84e4dec
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:
“name_a”, “name_b”, “name_c”,…,”name_z”
For some strange reason, the combination of “name_o” followed by “name_p” causes the bug.
Even if we skip all the previous entries and only set “name_o” followed by “name_p” it fails.
Issue request type
The text was updated successfully, but these errors were encountered: