We're using S5D9 device and when use data flash rather heavily (we use it for file system), we receive SSP_ERR_CMD_LOCKED error sooner or later. Usually at write but sometimes also at erase call. For write the sequence is erase some blocks and then write them so they're erased for sure. We're NOT using BGO, all is synchronous and there is no access to flash from other threads.
We're using SSP 1.60 + e2studio 7.3.0 and S5D9 development boards. It occurs on more than one board.
The error source is in the function HW_FLASH_HP_operation_status_check() line 1244 for both write and erase errors:
I don't see we could do anything wrong there, we just call the APIs, check all return codes and this is always the first error. It occurs at different addresses during every test run. What to do with it?
In reply to ChrisS:
In reply to Michal:
The issue could be caused by the compiler re-ordering the writes to the flash controller hardware when optimisation is enabled, e.g. for the blank check the addresses show the code is not executed in the same order as the C code is written :-
When I disable compiler optimisation for the low level hardware accesses in the file hw_flash_hp.c, by using
#pragma GCC push_options#pragma GCC optimize ("O0")
(code not to optimise)
#pragma GCC pop_options
around all the code in the file hw_flash_hp.c
then the order the code executes in, is the order the C code is written :-
With the default level of optimisation (-O2) and a test project on an S5D9, that writes and erases data across the entire Dataflash, I have seen the error condition SSP_ERR_CMD_LOCKED either for blankcheck() or write() fairly quickly (after 30 or 40 iterations across the whole dataflash). With the optimisation disabled for the file hw_flash_hp.c, I have yet to see the error SSP_ERR_CMD_LOCKED, after 1000 iterations across the entire dataflash.
In reply to Jeremy:
You may not get the result you expect. The "smart" e2studio build checks the SSP sources and "fixes" them if you make any change i.e. restores the original files. There is a way how to avoid it but in this particular case the best (IMO) solution is to disable optimization for this single source (using its Properties). This way:
(I used debug optimization for all configurations, you can use -O0 just for release)
Read-only flag doesn't work well with source control systems as the may not preserve file attributes. This was the first thing I tried when needed to fix a SSP source the first time and it wasn't usable with git. Changed source has to be moved elsewhere and the original one excluded from the build. In this particular case the situation is a bit simpler because you don't really need to change the source.