Code Flash Erase Issue

I am using the S7G2-DK board.

I just added some code to my project using the r_flash_hp Synergy driver.  My first step was to test erasing a block of code flash that I am not currently using for my code so I chose the 32KB block located at address 0x00100000.  The g_flash_hp.p_api->open() and the g_flash_hp.p_api->accessWindowSet() both returned SSP_SUCCESS.  However the g_flash_hp.p_api->erase() caused a breakpoint at address 0xfffffffe.

In the process of attempting to debug this issue, I noticed that the code flash was no longer being written by the J-Link debugger.  Even if I remove power from the PCB and then plug it back in, the J-Link fails to write to the flash.

If I manually used the Windows J-Link utility "J-Link Commander" I can successfully connect to the MCU, but when I try the "erase" command I get the following result: "************ Error: Failed to erase sectors 0 @ address 0x0000000 (erase error)".  Note that this method to erase the flash previously worked.

So it appears that somehow the code flash on my PCB in now in a state where it cannot be erased.

Any ideas?

Thanks, Jeff

  • What did you set the flash access window to? It sounds like you have set the flash access window such that the first block cannot be programmed or erased, so the JLink cannot erase the first sector of the flash

  • I set the flash access window to the addresses being erased, 0x00100000 to 0x00107fff.  So I think that is exactly what has happened.

    So now how can I get the flash access window cleared again?

  • I have a jlink commander script that should allow you to erase the flash access window that you set, I will post it tomorrow when I have access to it

  • Here is the JLink commander script to erase the FLASH access window. To use, from a command prompt (S7-DK board is powered and JLink is connected) :-

    jlink.exe S7G2_Clear_Flash_Access_Window.txt

    Then select the device (R7FS7G27H) choose the interface (SWD) and the speed (default is fine), then, at the end of the script running you should see :-

    40120060 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
    40120070 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
    40120080 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
    40120090 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
    401200A0 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
    401200B0 = FFFFFFFF FFFFFFFF

    Script processing completed.


    Which shows (hopefully) that the flash access window register at 0x40120064 has been erased back to the default. You should only need to set the flash access window if you want to limit the range of flash that can be erased and programmed.

  • Thanks Jeremy, that worked perfectly and I am now back up and running!

    I think I am not going to use the access window functions so I don't take a chance of doing this again.

    Jeff

  • Now that I am back up and running (thanks Jeremy), I am investigating the issue I am having where the debugger breakpoints at address 0xfffffffe when I execute the g_flash_hp erase() function to try to erase one block of code flash (the block is outside of my normal code space at 0x00100000).

    I notice that if I disable/enable interrupts around the erase() call then the erase() function works and it returns with SSP_SUCCESS.

    I do not see in the SSP documentation anything that says that the interrupts must be disabled so is disabling the interrupts the correct method or is there probably something else going on?

    -- Jeff

  • The flash_hp erase code runs from RAM, as when the flash is being programmed or erased, the CPU cannot access it for normal code execution or normal data fetch. The Vector table normally resides in flash, starting at address 0 (this can be changed by modifying the Cortex M register VTOR Vector Table Offset register). So, when programming the flash, if the vector table has not been re-located to RAM (and also interrupt routines not in the internal flash that is being programmed or erased), then if an iterrupt occurs, the CPU will try to access the vector table (which it can't), so a erro will occur.

    So, disabling interrupts is one approach (if you can cope with interrupts being disabled while the flash is being programmed), or you could re-locate the vector table with the VTOR register if you need interrupts while the flash is being programmed (but this will be more involved).

  • Thanks for the detailed explanation Jeremy.  It is exactly what I was thinking but I wanted to make sure I wasn't missing anything.

    -- Jeff

  • Hi,
    I get the same problem with the access window but on the S124 for the MCU : R7FS12477
    How can i create the same file as : S7G2_Clear_Flash_Access_Window.txt

    Thanks,