• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 887 subscribers
  • Views 543 views
  • Users 0 members are here
Options
Related

e2 Studio does not download to QSPI when debugging

Doug

I upgraded from 2022-04 to 2024-07.  In doing so, the IDE no longer programs QSPI when I debug my application.  It will program the internal FLASH of the device.

================  BUILD ===========================

Extracting support files...
14:12:46 **** Incremental Build of configuration Debug for project PROJ ****
make -r -j8 all
arm-none-eabi-size --format=berkeley "PROJ.elf"
   text               data                 bss              dec              hex          filename
2456180    11471872    20852832    34780884    212b6d4    PROJ.elf

14:12:47 Build Finished. 0 errors, 0 warnings. (took 1s.916ms)

================== DEBUG =========================

GDB Server for Renesas targets.
    Version 9.6.0.v20240708-130119 [c3334318] (Jul 10 2024 12:31:49)

Starting server with the following options:
        Raw options  : C:\Users\<user>\.eclipse\com.renesas.platform_510646852\DebugComp\\Synergy\e2-server-gdb -g SEGGERJLINKARM -t R7FS7G27H -uConnectionTimeout= 30 -uSelect= USB -uJLinkSetting= C:\Projects\ngt\ngt_1_A\src/NGT app.jlink -uJLinkLog= C:\Projects\ngt\ngt_1_A\src/JLinkLog.log -uLowPower= 0 -uInteface= SWD -uIfSpeed= 4000 -uResetBeginConnection= 1 -uNoReset= 1 -uResetPreRun= 1 -uIdCodeBytes= FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF -uDisconnectionMode= 2 -uSWOcoreClock= 0 -uresetOnReload= 1 -n 0 -uFlashBp= 1 -uSimulation= 0 -ueraseRomOnDownload= 0 -ueraseDataRomOnDownload= 0 -uOSRestriction= 0 -uAllowCachingFlash= 1 -uCPUFrequency= 0 -uCECycle= 1 -uResetBehavior= Reset -l -uCore= SINGLE_CORE|enabled|1|main -uSyncMode= async -uFirstGDB= main --english --gdbVersion= 12.1
Using J-Link version V7.84d - C:\Users\<user>\.eclipse\com.renesas.platform_510646852\DebugComp\Synergy\ARM\Segger\JLinkARM.dll

Connecting to R7FS7G27H, ARM Target
        GDBServer endian           : little
        Target power from emulator : Off
Starting target connection
Finished target connection
GDB: 4580
Target connection status - OK
Target connection status - OK
Starting download
Option Function Select, writing to address 0x00000400 with data fffffffffffdffff
SECMPUxxx, writing to address 0x00000408 with data ffffffffffffffffffffffffffffffff...
Finished download
GDB action 'Finished download', has failed with error report, failed to download

Parents
  • 0

    Hello,

    On your debug configuration I cannot see an option to program QSPI with something. You need to tell J-Link where and what it should program to QSPI flash. For example (from an RA document):

  • 0 in reply to AZ-Renesas

    I am not trying to load a separate file into QSPI.  My map file contains the QSPI code:

    Memory Configuration

