Cy_FlashEraseRow triggers reset, Cy_FlashWriteRow succeeds

[TiDo_3898341]

I am trying to erase 30 rows on a CY8C624FTI-D52 but am finding the processor will often reset (~30%)  while calling Cy_FlashEraseRow in a loop.  If I instead just Cy_FlashWriteRow with 0's it never resets.  Any idea what might cause this?  I am thinking it must be a symptom of some other problem I need to find.

[Ekta_N]

Hi @TiDo_3898341 

The Cy_FlashWriteRow function performs an erase before writing the flash with 0's. So, ideally using either Cy_Flash_EraseRow should not cause reset while the Cy_Flash_WriteRow works properly.

Is there any other difference in the code when using Cy_Flash_EraseRow like the use of WDT or are switching to Deep Sleep or Hibernate mode?

I would also like to know the reason for the reset. You can try using the Cy_SysLib_GetResetReason()  or the cyhal_system_get_reset_reason() function to know what was the cause of the reset. Kindly let me know the same.

Best Regards
Ekta

[TiDo_3898341 · Accepted solution]

I finally had time to revisit this.  Cy_SysLib_GetResetReason() returns CY_SYSLIB_RESET_SOFT (0x0010).  I ruled out a lot of possibilities:

1.  Byte array on stack for write 0's was guarding memory somehow

2.  Flash region was being used for something else

3.  WatchDog timer or other timer events not getting serviced

4.  Our system "event loop" was not getting called often enough

Finally, what fixed it was putting a Cy_SysLib_Delay(5) after each call to Cy_FlashEraseRow.

[TiDo_3898341]

Thanks, code is the same, with a call to flush the cache and buffers at the end of the loop.  Possibly the crash is happening there or somewhat later.  I am basing location of crash on last thing I see in uart debug log, but not sure how much delay might be there.  We do have WDT running, to trigger reset, but problem still occurred even if I reset the WDT in the loop.  Plus, it seems like Cy_Flash_EraseRow would be faster.  I will try to get a reading of Cy_SysLib_GetResetReason() and see how we are handling power modes.

[TiDo_3898341]

It just occurred to me big difference is write method declares 512-byte array of 0 which I guess compiler is allocating on the call stack.  So, if some other code is corrupting the stack, this could be giving protection.  I will investigate this.