[SOLVED] unreliable flash upload with J-Trace and SAM4S

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

  • [SOLVED] unreliable flash upload with J-Trace and SAM4S

    Hello,
    I'm using a J-Trace Pro to debug an ATSAM4SD32C. While I've tried to figure out, why my code is not doing, what it is supposed to do, I came to the conclusion, that the content of my elf file is not flashed correctly. This is not 100% reproducible but if I inspect for example the interrupt table and compare it with a list file or hex file, I find the address of the Reset_Handler to be "reasonable", but not correct. In the log of the SEGGER J-Link GDB Server V6.54 (GUI Version), I found a clue, that there might have been something wrong:


    log wrote:

    Connected to 127.0.0.1
    Reading all registers
    Read 4 bytes @ address 0x0040035C (Data = 0xF0004801)
    Read 2 bytes @ address 0x0040035C (Data = 0x4801)
    Received monitor command: speed 1000
    Target interface speed set to 1000 kHz
    Received monitor command: flash breakpoints = 1
    Flash breakpoints enabled
    Received monitor command: flash download = 1
    Flash download enabled
    Received monitor command: flash device = ATSAM4SD32C
    Selecting device: ATSAM4SD32C
    Downloading 15952 bytes @ address 0x00400000 - Verified OK
    Downloading 7452 bytes @ address 0x00403E50 - Verified OK
    Downloading 240 bytes @ address 0x00405B6C
    - Verified OK
    ERROR: Failed to prepare for programming.
    RAM check failed @ addr 0x20000785.
    RAM check failed while testing 0x07F0 bytes @ addr 0x20000784.
    Writing register (PC = 0x 400000)
    Read 4 bytes @ address 0x00400000 (Data = 0xFEF7FFFF)
    Read 2 bytes @ address 0x00400000 (Data = 0xFFFF)
    Read 2 bytes @ address 0x004009F0 (Data = 0xFFFF)
    Read 4 bytes @ address 0x00400000 (Data = 0xFFFFFFFF)
    Read 2 bytes @ address 0x00400000 (Data = 0xFFFF)
    Read 2 bytes @ address 0x00400002 (Data = 0xFFFF)
    Read 2 bytes @ address 0x0040499C (Data = 0xFFFF)
    Read 2 bytes @ address 0x0040499C (Data = 0xFFFF)
    Read 2 bytes @ address 0x0040499C (Data = 0xFFFF)
    Read 2 bytes @ address 0x00400A82 (Data = 0xFFFF)
    Read 2 bytes @ address 0x00400ABA (Data = 0xAB4B)
    Received monitor command: reset
    Resetting target
    Received monitor command: reset
    The line starting with `ERROR` does not appear, when loading the elf file, but when I start my debug sequence with `monitor reset`. In the cases, where it looks it seems to working correctly, the Error message and the two following lines starting with "RAM" are not present in the log file.

    I've set the "Verify download" option in the GDB server, but even with this option, I don't get any feedback that I can see in GDB (cli version; 7.12.1). This is how my .gdbinit looks like:


    .gdbinit wrote:

    # set print pretty on
    # set debug remote 1

    target remote localhost:2331
    monitor speed 1000
    monitor flash breakpoints = 1
    monitor flash download = 1
    monitor flash device = ATSAM4SD32C

    load ../sensor-blp/cmake-build-workspace-none-cortex-m4-debug-gcc/bin/backend_verifications.elf
    symbol ../sensor-blp/cmake-build-workspace-none-cortex-m4-debug-gcc/bin/backend_verifications.elf

    break crash_log_hardfault_parameters
    break usb.cpp:28
    monitor reset


    Is there a ways to get reliable around this error / to prevent this error? Is there a way to at least get direct feedback in GDB, that such an error occurred?

    best regards,
    Torsten
  • Here is a second example:


    Segger GDB Server log wrote:

    Connected to 127.0.0.1
    Reading all registers
    Read 4 bytes @ address 0x00403DDE (Data = 0x4770BC80)
    Read 2 bytes @ address 0x00403DDE (Data = 0xBC80)
    Received monitor command: speed 1000
    Target interface speed set to 1000 kHz
    Received monitor command: flash breakpoints = 0
    Flash breakpoints disabled
    Received monitor command: flash download = 1
    Flash download enabled
    Received monitor command: flash device = ATSAM4SD32C
    Selecting device: ATSAM4SD32C
    Downloading 15952 bytes @ address 0x00400000 - Verified OK
    Downloading 7772 bytes @ address 0x00403E50 - Verified OK
    Downloading 240 bytes @ address 0x00405CAC - Verified OK
    ERROR: Failed to prepare for programming.
    RAM check failed @ addr 0x20000784.
    RAM check failed while testing 0x07F0 bytes @ addr 0x20000784.
    Writing register (PC = 0x 400000)
    Read 4 bytes @ address 0x00400000 (Data = 0x20003B28)
    Read 2 bytes @ address 0x00400000 (Data = 0x3B28)
    Read 2 bytes @ address 0x004009F0 (Data = 0x3B28)
    Read 4 bytes @ address 0x00400000 (Data = 0xAF00B480)
    Read 2 bytes @ address 0x00400000 (Data = 0x3B28)
    Read 2 bytes @ address 0x0040499C (Data = 0x4A69)
    Read 4 bytes @ address 0x00404B44 (Data = 0xB082B580)
    Read 2 bytes @ address 0x0040499C (Data = 0x68F8)
    Read 2 bytes @ address 0x0040499C (Data = 0x4B2B)
    Received monitor command: reset
    WARNING: T-bit of XPSR is 0 but should be 1. Changed to 1.
    Resetting target
    Setting breakpoint @ address 0x0040499C, Size = 2, BPHandle = 0x000B
    Starting target CPU...
    WARNING: T-bit of XPSR is 0 but should be 1. Changed to 1.
    ...Target halted (DBGRQ, PC = 0x20000000)
    Reading all registers
    I've started GDB (without flash breakpoints enabled, with just one break point set; without the "monitor reset" command from the .gdbinit above). The log showed the messages above down to the last Downloading Message. I've entered a "monitor reset" command, which does not lead to addition log output. After I've started the debug session ("c"), the error message above appeared. The missing T-bit clearly indicates that the flash content was not correct.

    In an other session, the error message above shows up, directly after reseting the controller ("monitor reset"). If I repeat the flash upload (by restating GDB and thus executing the .gdbinit file), I end up without and error messages in the log and then, I'm able to debug my target.
  • Hello,

    Thank you for your inquiry.
    Such an issue is not known to us.
    Could you verify functionality with J-Link Commander?
    Try the following sequence:
    connect
    reset
    halt
    erase
    loadfile "path to hex,bin etc."

    Does this work?
    If not could you provide a screenshot of the session?

    Best regards,
    Nino
    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.
  • Hi Nino,
    thanks for looking into this. No, it doesn't work (beside the command for reseting seems to be "r" not "reset"). I'm getting reproducible an error while executing the "erase" command:


    Error while erasing wrote:

    J-Link>erase
    Erasing device...

    ****** Error: Failed to erase chip @ address 0x00400000 (Algo47: Sector is locked)
    Failed to erase chip.
    Failed to execute RAMCode for chip erase!
    J-Link: Flash download: Total time needed: 5.174s (Prepare: 0.195s, Compare: 0.000s, Erase: 4.901s, Program: 0.000s, Verify: 0.000s, Restore: 0.077s)
    ERROR: Erase returned with error code -5.
    J-Link>

    As this is deterministic and reproducible, I don't think that this is exactly the issue that is bugging me. I ignored that erase issue and went further down your command list and flashed two different hex files alternating and got no error messages even after at least 10 attempts.

    When writing an elf file using GDB, the GDB Server runs very quickly into the issue I'm seeing (see above). I've attached a log from my JLinkExe session.

    I suspect, that the GDB server is deferring flashing until the CPU is restarted and thus is failing at this point. Are there any other tests, that I can do to bring more insight? Anything to make it more reproducible? (already reduced the SWD frequency).

    best regards,
    Torsten
    Files
    • segger.log

      (13.62 kB, downloaded 479 times, last: )
  • As I'm still looking for a solution, I'm poking around a little bit and realized, that the J-Flash Lite software that comes with the J-Trace Pro, also has problems erasing the flash (I dunno, if that is somehow related to my problem):

    J-Flash Lite wrote:

    Connecting to J-Link...
    Connecting to target...
    Erasing...
    ERROR: Could not erase chip.Done
  • While I was searching for similar error messages here in the forum, I found some cases, where the wrong device type caused similar problems (albeit more reproducible). I received the device type with the schematic of the hardware I'm working for. So I got a big magnificent glas and verified, that the actually used type is really a ATSAM4SD32C.
  • Hello,

    Thank you for providing the Commander Session. It appears that your application has write protected parts of the Flash memory which leads to the error behaviour.
    We will investigate if we can improve our Flash algorithm so it can clear such locked areas. This will most likely be added with the next couple of J-Link software versions.

    To stay up to date you can subscribe here:
    segger.com/notification/subscribe.php?prodid=7

    Generally we recommend not to lock your device before debugging is finished.

    Best regards,
    Nino
    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.
  • That would be very helpful. Currently I have to start GDB 3-5 times, and search the tiny font on the GDB server to look for error message. May I propose to maybe print the error message in red, so that error could be spotted easier?

    Anyway: thanks for taking care of this.
  • Is there anything, that I can do to mitigate the problem? Currently, it took me 20 retries to get the flash content to the controller. I don't know if this relates to a OS/X security update I've installed this morning, but for a >2000€ debug probe, the user experience is quite "not sooo good".
  • Hello,
    Keep in mind, that this is not a support forum, so answers might be delayed.
    If you are still in the support period, you can also open a ticked in our support system.
    Please refer to my signature for more information.

    We are working on the security detection issue right now.
    In the meantime a work-around could be to not set the security bit until then.
    Could you send us a reproducer for the security bit problem (ideally a .hex file)?

    I understand, that the issue with the flash download is not related to the issue of the security detection?
    If so, is this problem also appearing when using the J-Link Commander or J-Flash to download the file?

    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.
  • Hi Fabian,
    the J-Trace Pro is less than half a year old. If it helps to speed up this use, I will also open a ticket within your support system. The original message, that flashing with the J-Commander works flawless, was not quite correct. I can see problems there two, but much less. My current workaround is, to close the JLinkGDBServer, start the JLinkExe, flash a new version of the software and then start the JLinkGDBServer again. When flashing with the JlinkExe fails, I try some combinations of `r`, `halt` and `loadfile` until the file is flashed without error message.

    We do not set the SAM4S security flag. Please find attached a hex file that should reproduce the problem. (this more directed to the support, which I will contact right now).

    thanks for looking into this!

    best regards,
    Torsten
    Files
  • Hi Torsten,
    we answered you via Ticket System.

    We will consider this thread as closed.

    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.