[SOLVED] JLinkGDBServer appears to write to SAMD21 flash but write doesn't happen

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

  • [SOLVED] JLinkGDBServer appears to write to SAMD21 flash but write doesn't happen

    I have been having trouble in the past few weeks using JLInkGDBServer, in which it appears to write to flash memory on a SAMD21G18, but the writes don't actually happen.

    Example A:

    (gdb) set *0x2000 = 0x1234
    (gdb) x 0x2000
    0x2000: 0xffffffff # write did not happen?!

    JLinkGDBServer output:
    Downloading 4 bytes @ address 0x00002000
    Reading all registers
    Read 4 bytes @ address 0x00000288 (Data = 0x49214820) # (this is the PC location, not important to this example)
    Read 2 bytes @ address 0x00000288 (Data = 0x4820)
    Read 4 bytes @ address 0x00002000 (Data = 0xFFFFFFFF)
    [etc.]

    Example B:

    (gdb) restore example.bin binary 0
    Restoring binary file example.bin into memory (0x0 to 0x2000)
    (gdb) dump binary memory dump1.bin 0 0x2000

    # after the above, the example.bin and dump1.bin files are identical.

    # But then I unplug the J-Link from the board, power cycle the board, plug J-LInk back in, and restart JLinkGDBServer, and dump memory again.
    (gdb) dump binary memory dump2.bin 0 0x2000

    # after the above, dump1.bin and dump2.bin are not identical. In fact, it appears that the original restore did not write to flash. dump2.bin contains the original contents of flash before the restore happened. So the restore did not actually write to flash.

    JLinkGDBServer is again reasonable, showing things like this:
    Downloading 8192 bytes @ address 0x00000000
    Reading 8192 bytes @ address 0x00000000

    It's not true writes never happen. I can load programs with the "load" command, and sometimes writing flash works, but as you see, sometimes it doesn't.
    Note that BOOTPROT is sometimes set to protect 0x0000 to 0x1FFF, but I've also seen this when BOOTPROT is set to protect nothing.

    I'm baffled by this. In the case of restore and dump, it's as if there's a local copy being used instead of reading from flash.

    I can open a ticket, but I thought I would ask here first. Thanks.


    Everything is quite up to date:

    Versions:
    arm-none-eabi-gdb: GNU gdb (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 8.3.0.20190709-git
    Ubuntu 20.04 x64 (but also had problems on 18.04)
    J-Link: Firmware: J-Link V10 compiled Mar 19 2020 11:10:39, Hardware: V10.10
    SEGGER J-Link GDB Server V6.70 Command Line Version

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

  • Just to show you that this problem is intermittent, I tried again this morning, with the same board, same everything, just restarting JLinkGDBServer and arm-non-eabi-gdb, and it's currently working, so somehow it gets into a bad state:

    (gdb) x 0x8888
    0x8888: 0xffffffff
    (gdb) set *0x8888 = 0x12345678
    (gdb) x 0x8888
    0x8888: 0x12345678
    (gdb) x 0x2000
    0x2000: 0xffffffff
    (gdb) set *0x2000 = 0x1234
    (gdb) x 0x2000
    0x2000: 0x00001234
  • Hi,
    Thank you for your inquiry.

    Since you submitted a ticked we will consider this forum thread as closed now.

    Best regards,
    Fabian
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.