Name          Origin     Length     Attributes
FLASH         0x00000000 0x00400000 xr
RAM_S         0x1ffe0000 0x00020000 xrw
RAM           0x20000000 0x00080000 xrw
DATA_FLASH    0x40100000 0x00010000 xr
QSPI_FLASH_NA 0x60000000 0x00040000 xr
QSPI_FLASH    0x60040000 0x01fc0000 xr
SDRAM         0x90000000 0x02000000 xrw
ID_CODES      0x40120050 0x00000010 xr
*default*     0x00000000 0xffffffff
  • 0 in reply to Doug

    Which pins are used as QSPI pins ? Are you using a custom board ?

    It seems that the download fails: 

    < GDB action 'Finished download', has failed with error report, failed to download >

  • 0 in reply to AZ-Renesas

    I have upgraded from 2.3 to 2.6.1, but I am using the same XML and pincfg files. These should have kept all of my pins configured the same. I am using the S7G2 DK design.  I have not had this issue with previous versions of e2 studio for the last last 4 years. It only started when I upgraded  from 2022-04 to 2024-07.

    I do not get any other error messages while downloading, so I do not know when (or why) the error occurred.  I have verified that our QSPI pins have not changed from 2.3 to 2.6.1.


    pin_data.c

    I have also verified that my jlink file matches that of our previous e2 studios. I also verified the following settings in the Debugger, startup, and debug tools settings match our previous version.

    I assume there is some setting in the debugger that I need to set that I did not in previous versions of e2 studio in order for the debugger to download to this area.

    • Is there a JLINK setting I need to set?
    • Is there anything else I can provide to help debug this issue?
  • 0 in reply to Doug

    Hello,

    Does this happen also with the correct pin configuration ? (referring to the issue on the other post you submitted).

  • 0 in reply to AZ-Renesas

    Yes.  My pin configuration now matches my 2.3 version.  I did a make clean/rebuild and the issue persists.

    I figured that I had to figure out which log file was showing the error.  It turns out the error is in JlinkLog.log.

    T4C64 013:523.358 Flash bank @ 0x60000000: Default: L2 verify disabled because algorithm performs L1 verify

    T4C64 013:523.996 -- Start of determining flash info (Bank @ 0x60000000)

    T4C64 013:524.468 -- Calculating RAM usage

    T4C64 013:525.029 -- RAM usage = 40180 Bytes

    T4C64 013:525.502 -- Preserving CPU registers

    T4C64 013:526.003 -- Preparing target

    T4C64 013:526.411 -- Preserving target RAM temporarily used for programming

    T4C64 013:655.537 -- Downloading RAMCode

    T4C64 013:713.025 -- Preparing RAMCode

    T4C64 013:720.133 -- Checking target RAM

    T4C64 013:724.804 -- Error while determining flash info (Bank @ 0x60000000)

    T4C64 013:725.376

    ***** Error:

    T4C64 013:725.871 Error while determining flash info (Bank @ 0x60000000)

    T4C64 013:726.340 -- End of determining flash info

    T4C64 013:727.858 CPU_ReadMem(4 bytes @ 0x2006693C)

    T4C64 013:728.716 Data: 00 00 00 00

    T4C64 013:729.134 - 1808.873ms returns 0

    T4C64 013:743.316 JLINK_EndDownload()

    T4C64 013:743.734 - 0.625ms returns -1 (0xFFFFFFFF)

    I have verified the device is a R7FS7G27H.

  • 0 in reply to Doug

    It's been several days.  I am using the same hardware for two years.  This was not an issue until I upgraded to 2.6. running 2024-07.   I can message you my pin_data file if that would help.  I really need this to start working again.

  • 0 in reply to Doug

    Could you share a project with QSPI issue so I can test on my side ?

    Let me attach a working project on SK-S7G2 that loads 10 bytes in the first 10 bytes of QSPI:

    Test_SK_S7G2_QSPI.zip

    Have you tried to update the J-Link firmware version ?

    Is QSPI 'visible' by J-Link ? Are you able to erase the QSPI area for example ?

    On DK-S7G2 is DIP switch S9-1 set to ON ?

  • +1 in reply to AZ-Renesas

    I figured out  the issue. We are using a custom board 'based' on the S7G2-DK dev kit. This board has not changed in 4 years. The only difference is that our board does not have the EEPROM the BSP uses to determine board type.  bsp_s7g2_dk_id_read() will hang if the eeprom is not installed (not sure why it doesn't just time out),  I got around this by replacing bsp_s7g2_dk_id_read(), which should have left bsp_s7g2_dk_board_rev= 0 (version 3.95).  We are using a MT25QL256ABA1EW9. 

    My first attempt at overriding the issue was to return '0', which was wrong, because '0' means the FLASH is MX25.  bsp_s7g2_dk_board_rev now returns '0xff' and we are now able to write to external FLASH.

    And yes I set bsp_qspi.c to read-only to prevent rebuilds from altering it.

Reply
  • +1 in reply to AZ-Renesas

    I figured out  the issue. We are using a custom board 'based' on the S7G2-DK dev kit. This board has not changed in 4 years. The only difference is that our board does not have the EEPROM the BSP uses to determine board type.  bsp_s7g2_dk_id_read() will hang if the eeprom is not installed (not sure why it doesn't just time out),  I got around this by replacing bsp_s7g2_dk_id_read(), which should have left bsp_s7g2_dk_board_rev= 0 (version 3.95).  We are using a MT25QL256ABA1EW9. 

    My first attempt at overriding the issue was to return '0', which was wrong, because '0' means the FLASH is MX25.  bsp_s7g2_dk_board_rev now returns '0xff' and we are now able to write to external FLASH.

    And yes I set bsp_qspi.c to read-only to prevent rebuilds from altering it.

Children
No Data