Unable to program and/or erase a S7G2 Device

We are developing on a custom hardware, based on S7G2. The controller part number is R7FS7G27H3A01CFB. All modules required by the application are functional.

There is a requirement to support on-site Firmware Upgrades over Ethernet. To achieve this, I started looking at the TFTP-based firmware upgrade shared here. This is usable with a SK-S7G2.
I created a fresh project with modified pin config file. I also integrated an instance of DHCP client as a separate thread.
I forgot to understand (and modify the contents of bsp_warmstart.c) file.

When I compiled the project, it reported following errors:

miu_bootloader.elf section `.bootloader_record' will not fit in region `ID_CODES'

region `ID_CODES' overflowed by 44 bytes

I looked into the s7g2.ld file, I could see

ID_CODES (rx) : ORIGIN = 0x40120050, LENGTH = 0x10 /* 16 bytes */

I changed it to

ID_CODES (rx) : ORIGIN = 0x40120050, LENGTH = 0x40 /* 64 bytes */

Then, the code compiled just fine. When I programmed my device with it, the debugger ends up at a random address and code does not seem to execute. I tried using the JLink Flasher utility to erase the chip, but no luck there.

Logs for utility:

Connecting to J-Link...
Connecting to target...
Erasing...
ERROR: Could not erase chip.
Done
Selected file: C:/Users/devNull/Desktop/Target_Hardware-Blinky.srec
Conecting to J-Link...
Connecting to target...
Downloading...
ERROR: Could not download file.
Done

I am certain that there is no issue with JTAG/SWD since hours ago I was able to debug and execute application on the same hardware. I have 3 prototypes of this hardware. After the first one failed, I tried other hardware (my mistake!) which was functional.

Now I have 2 boards that needs some fixing. Is there a way I can erase the chip? Also, if anyone can point looking at the project can point where it goes wrong, it would be of great help.

 

 

  • It sounds like you have program the Flash Access Window register by putting extra data into the ID_CODES section :-

     

    It might be possible to clear the Flash Access Window. Download the latest version of the JLink software from :-

    https://www.segger.com/downloads/jlink/JLink_Windows.exe (V6.56a at the time of writing). Install it. Then open a command prompt in the installation directory :-

    And run JLink.exe :-

    Then type connect, select the device as R7FS7G27H, the target interface is SWD and the default connection speed is ok :-

    Then use the loadfile command to load this s-record file (rename to  Clear_ID_FAW_S7G2.mot):-

    Clear_ID_FAW_S7G2.txt
    S31540120050FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF58
    S31540120060FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF48
    S70500002B319E

     

    and it might be possible to overwrite the Flash Access Window setting you made (the result will look different to above, as in my S7G2 there are no ID bytes, or FAW setting programmed).

    The power cycle the board.

  • In reply to Jeremy:

    Hi Jeremy, thank you for responding. I tried the steps you suggested. The 'loadfile' command generates the following response:

    Next actions?

  • In reply to WedaPashi:

    Try the attached script. Set the path to the JLink.exe in JLink_path.bat, and run ID_Code_ERASEALL_S7G2.bat. If it is successful you should see MCUSTAT: 0x00000002 as shown by the red arrow :-

     

     

    0218.ALeRASE_JLINK.zip

     

  • In reply to Jeremy:

    Hi Jeremy, thanks for responding.

    I tried the steps you suggested.

    MCUSTAT is 0x00000000.

     

     The command prompt keep printing the same unless terminated manually.

  • In reply to WedaPashi:

    If the MD pin (P2_01) is low the script won't work.
  • In reply to Jeremy:

    Hi Jeremy, 

    I have two boards that seems to have locked.

    I have modified one hardware to pull-down the MD pin to try and see if it boots into SCI boot mode. The other hardware has MD pin pulled high (3V3) via a 10K resistor.

    The logs for the board that has MD pin pulled high are as follows:

     

  • In reply to WedaPashi:

    Run jlink.exe and connect to the device (with MD = 1) and run the commands mem32 0x400, 10 and mem32 0x40120040, 20 :-

  • In reply to Jeremy:

    Hi Jeremy,

    Ran JLink.exe, when I pass connect command, the following pop-up appears.

  • In reply to WedaPashi:

    Power cycle the board and try again.
  • In reply to Jeremy:

    Hi Jeremy, I really appreciate the support your are providing.

    Please see below:

  • In reply to WedaPashi:

    You have programmed the AWS register at 0x40120064, and the OFS registers at 0x400 - 0x407 and the reserved area at 0x408 to 0x43b :-

     

    with what looks like code, you shouldn't do that, these are configuration areas that effect how the chip operates. You could well have locked the devices.

    The last thing to try is run the attached jlink script

    jlink.exe S7G2_BLock_0_Erase.txt

    then power cycle the board connect the jlink again and run the memory dump commands again

    S7G2_BLock_0_Erase.txt
    /* Sleep for 10ms to allow things to settle */
    sleep 10
    
    /* FPCKAR PCKA for default of 2MHz PCKA (MOCO/4) as set by default values of SCKSCR and SCKDIVCR after reset*/
    w2 0x407FE0E4, 0x1EFF
    
    /*FWEPROP set to 1, Allow access to the flash registers */
    w1 0x4001E416, 0x01
    
    /* FENTRYR = AA80H - code flash in PE mode */
    w2 0x407FE084, 0xAA01
    
    /* FPCKAR PCKA for default of 2MHz PCKA (MOCO/4) as set by default values of SCKSCR and SCKDIVCR after reset*/
    w2 0x407FE0E4, 0x1EFF
    
    /* FSADDR = 0 */
    w4 0x407FE030, 0x00000000
    
    /* Write 40h to the FACI command issuing area */
    w1 0x407E0000, 0x20
    
    
    /* Write D0h to the FACI command issuing area - final access, start FACI processing the command */
    w1 0x407E0000, 0xD0
    
    /* Read the FSTATR Reg, is FRDY bit 1 yet (probably not) */
     mem32 0x407FE080, 1
    
    /* wait for 1sec, more than enough time for the operation! */
    sleep 1000
    
    /* Read the FSTATR Reg, FRDY bit should be 1 by now (register should read 0x00008000) */
     mem32 0x407FE080, 1
    
    /* FENTRYR = AA01H - return to ROM read mode */
    w2 0x407FE084, 0xAA00

  • In reply to Jeremy:

    Hi Jeremy,
    The memory dump appears same as before (Screenshot shared earlier).

    I think if thats the case, I am going to have to replace the controller with a fresh one.
    Can you help me understand the correct way to implement the firmware upgrade over ethernet, probably using the tftp bootloader example?
    I have tried the example shared by Karol. This code in fact was developed looking at the example as a reference.

    I guess the problem is with this part:

    When I compiled the project, it reported following errors:

    miu_bootloader.elf section `.bootloader_record' will not fit in region `ID_CODES'

    region `ID_CODES' overflowed by 44 bytes

    I looked into the s7g2.ld file, I could see

    ID_CODES (rx) : ORIGIN = 0x40120050, LENGTH = 0x10 /* 16 bytes */

    I changed it to

    ID_CODES (rx) : ORIGIN = 0x40120050, LENGTH = 0x40 /* 64 bytes */

    This is what I think has locked the device, is there a way to get around this?
  • In reply to WedaPashi:

    Hi WedaPashi,

    >When I compiled the project, it reported following errors:

    >miu_bootloader.elf section `.bootloader_record' will not fit in region `ID_CODES'

    >region `ID_CODES' overflowed by 44 bytes

    To begin with, `.bootloader_record' section should not be allocated in region `ID_CODES'.

    It has execution code for boot, and the bootloader never updates this area.

    (See Karel says in the following thread.)

    It seems the linker script of your project is broken.

     

    The bootloader does not jump to the application

     

     

    >I think if thats the case, I am going to have to replace the controller with a fresh one.

    I can see that.

    But you should repair the liker script before doing it.

  • In reply to tenballs:

    You also need to check OFS registers at 0x400 - 0x407 and the reserved area at 0x408 to 0x43b in your linker script.
  • In reply to Jeremy:

    Thank you Jeremy. I'll look into it, and will see if it can be validated by experts here before I lock up another microcontroller.