[SOLVED] J-Link GDB Server erases flash sectors used for storing persistent data when downloading a firmware image

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] J-Link GDB Server erases flash sectors used for storing persistent data when downloading a firmware image

    Hello,

    I am using the J-LINK GDB server V7.98a for downloading and debugging my firmware on a Nordic nrf9160.

    Recently I added a flash area for storing persistent data in the firmware. This data is located in the area 0x000f8000-0x000f9fff.

    When I download my full application, this persistent area gets erased. This is an excerpt of the log I see in the GDB server log (you can see my attempts to define which areas to erase and to enable the RWM feature):

    Received monitor command: exec erase 0x00000000-0x0007FFFF
    Executed erase 0x00000000-0x0007FFFF
    Received monitor command: exec erase 0x00FF8108-0x00FF8388
    Executed erase 0x00FF8108-0x00FF8388
    Received monitor command: exec SetFlashDLNoRMWThreshold = 0xFFFFFFFF
    Executed SetFlashDLNoRMWThreshold = 0xFFFFFFFF
    Received monitor command: reset 0
    Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
    Downloading 16128 bytes @ address 0x00000000
    Downloading 11676 bytes @ address 0x00003F00
    Downloading 16080 bytes @ address 0x00008000
    Downloading 16112 bytes @ address 0x0000BED0
    Downloading 576 bytes @ address 0x0000FDC0
    Downloading 1458 bytes @ address 0x00010000
    Downloading 16080 bytes @ address 0x00018000
    Downloading 16112 bytes @ address 0x0001BED0
    Downloading 576 bytes @ address 0x0001FDC0
    Downloading 1458 bytes @ address 0x00020000
    Downloading 16096 bytes @ address 0x00028000
    Downloading 16160 bytes @ address 0x0002BEE0
    Downloading 512 bytes @ address 0x0002FE00
    Downloading 16096 bytes @ address 0x00030000
    Downloading 16000 bytes @ address 0x00033EE0
    Downloading 16032 bytes @ address 0x00037D60
    Downloading 15888 bytes @ address 0x0003BC00
    Downloading 1520 bytes @ address 0x0003FA10
    Downloading 16016 bytes @ address 0x00040000
    Downloading 16016 bytes @ address 0x00043E90
    Downloading 16064 bytes @ address 0x00047D20
    Downloading 16000 bytes @ address 0x0004BBE0
    Downloading 1440 bytes @ address 0x0004FA60
    Downloading 15984 bytes @ address 0x00050000
    Downloading 16080 bytes @ address 0x00053E70
    Downloading 16096 bytes @ address 0x00057D40
    Downloading 16096 bytes @ address 0x0005BC20
    Downloading 1280 bytes @ address 0x0005FB00
    Downloading 16064 bytes @ address 0x00060000
    Downloading 16048 bytes @ address 0x00063EC0
    Downloading 16096 bytes @ address 0x00067D70
    Downloading 16080 bytes @ address 0x0006BC50
    Downloading 1248 bytes @ address 0x0006FB20
    Downloading 16192 bytes @ address 0x00070000
    Downloading 16352 bytes @ address 0x00073F40
    Downloading 16288 bytes @ address 0x00077F20
    Downloading 10967 bytes @ address 0x0007BEC0
    Downloading 80 bytes @ address 0x00FF8130

    When I download a sample application (which does not write the 80 bytes to the address 0x00FF8130) the persistent data remains intact:


    Received monitor command: exec erase 0x00000000-0x0007FFFF
    Executed erase 0x00000000-0x0007FFFF
    Received monitor command: exec erase 0x00FF8108-0x00FF8388
    Executed erase 0x00FF8108-0x00FF8388
    Received monitor command: exec SetFlashDLNoRMWThreshold = 0xFFFFFFFF
    Executed SetFlashDLNoRMWThreshold = 0xFFFFFFFF
    Received monitor command: reset 0
    Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
    Downloading 588 bytes @ address 0x00000000
    Downloading 8664 bytes @ address 0x00000260
    Downloading 13836 bytes @ address 0x00002440
    Downloading 312 bytes @ address 0x00007C00
    Downloading 16080 bytes @ address 0x00008000
    Downloading 13768 bytes @ address 0x0000BED0

    How can I ensure that the persistent area is not erased during a firmware download?

    Thank you
    Stefan
    Files

    The post was edited 1 time, last by StefanSchmidt ().

  • Add "memory.region add ro 0x000f8000 0x2000" does not help... The persistent data is erased after the download.

    Received monitor command: exec memory.region add ro 0x000f8000 0x2000
    Executed memory.region add ro 0x000f8000 0x2000
    Received monitor command: reset 0
    Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
    Downloading 16128 bytes @ address 0x00000000
    Downloading 11676 bytes @ address 0x00003F00
    Downloading 16080 bytes @ address 0x00008000
    Downloading 16112 bytes @ address 0x0000BED0
    Downloading 576 bytes @ address 0x0000FDC0
    Downloading 1458 bytes @ address 0x00010000
    Downloading 16080 bytes @ address 0x00018000

    The post was edited 1 time, last by StefanSchmidt ().

  • I close this thread as I found a solution for the issue. I am using the Cortex-M plugin in a docker container to connect to the GDB server running natively on my host. In order to "keep" the settings in the device I added the following to the launch.json (specific for the Cortex-M Plugin):

    "overrideLaunchCommands": [
    "monitor reset 0",
    "dump memory ./settings.bin 0x000f8000 0x000fffff",
    "-target-download",
    "restore ./settings.bin binary 0x000f8000",
    "monitor reset 0"
    ],

    This dumps the settings area to a file and pushes it back onto the device after the target-download has erased the area.