SSP_ERR_CMD_LOCKED during data flash write and erase

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:

    No. The workaround I described above (turn off compiler optimization for hw flash driver) seems to solve problem for us and I didn't have time for next experiments. It is quite possible the workaround just lowers the probability of the problem, though.

    I'd expect next action from Renesas. There is a problem which is very probably in their code so I'd expect they'd try to reproduce and fix it themselves. I really can't give them our project where it is reproducible and don't have time for creating a new project just for this purpose. I guess I provided enough info and I'm willing to answer any related questions.
  • 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:

    That sounds like a potential cause. I'm also running with O2. I will add those lines and see if the error appears again. This might be a promising change for the next SSP release :)
  • In reply to Jeremy:

    Jeremy,

    I'm glad you see it, too. Instruction reordering seems as a good possibility. I don't see a difference on the pictures you posted, though, it seems as original C code, not assembly. If it is a case, it is a bit scary as hw often depends on the right order... any general solution for it?

    Are you speaking for Renesas? If so, what's the plan about official fix?

    Thanks,

    Michal
  • In reply to ChrisS:

    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)

  • In reply to Michal:

    Yes, this is an important point if you don't know about it. You can set the file to read-only to preserve te changes, or change the optimization flags as shown here. The latter option is probably better for future SSP updates.
  • In reply to ChrisS:

    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.

  • In reply to Michal:

    Good to know. I didn't have these issues with SVN so far.
  • In reply to Jeremy:

    Jeremy,

    I'd need some resolution about this issue. We'd need a confirmation this workaround is correct and sufficient solution. Or should I report it as a bug directly?

    Thanks,

    Michal
  • In reply to Michal:

    I have already raised a bug report with the SSP developers, and provided all the information in this posting.
  • In reply to Michal:

    I haven't seen any problems after applying this fix, but I haven't written a specific test case to stress test the flash access.
  • In reply to Jeremy:

    Thanks :) Can we expect some output from them here?
  • In reply to ChrisS:

    Me too but you know, it isn't sufficient. Until the bug is investigated and the root cause found, we can't say this is real fix. It could only decrease probability of a real bug so we don't see it during development and testing but it could occur in the field when millions of devices are released.