[SOLVED] Loadfile fails using JLink with Adafruit Feather M0

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

  • [SOLVED] Loadfile fails using JLink with Adafruit Feather M0

    I've been tearing my hair out trying to use Atmel Studio 7 to debug a program on the Adafruit Feather M0 with the Segger JLink. I also can't rewrite the bootloader to the Feather M0.

    I have read the Adafruit debugging of ATSAMD21 processors at learn.adafruit.com/proper-step…-arduino-zero-m0/overview.

    I have attached the JLink to the board through the SWD interface and can read the memory of a fresh board that still has the Adafruit-burned bootloader with mem8, mem16, etc commands in JLink.exe. But as soon as I try to use Atmel Studio 7 to debug a sketch, the bootloader is overwritten with 0xFF's and AT7 debugging errors out. I tried to restore the bootloader with AS7 and it fails.

    Using the JLink.exe software directly without AS7, I can use the w1 command to write to the M0 flash and it reads back correctly. But as soon as I try to write the whole bootloader .hex file with the loadfile command, I get the attached error. I have tried slowing the JLink speed down to 1000 kHz and even 500 kHz, but same error occurs.

    The bootloader.hex file is attached.

    Thanks for any ideas.
    Images
    • JLink programming error.PNG

      44.53 kB, 983×610, viewed 2,681 times
    Files
  • Error in loading/erasing ARM M0+ atmel SAMD21G18

    I follow up this since I have similar issue with one of my custom board with SAMD21G18 [same used in Adafruit Feather M0

    I connect SEGGER J-link via SWD interface and I try to load bootloader from location 0x000 but if I do Program&Verify I'm propted that the program area is not empty and if I select to overwrite (answer YES to pup up) the programming process fails and here is the log

    - Erasing affected sectors ...
    [i] - Erasing bank 0, sectors 0-24

    - ERROR: Blank check after erase reports: Failed to erase sectors 0-24 (0x00 - 0x18FF) @ address 0x00
    - ERROR: Failed to erase sectors
    - ERROR: Failed to program and verify target[/i]

    If I answer no to overwriting the area the process seems to end successfully :huh:

    RAM tested O.K.
    [i] - Programming target (6384 bytes, 1 range) ...

    - Target programmed successfully
    - Verifying target (6384 bytes, 1 range) ...
    - All loaded bytes verified OK![/i]

    But then when I load the application from address 0x2000 it doesn't work at all (same binary on another board works perfectly)

    Alos If I try to erase chip from j-flesh I got an error :wacko:

    Erasing chip ...
    [i] - Erasing 1025 sectors, 2 ranges, 0x0 - 0x3FFFF, 0x804000 - 0x80400F

    - RAM tested O.K.
    - Erasing bank 0, sectors 0-63
    - ERROR: Blank check after erase reports: Failed to erase sectors 0-63 (0x00 - 0x3FFF) @ address 0x00
    - ERROR: Failed to erase chip[/i]

    Instead if I try to earse chip from command line or J-flash lite I got successful operation ! ?(

    Erase Thread started.
    Device "ATSAMD21G18" selected.
    Found SWD-DP with ID 0x0BC11477
    Found SWD-DP with ID 0x0BC11477
    Found Cortex-M0 r0p1, Little endian.
    FPUnit: 4 code (BP) slots and 0 literal slots
    CoreSight components:
    ROMTbl 0 @ 41003000
    ROMTbl 0 [0]: 9F0FC000, CID: B105100D, PID: 000BB4C0 ROM Table
    ROMTbl 1 @ E00FF000
    ROMTbl 1 [0]: FFF0F000, CID: B105E00D, PID: 000BB008 SCS
    ROMTbl 1 [1]: FFF02000, CID: B105E00D, PID: 000BB00A DWT
    ROMTbl 1 [2]: FFF03000, CID: B105E00D, PID: 000BB00B FPB
    ROMTbl 0 [1]: 00003000, CID: B105900D, PID: 001BB932 MTB-M0+
    Debugger initialized successfully.
    J-Link: Flash download: Total time needed: 4.186s (Prepare: 0.604s, Compare: 0.000s, Erase: 3.538s, Program: 0.000s, Verify: 0.000s, Restore: 0.043s)
    Erase Thread exited
    Erase done

    But than if a look through memory with j-Mem the area between 0-2000 it’s definitely not empty !


    so I'm completely puzled..

    Do I have something corrupted in the SAMD21? Is there any way to erase completely the flash? Can I recover my MCU in some way ?


    thanks for support
    Images
    • SAMD21G-jling1.PNG

      148.32 kB, 902×769, viewed 1,199 times
    • SAMD21G-jlink2.PNG

      155.56 kB, 902×770, viewed 1,068 times
    • SAMD21G-jlink3.PNG

      145.05 kB, 903×765, viewed 924 times
  • Hi,

    thanks four your inquiry.

    Most likely, the option bytes at 0x804000 are not in a good state. (e.g they were erased).
    I appended a mot file that contains valid option bytes.
    You can download it using J-Link Commander and the "loadfile" command or J-Flash (drag&drop, F7).

    We will improve the behavior of J-Link with SAMD20 / SAMD21 (J-Link will no longer erase the option bytes during ChipErase) in a furture version of the J-Link software.


    Best regards,
    Niklas
    Files
    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.
  • Loadfile fails using JLink with Adafruit Feather M0 »

    I cannot upload any code - it seems to upload, but verification fails (all 0xff). I can read ID and registers and erase flash..
    Tried your advice, but J-link Commander did not understand the file and J-Flash did not connect.

    What next?

    Regards

    SEGGER - Niklas wrote:

    Hi,

    thanks four your inquiry.

    Most likely, the option bytes at 0x804000 are not in a good state. (e.g they were erased).
    I appended a mot file that contains valid option bytes.
    You can download it using J-Link Commander and the "loadfile" command or J-Flash (drag&drop, F7).

    We will improve the behavior of J-Link with SAMD20 / SAMD21 (J-Link will no longer erase the option bytes during ChipErase) in a furture version of the J-Link software.


    Best regards,
    Niklas
  • (Solved) Loadfile fails using JLink with Adafruit Feather M0

    Niklas,

    Thank you for educating me on the option bytes. I looked at another Adafruit M0 board I had which still had the boot loader installed and operational. I compared that to the option byte addresses on the 2 M0 boards which I can't program. There were only two bits different in the first byte only:

    "Good" board option bytes:

    00804000 = FF C7 E0 D8 5D FC FF FF FF FF FF FF FF FF FF FF

    "Bad" boards option bytes:

    00804000 = FA C7 E0 D8 5D FC FF FF FF FF FF FF FF FF FF FF

    I rewrote the first byte to match the "good" board:

    w1 00804000, 0xFF

    Now the "Bad" board option bytes match the "Good" boards. Tried uploading the boot loader file. It failed exactly as in the png file I uploaded initially.

    I did not program in the option bytes you suggested because: (1) They were so different from what the good boards had, and (2) they were for the ATSAMD20J not the ATSAMD21G18 that the Adafruit M0 has.

    BUT......
    Then I read the ATSAMD21G18 data sheet and saw that changes in the NVM option bytes at 0x00804000 don't take effect throughout the core until the chip is reset. I reset the chip. Now I am able to upload the boot loader file and program the chip from the Arduino IDE again.

    My real objective was to use the JLink to debug programs from the Atmel Studio 7 IDE, set breakpoints, etc. I will try that tomorrow. I think I remember an option NOT to erase memory before the sketch is uploaded to the chip through JLink.

    Two questions:

    1. When will the change be released to not erase the NVM option bytes?

    2. Will you please submit a request to the developers to improve the error reporting on file upload errors? The JLink should have been able to see that the NVM was corrupted. It is interesting that only 2 bits were flipped in the NVM option bytes by the JLink when it erased memory but not the entire memory. What was it thinking? ^^

    Thanks,

    Rick

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

  • Thanks Niklas / Rick for the troubleshooting and support but I'm still deeply in the fog with my custom SAMD21G18 board...I'm really got crazy ;(

    following your instruction i did some test

    my faulty board option byte is
    00804000 = 8A C7 E0 D8 5D FC FF

    I try to to fix the first byte with the value suggested by Rick (I use same bootloader SAM-BA modified for arduino 0)
    I did via J-link commander

    w1 00804000,0xFF

    but I got ambiguous result: if I read the address/position after change I still got “8A”

    I tryied few times an one times I got FF but than I read again and was 8A ?(
    (see attached screenshot for sequence of operations)

    Then I try to use the .mot file via J-flash and the result was ok , I reprogram all the option byte with this value
    00804000 = FF 40 40 D8 5D FF FF
    Reading mem from j-link commander was ok

    Then I try again to load bootloader from 0x000 but I always get the same error !!!

    Programming and verifying target (6384 bytes, 1 range) ...
    - RAM tested O.K.
    - Erasing affected sectors ...
    - Erasing bank 0, sectors 0-24
    - ERROR: Blank check after erase reports: Failed to erase sectors 0-24 (0x00 - 0x18FF) @ address 0x00
    - ERROR: Failed to erase sectors
    - ERROR: Failed to program and verify target

    I did another reset via J-flesh light and I verify that the option byte is overwritten again to 00804000 = 8A C7 E0 D8 5D FC FF

    Tried again to load bootloader but nothing…

    Don’t know what to try more :wacko:
    SOS
    [font='&quot'] [/font]
    Images
    • SAMD21G-jlink7.PNG

      34.46 kB, 646×465, viewed 981 times
    • SAMD21G-jlink6.PNG

      17.92 kB, 544×356, viewed 897 times
    • SAMD21G-jlink8.PNG

      71.55 kB, 907×699, viewed 870 times

    The post was edited 2 times, last by arzaman ().

  • I did few other attempts to erase/reset SAMD21G18 and tweak the option byte but I think I have worsen my situation..
    Now if I try to load the applicaiton firmware from 0x2000 I got a fatal error

    - Data file opened successfully (78574 bytes, 1 range, CRC = 0x0F072295)
    Programming and verifying target (78574 bytes, 1 range) ...
    - Connecting ...
    - Connected successfully
    - RAM tested O.K.
    - Erasing affected sectors ...
    - Erasing bank 0, sectors 32-95, 96-159, 160-223
    - Erase operation completed successfully
    - Programming target (78574 bytes, 1 range) ...
    - ERROR: PC of target system has unexpected value after programming. (PC = 0xFFFFFFFE)!
    ---------------------------------------------------------------------- Registers -------------------------------------------------------------------------------------
    PC = FFFFFFFE
    Current: R0 = 41004480, R1 = 00002000, R2 = 00014A99, R3 = E000ED00
    R4 = F0013014, R5 = 0000017F, R6 = 00000000, R7 = 0000000E
    ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    - ERROR: Failed to program target
    - ERROR: Failed to program and verify target

    Any chance to recover the situation? Any solution to clean and reset to factory value my SAMD21G ?
    Hope I have no bricked my micro and someone help me. ?( ?(


    Davide
  • I spent my sunday afternnoon doing some further test and troubleshooting in order to get rid of the problem
    but no chance to revitalize my SAMD21G18...very frustrated and unless someone can help me I give up..

    here what I did

    -upgrade SW suuite to V6

    -perform succesfully after few attempts a "chip erase" from j-link commander

    -loaded succesfully option byte copied from a working orginal sparkfun breakout mountig SAMD21G18
    00804000 = 8A C7 E0 D8 5D FC FF

    -tried to load boot loader from location 0x000 using j-flash but got another error !! X(



    Data file opened successfully (6384 bytes, 1 range, CRC of data = 0xA75EAE86)
    Programming and verifying target (6384 bytes, 1 range) ...
    - Start of preparing flash programming
    - End of preparing flash programming
    - Start of determining dirty areas in flash cache
    - End of determining dirty areas
    - CPU speed could not be measured.
    - Start of erasing sectors
    - Start of blank checking
    - End of blank checking
    - End of erasing sectors
    - Start of flash programming
    - Programming range 0x00000000 - 0x000018FF (025 Sectors, 6 KB)
    - End of flash programming
    - ERROR: Program failed
    - ERROR: Failed to program and verify target


    tried anyway to load the application from 0x2000 but again got error



    - Start of flash programming
    - Programming range 0x00002000 - 0x00009FFF (128 Sectors, 32 KB)
    - End of flash programming
    - ERROR: Program failed
    - ERROR: Failed to auto program target

    don't know what to do more ...may I conclude that is an HW problem and trow away my custom board or there is a chance to recover it ?? ?( ?(


    Davide












    Images
    • SAMD21G-jlink9.PNG

      45.09 kB, 673×420, viewed 913 times
    • SAMD21G-jlink10.PNG

      54.07 kB, 914×671, viewed 996 times
    • SAMD21G-jlink11.PNG

      80.87 kB, 846×538, viewed 914 times
  • Hi all,

    Summary:
    • Erasing the option bytes is not faulty but results in enabling the windowed mode of the watchdog timer. Factory reset values of the option bytes are windowed mode not enabled.
    • If the windowed watchdog is enabled, this may results in different errors during flash programming (RAMCode execution) as for example: PC has unexpected value after..., Error during program / erase..., failed to perform blank check..., etc...
    • As Niklas already wrote, we will improve the SEGGER flash loader so that the option bytes will not be erased when issuing a erase chip. This change is planned to be available in V6.01a, planned to be available on Monday.
    • Apart from this, we will check if we can improve the flash loader to be able to handle the watchdog if it is configured for windowed mode (normal watchdog mode is already supported)

    @rickrcomm: Good to hear that you are up and running
    @arzaman: Did you make sure to power cycle the board after programming the option bytes? This is absolutely necessary as the option bytes become active after power on reset, only. If you still run into any issues, can you please do the following:
    1. Power on reset the board
    2. Start J-Link Commander
    3. Read out the "RCAUSE" register using "mem8 <Addr> 1" command --> Should be 0x01 after reset
    4. Perform the flash download using J-Link Commander
    5. Read out the RCAUSE register again --> If bit 5 is set, this confirms that the watchdog is the root cause of the behavior

    Best regards
    Erik
    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.
  • load file fails using JLink with GBD/openocd with Adafruit Feather M0.

    Updated to JLink version 6.00g today and am now using embedXcode+ as the IDE via GDB and OpenOCD.

    Still experiencing a problem where JLink erases (0xFF) low memory when new code is uploaded from gdb. Then I have to use jlinkexe to reload the Feather bootloader. Then jlinkexe will properly flash the new code using the loadfile command.

    So it seems that when the gdb session issues the "load" command, the Jlink gdb server does an erase first before flashing the code. Then the openocd session begins generating LIBUSB_ERROR.(see attachment)

    Attached are the GDB session, the openocd session and the separate JLinkExe session where the flashing is successful.

    I'm sending this update because previously I thought it was only the option bytes at 0x00804000 that were being corrupted. That only happened when flashing from Atmel Studio 7. But now the erasure of the low memory at 0x0 appears to be causing a problem.

    I know you said the erasure fix was scheduled for version 6.1 but I wanted to get this additional information to you.

    Thanks,

    Rick
    Files
  • Hi Rick,


    the behavior change regarding Option Bytes erasing is included in version V6.00f and later of the J-Link software & documentation pack.
    The next issue seems to be OpenOCD related. OpenOCD does not work reliable with full-speed J-Link devices (J-Link EDU/BASE/PLUS v9 and older, J-Link ULTRA/PRO v3 and older) and current firmware versions.
    Firmware versions included in V5.12j and earlier will work, however, downgrading the firmware of J-Links is not recommend and, although there are no known issues, always happens at your own risk.
    We still need to investigate if this issue can be fixed on our side or has to be fixed in OpenOCD. This is already on our internal ToDo, but unfortunately with a lower priority than other projects, therefore investigation will most likely not start until the end of next week.

    Is OpenOCD necessary for your setup? The J-Link software & documentation pack comes with our own GDB Server, therefore if embedXcode+ supports GDB, you do not to use OpenOCD in order to use embedXcode+ with J-Link.


    Best regards,
    Niklas
    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.
  • Hello Forum,

    the issue regarding OpenOCD + J-Link models with Full Speed USB (V9 and older) has been fixed with the firmware "J-Link V9 compiled Sep 1 2016 18:29:50" or later, which is included in V6.00i or higher of the J-Link software & documentation pack.

    Best regards,
    Niklas
    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.
  • Niklas,

    Thank you for the update.

    I took your advice and moved to the JLink GDB Server. It works fine. It is the solution now implemented by the embedXcode Apple OSX xCode-based IDE I am using. Together the Segger JLink and embedXcode make a wonderful development and debugging environment for Mac developers. Check out embedXcode at: embedxcode.weebly.com/.

    Rick

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