[SOLVED] J-Link RAMCode problems with Atmel ATSAME70Q21

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

  • [SOLVED] J-Link RAMCode problems with Atmel ATSAME70Q21

    Hi,

    I am using J-Link 6.22d / Ozone 2.54a via a USB J-Link Plus to an Atmel ATSAME70Q21 (Cortex-M7) controller. The debugger connects and identifies the core, but the RAMCode fails to program.

    -------------------------------------
    J-Link: Device "ATSAME70Q21" selected.
    J-Link: Found SW-DP with ID 0x0BD11477
    J-Link: Scanning AP map to find all available APs
    J-Link: AP[1]: Stopped AP scan as end of AP map has been reached
    J-Link: AP[0]: AHB-AP (IDR: 0x04770041)
    J-Link: Iterating through AP map to find AHB-AP to use
    J-Link: AP[0]: Core found
    J-Link: AP[0]: AHB-AP ROM base: 0xE00FD000
    J-Link: CPUID register: 0x410FC271. Implementer code: 0x41 (ARM)
    J-Link: Found Cortex-M7 r0p1, Little endian.
    J-Link: FPUnit: 8 code (BP) slots and 0 literal slots
    J-Link: CoreSight components:
    J-Link: ROMTbl[0] @ E00FD000
    J-Link: ROMTbl[0][0]: E00FE000, CID: B105100D, PID: 000BB4C8 ROM Table
    J-Link: ROMTbl[1] @ E00FE000
    J-Link: ROMTbl[1][0]: E00FF000, CID: B105100D, PID: 000BB4C7 ROM Table
    J-Link: ROMTbl[2] @ E00FF000
    J-Link: ROMTbl[2][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
    J-Link: ROMTbl[2][1]: E0001000, CID: B105E00D, PID: 000BB002 DWT
    J-Link: ROMTbl[2][2]: E0002000, CID: B105E00D, PID: 000BB00E FPB-M7
    J-Link: ROMTbl[2][3]: E0000000, CID: B105E00D, PID: 000BB001 ITM
    J-Link: ROMTbl[1][1]: E0041000, CID: B105900D, PID: 000BB975 ETM-M7
    J-Link: ROMTbl[0][1]: E0040000, CID: B105900D, PID: 000BB9A9 TPIU-M7
    J-Link: Cache: Separate I- and D-cache.
    J-Link: I-Cache L1: 16 KB, 256 Sets, 32 Bytes/Line, 2-Way
    J-Link: D-Cache L1: 16 KB, 128 Sets, 32 Bytes/Line, 4-Way
    J-Link: connected to target device
    J-Link: Failed to download RAMCode.
    Failed to prepare for programming.
    Failed to download RAMCode!

    --------------------------------------------------------


    I guessed that the problem might be that the on-chip watchdog might be restting, as according to the datasheet it does run from startup. So i added the following to the Ozone project.


    Target.WriteU32 (400E1854, 0x00008000); // the WDT, bit 15 (1 - disables)
    Target.WriteU32 (400E1904, 0x00008000); // the RSWDT, bit 15 (1 - disables)


    there was then a pause of several seconds, but RAMCode download still failed.

    Now Ozone says..
    J-Link: Failed to restore target. RAMCode never stops

    and J-Link commander says.


    Erasing device (ATSAME70Q21)...
    J-Link: Flash download: Total time needed: 0.027s (Prepare: 0.025s, Compare: 0.000s, Erase: 0.001s, Program: 0.000s, Verify: 0.000s, Restore: 0.000s)

    ****** Error: Failed to restore target. RAMCode never stops

    ERROR: Erase returned with error code -5.


    So it looks like this is some compatibility problem with the version of J-Link and the ATSAME70Q21 chip.

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

  • Hello,

    Thank you for your inquiry.
    Such an issue is not known to us.
    Are you using an eval board or custom hardware?
    We tried to reproduce the issue with a "Smart SAME70 Xplained Ev. Kit" and everything was working as expected.

    For reference an Embedded Studio project with a simple hello world example for this target device is attached.
    There you will find an Ozone project as well for quick testing with your setup.
    Are you able to program the example application with Ozone?
    To test it simply open the same70_flashtest.jdebug file with Ozone and start a debug session.

    I guessed that the problem might be that the on-chip watchdog might be restting, as according to the datasheet it does run from startup. So i added the following to the Ozone project.

    This should be taken care off in our flash loader algorithm so you don't have to think about it for programming the flash.

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

  • Hi,

    Yes we did not see the problem on the Atmel dev kit either, but this is custom hardware. When we added the following to the *.jdebug file, that allowed erase and programming to be successful on our custom board.


    void TargetReset (void) {
    Target.WriteU32(0x400E1854, 0x3FFFAFFF);
    }

    This disables the onboard Atmel watchdog, i presume the Xplained Kit add a certain pin pulled low to prevent the watchdog running on startup.


    There now appears to be a different issue. 'J-Link Failed to read current instruction'.


    J-Link: connected to target device
    Target.WriteU32 (400E1854, 0x3FFFAFFF);
    J-Link: J-Link: Flash download: Bank 0 @ 0x00400000: Skipped. Contents already match
    Debug.StepOver();
    J-Link: Failed to read current instruction.

    Do you know why this would be ?, this is the very first instruction.

  • Hi,

    This disables the onboard Atmel watchdog, i presume the Xplained Kit add a certain pin pulled low to prevent the watchdog running on startup.

    That would make sense.

    There now appears to be a different issue. 'J-Link Failed to read current instruction'.


    For this case could you provide a J-Link log file?
    How to create one is described here: wiki.segger.com/Enable_J-Link_log_file

    Could you also provide us with an example project where this issue is reproducible?

    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,

    Please see attached log file, it still seems the problem is around the ROMCode.


    T386C 022:517 JLINK_EndDownload()
    -- CPU_ReadMem(4 bytes @ 0xE000ED90)
    -- CPU_ReadMem(4 bytes @ 0xE000ED94)
    -- --------------------------------------
    -- Start of determining dirty areas in flash cache
    -- End of determining dirty areas
    -- Start of preparing flash programming
    -- Calculating RAM usage
    -- RAM usage = 5884 Bytes
    -- Preserving CPU registers
    -- Preparing memory
    -- Preparing target
    ***** Error: Failed to prepare target -- End of preparing flash programming returns 0xFFFFFFFF
    (0505ms, 1000ms total)
    Files

    • JLink.zip

      (5.26 kB, downloaded 274 times, last: )

  • Hello,

    Thank you for providing the log.
    According to the log the initial programming did not succeed. This is most likely due to a not handled watchdog as the RAMCode feeds the watchdogs during runtime.
    So one of the watchdogs triggers before the RAMCode can execute.
    The SAME70 device series has actually two watchdogs running.
    One located at 0x400E1850 (which you correctly disabled) and one at 0x400E1900 called "Reinforced Safety Watchdog Timer".
    Both need to be handled/disabled otherwise the RAMCode can't execute.
    Could you try to disable both in your Ozone Script and see if the behaviour improves?

    Unfortunately I could not find any clues in the documentation about how ATMEL handles the watchdog on their eval board so I suggest to contact ATMEL in that regard how to disable the Watchdogs other than per software.

    Should disabling both watchdogs not succeed could you provide us with a reproduction scenario with the eval board?

    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,

    I just noticed that you do the watchdog register writes in the function TargetReset().
    Try using AfterTargetConnect() or AfterTargetReset() instead (depending on if you trigger a download of the application or not).
    Make sure to uncomment the function in the script.
    Does that solve the issue?

    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,

    We had a visit from the Atmel/Microchip support guys, using Atmel Studio as the interface to our J-Link, the key seems to be setting the reset method to 'core', which just resets the debug core, not 'normal' which does a whole CPU reset. This is equivalent to the J-Link 'monitor reset 2' method.

    They and we do not understand why the default 'Normal' method does not work, but method 2 'core' does. Using this method we do not have to do memory writes to disable the watchdogs either.

    Thank you for all you support.

  • Hello,

    Great to hear that you are up and running again.
    They and we do not understand why the default 'Normal' method does not work, but method 2 'core' does. Using this method we do not have to do memory writes to disable the watchdogs either.

    The difference is that a "normal" reset resets all registers to their default values. For the watchdog it means that it gets reenabled. A Core reset does not do that.
    That is why I wrote to put the two Target.Write32 calls into the AfterTargetReset() function. That way you make sure that after each reset the watchdogs stay disabled.

    We will consider this case as closed now.

    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.