[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:


    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:


    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:


    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: https://www.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:



    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

    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):

    Quote from J-Flash Lite

    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:
    https://www.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: https://www.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: https://www.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

    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: https://www.segger.com/ticket/
    Or you can contact us via e-mail.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login