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 Jeremy:
In reply to Michal:
FSTATR when error occurs:
That's a problem. It is part of our project which is already rather big and contains a lot of company IP. Most of it is unrelated to this problem but I'd have to create a new project and extract there only relevant parts. Which could take few days which I don't have now...
However, I'm willing to examine anything you need and/or make some experiments. Just tell me what to try. What ILGLERR flag means and how it can happen? I don't see this register documented in hw manual... BTW, we successfully reproduced it with the brand new S5D9 board so it isn't flash wearing issue.
No, we can reproduce it from the unit test which is called during initialization when all other threads wait for it. Also, we use mutex as data flash access lock.
The flash area used is valid, this was the first thing I checked. Actually, our functions always check area validity before calling flash API. In additon, we call blackCheck API for the range before write and it passes. The code looks like this:
Another observation: I tried recovery. After failed write erase the whole area and write again. For failed erase just repeat it. It works, till now it succeeded always on the 1st attempt. Using the same parameters as original so I don't see how our code could be wrong. Instead, it seems as a weird timing problem in hw driver code or hw itself.
The number of errors isn't small, usually 3 - 5 during 10 sec erase/write test. Errors in one test, number in <> is time in seconds (from the boot, not from test start):
Did you find out the cause of this error? I also started seeing it again just recently on S5D5 after updating from SSP 1.5.0 to 1.7.0 (no idea if this matters). I had this problem some time before and tried to solve it by repeatedly calling erase and possibly reset when this error occurs. However, right now this doesn't seem to suffice anymore. I also see the same FSTATR value like you posted above.
In reply to ChrisS: