3 Replies Latest reply on Feb 13, 2019 5:53 PM by XiaoweiZ_71

    Recovering from corrupted SFLASH due to Day029_BLE_SFlash_Write


      I was trying to learn how to store user data in SFLASH and thought I could use this example case in github. It was set up for 128 kB while my cyc8ckit-042-ble-a has 256 kB. I tried it several times and I don't know what it did, since there was a weird problem with virtual COM + TeraTerm and I got nothing. Then I found out how to set up the software for 256 kB and I it working and added some own data as well.


      The stupid example software writes over all the four rows, even though there seems to be 6 (32 bit?) reserved values. What else did it overwrite when the parameters were setup for wrong address, row length etc? Is it possible to restore the SFLASH?


      When I started to go back to BLE testing I noticed that the MAC address had changed and contained values that I had put into SFLASH. Even worse one project doesn't seem to work anymore. No BLE output and current consumption is 17 mA instead of 200 uA it used to be. Another BLE test project seemed to still work OK with expected current consumption (180 uA connected at 100 ms).


      I also tested using CySysPmStop() to put the module into stop state. For some reason it consumed 7 mA instead of the expected <<1 uA. Hadn't tested that before SFLASH corruption, so maybe there is another reason.


      My idea was to use SFLASH for marking what should happen after reset. Every other reset should put the device to stop and every other should wake up. So I would need to store a state in SFLASH at every reset. What will happen if the user resets the chip while I'm writing to SFLASH? Will it possible corrupt the whole SFLASH or just the row I was writing?

        • 1. Re: Recovering from corrupted SFLASH due to Day029_BLE_SFlash_Write

          Creator provide SFLASH writing API (uint32 CySysSFlashWriteUserRow(uint32 rowNum, const uint8 rowData[]) ) for PSoC 4100 BLE/PSoC 4200 BLE devices, you can find this API in cy_boot-->CyFlash.c, you can call this API directly to write or over-write dedicate SFLASH row.


          If the user resets the chip while writing to SFLASH, current SFLASH ROW may be corrupted, because CPU erase current SFLASH row first before writing. No affection to other three SFLASH rows.


          If you need to write SFLASH frequently, you may need to care the Flash endurance spec in datasheet, the minimum value is 100K cycles.

          • 2. Re: Recovering from corrupted SFLASH due to Day029_BLE_SFlash_Write

            Looking from CyFlash.c it says for this function:


            "* This API is applicable for PSoC 4100 BLE, PSoC 4200 BLE, PSoC 4100M,

            * PSoC 4200M, and PSoC 4200L family of devices."


            So not applicable for cyble-022001 module, which I plan to actually use? AFAIK it's a PRoC BLE while the kit has a PSoC 4200 BLE chip.

            How will I know will this work or not? I don't have the module yet and I thought PSoC 4200 BLE would be similar enough for testing.


            The API in CyFlash.c seems to do about the same as this old example I used, but it does set the parameters differently so you don't have to take care of addresses and row lengths.


            Selecting cyble-022001 in PSoC Creator shows just the same CyFlash.c and CyFlash.h still shows 4 rows of SFLASH. Compiles just fine. Works even for PRoC BLE???


            Like I wrote in the other thread I'm still very confused about PRoC vs. PSoC. Even cyble-022001 datasheet says " PSoC 4 BLE" while in PSoC Creator it is listed as "PRoC BLE".




            100K cycles should be plenty for writing at each reset. Hard to see even 1K cycles to be used.

            • 3. Re: Recovering from corrupted SFLASH due to Day029_BLE_SFlash_Write

              This module include a PSoC 4100 or 4200 BLE device, SFLASH writing API is available to this module. If it is not available, API is grey color and project cannot pass building without error.