DISCO_F746NG QSPI WriteEnable might Fail on IAR8

[offirko]

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

if (HAL_QSPI_Command(&obj->handle, &st_command, HAL_QPSI_TIMEOUT_DEFAULT_VALUE) != HAL_OK) {

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

[ ] Question
[ ] Enhancement
[X] Bug

[offirko]

@jeromecoutant , @adustm : I'd appreciate your inputs
Thanks.

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-990

[offirko]

@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

[offirko]

@ARMmbed/mbed-os-maintainers - Please assign this issue to STM people

[offirko]

@VVESTM , @jeromecoutant , @adustm : hal qspi get stuck at certain stage of the test at:

mbed-os/targets/TARGET_STM/TARGET_STM32F7/device/stm32f7xx_hal_qspi.c

Line 696 in db8a018

status = QSPI_WaitFlagStateUntilTimeout(hqspi, QSPI_FLAG_TC, SET, tickstart, Timeout);

Eventually the 5[sec] timeout expires and error state is set:

mbed-os/targets/TARGET_STM/TARGET_STM32F7/device/stm32f7xx_hal_qspi.c

Line 2167 in db8a018

hqspi->State = HAL_QSPI_STATE_ERROR;

The QSPI hal then is stuck, and no read/program/erase commands can be made until the device is reset !

[0xc0170]

cc @ARMmbed/team-st-mcd

[VVESTM]

There is also something related to the toolchain. Does someone knowing IAR can see what can be the issue ?
Can it be a memory corruption ? For information, the problem always occurs at the same place. If we rename variable or change name_a to name_A, the problem moves or "disappear"... Same if we remove optimizations in compiler options.

[VVESTM]

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)
"IAR": {
"common": [
"--no_wrap_diagnostics", "-e",
"--diag_suppress=Pa050,Pa084,Pa093,Pa082", "--enable_restrict",
"-DMBED_TRAP_ERRORS_ENABLED=1"],
"asm": [],
"c": ["--vla", "--diag_suppress=Pe546", "-Oh"],
"cxx": ["--guard_calls", "--no_static_destruction", "-On"],
"ld": ["--skip_dynamic_initialization", "--threaded_lib"]
}
Does it means that problem can be on C++ part ?

[jeromecoutant]

@kjbracey-arm @pan- Could you have a look on questions we have around C++ and IAR ?
Thx

[VVESTM]

One more point. On @LMESTM side, the test is passed. The difference is the IAR version :
Test passed : IAR ELF Linker V8.32.2.178/W32 for ARM (EWARM-CD-8322-19423.exe)
Test failing : IAR ELF Linker V8.32.3.193/W32 for ARM (EWARM-CD-8323-20228.exe)