Programming dual SNOR flash on custom RZA1H board using JLink fails

Hi,

I have a custom RZA1H board designed with dual SNOR flash (Spansion S25FL512SAGBHI310) device. Programming the bootloader using Seggar JLink Lite V634h was fine. The Renesas QSPI Bootloader code was modified to configure the SPBIO pins accordingly.

Downloading however fails for the application image generated by e2studio. It looks like the JLink tool times out while erasing the devices. The error message is: "block verification error". 

I understand the bootloader is sent on one-bit mode to the first device. Having the bootloader reconfigure the system to Dual mode operation and enable Read Burst Cache, the application image is downloaded to both devices. Not sure if it is done on one-bit or quad bits.

My test program can write data to both device but over single lane only. 

Anyone came across similar issues?

Many thanks 

Regards

EsKay

  • Can you erase the FLASH in single?

    Open JLink, then:
    connect
    ? (and select R7S721001 via dialog)
    (accept all defaults)
    exec EnableEraseAllFlashBanks
    erase
  • In reply to MicBis:

    My test program can erase in single using the Renesas QSPI driver.

    Executed as instructed and got the following msg:
    --------------------------------------------------------------------------------------
    J-Link>erase
    Erasing device...
    Compare method "Programmed sectors, fastest method" is not supported for this device.
    Changed to "Programmed sectors using read back"
    Verify method "Programmed sectors, fastest method" is not supported for this device.
    Changed to "Programmed sectors using read back"

    ****** Error: Verification of RAMCode failed @ address 0x20020000.
    Write: 0xE0A1BE00 E09CE083
    Read: 0xE59FF018 E59FF018
    Failed to prepare for programming.
    Failed to download RAMCode!
    Error while determining flash info (Bank @ 0x18000000)
    ERROR: Erase returned with error code -1.

    --------------------------------------------------------------------------------------

    This could be because the system has no bootloader running - the flash devices are currently blank.

    I will try programming with the bootloader running, next week. This is the only development board left as others have been bricked by the flash tool while programming. The tool somehow has set the BPNV flag in the device Control Register; hence deemed unusable.

    -EsKay
  • In reply to EsKay:

    What pins did you hook the 2nd QSPI up to?

    The J-Link can only program the second QSPI if it is on pins P2_12 to P2_15
  • In reply to EsKay:

    EsKay

    This could be because the system has no bootloader running - the flash devices are currently blank.

    Jlink does not use bootloader, otherwise you won't be able to program the bootloader itself.

     

    EsKay

    I will try programming with the bootloader running, next week. This is the only development board left as others have been bricked by the flash tool while programming. The tool somehow has set the BPNV flag in the device Control Register; hence deemed unusable.

    They are not bricked. They can still be used, if you manage to program OTP bits on both FLASH devices.

  • In reply to Chris:

    I use P8-14 to P9_2?

    Is there anyway the JLink informed with the new setting?
  • In reply to MicBis:

    I thought the bootloader needs to run to configure the devices to quad mode.
    Flash device would not accept to clear the OTP flag in CR, or BP flags in SR1.
  • In reply to EsKay:

    > I thought the bootloader needs to run to configure the devices to quad mode.

    For J-Link programming, the J-Link does everything (setups up the pins, controls the SPI flash, etc...).
    What you have already loaded into the SPI flash does makes not difference. That code is not used, or run and will not help you.


    > Is there anyway the JLink informed with the new setting?

    It seems you have already asked Segger this question back in April.

    forum.segger.com/.../

    As Segger told you, you need to contract them to get a special "Flash loader" that will get downloaded and used by the J-Link. This is not your bootlaoder that you have been programming into SPI flash.
    This is special code specifically for the J-Link, that is downloaded to on-chip (but hte J-Link) and run for each programming session.
  • In reply to EsKay:

    EsKay

    I thought the bootloader needs to run to configure the devices to quad mode.
    Flash device would not accept to clear the OTP flag in CR, or BP flags in SR1.

     

     
    Of course you cannot clear the OTP flags, but what matters is that they have the same configuration on both modules.
    Start by erasing the bootloader: select any bootmode but Boot Mode 3 by acting on MD_BOOTx accordingly, then give the JLink command sequence I suggested above. 
  • In reply to Chris:

    Thanks Chris.
    I got distracted looking into other things on our hardware and had completely forgotten about the query posted on the forum. Will contact Seggar regarding a modified tool.
  • In reply to MicBis:

    Switched to Bootmode 0.
    Ran through the instructions.
    Erase process was successful.
    Programming a bin file (J-Link> loadbin resources.bin 19000000) failed with the following error.

    J-Link: Flash download: Restarting flash programming due to program error (possibly skipped erasure of half-way erased sector).
    J-Link: Flash download: Skip optimizations disabled for second try.

    ****** Error: Programming failed @ address 0x19000000 (block verification error)
    Error while programming flash: Programming failed.


    This could due to the QSPI port 1 pin configs are different on our board from that in the EVM (RSK+). As Chris pointed out in this forum the Seggar flash tool supports RSK+ config only.
  • In reply to EsKay:

    You should be able to use your boards in single SPI mode. Have you selected R7S721001? Do not select R7S721001_Dual, JLink should be able to erase/program in single. Then you can program the bootloader compiled to work in single. I don't remember if the OTP bits matter though. To be sure you will need to program on both modules the same OTP configuration.