Atmel SAM-ICE with Atmel Studio 7 debugging ATSAME54N20A

Go To Last Post
2 posts / 0 new
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On my latest board design I am using the ATSAME54N20A. I am able to connect, erase, reset and upload with the J-link commander:


SEGGER J-Link Commander V6.20h (Compiled Oct 27 2017 16:23:22)
DLL version V6.20h, compiled Oct 27 2017 16:22:47

Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM V8 compiled Aug 26 2015 15:08:21
Hardware version: V8.00
S/N: 28017444
License(s): RDI, GDB
VTref = 3.300V

Type "connect" to establish a target connection, '?' for help
Please specify device / core. <Default>: ATSAME54N20
Type '?' for selection dialog
Please specify target interface:
  J) JTAG (Default)
  S) SWD
Specify target interface speed [kHz]. <Default>: 4000 kHz
Device "ATSAME54N20" selected.

Connecting to target via SWD
Found SW-DP with ID 0x2BA01477
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
AP[1]: AHB-AP (IDR: 0x74770001)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0x41003000
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ 41003000
ROMTbl[0][0]: E00FF000, CID: B105100D, PID: 000BB4C4 ROM Table
ROMTbl[1] @ E00FF000
ROMTbl[1][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS
ROMTbl[1][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
ROMTbl[1][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
ROMTbl[1][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
ROMTbl[1][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU
ROMTbl[1][5]: E0041000, CID: B105900D, PID: 000BB925 ETM
ROMTbl[1][6]: E0042000, CID: B105900D, PID: 003BB907 ETB
Cortex-M4 identified.
Erasing device (ATSAME54N20)...
J-Link: Flash download: Total time needed: 5.111s (Prepare: 0.031s, Compare: 0.000s, Erase: 5.076s, Program: 0.000s, Verify: 0.000s, Restore: 0.003s)
J-Link: Flash download: Total time needed: 0.030s (Prepare: 0.022s, Compare: 0.000s, Erase: 0.004s, Program: 0.000s, Verify: 0.000s, Restore: 0.003s)
Erasing done.
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.


Unfortunately in the Atmel Studio 7.0 the device programming tool doesn't allow me to erase the flash before programming:


Timestamp:    2018-03-14 08:06:21.144
Severity:        ERROR
ComponentId:    20100
StatusCode:    131100
ModuleName:    TCF (TCF command: Device:erase failed.)

Timed out waiting for the chip erase to complete


Also, when I start debugging in Atmel Studio I get a "Jlink Device Override" pup-up box:

Device type is overridden in Jlink configuration settings to "ATSAME54N20".

Press Yes to continue launch and not be warned again.

Press No to cancel launch and open Jlink configuration utility.


After pressing "Yes", an error will occur (J-Link V6.20h Error):

Timeout while checking target RAM, core does not stop. (PC = 0x00000000, CPSR = 0x00000000, LR =0x00000000)!

Failed to prepare for programming.

Failed to execute RAMCode for RAM check!




Has someone a solution for this error? Is there a location where ATSAME54N20 should be selected in the Jlink configuration tool? In the SEGGER J-link control panel, under the general tab, ATSAME54N20 is shown in the box for Device.



Last Edited: Wed. Mar 14, 2018 - 04:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

not a solution, but maybe a clue.  I use Atmel ICE and my SAMD51 occasionally locks up (appears to be a spurious write protect?)

If I try a segger jlink mini edu, I get a similar core does not stop kind of message (I am 2000 miles from my hardware today, so no exact message for now...)


To unlock it I have to:

segger jlink mini in segger IDE; connect to target and chip erase (I think)

ASF 7 jlink mini; with a blank dummy project (e.g. hello world or just return;), program it.

ASF7 jlink mini or atmel ice will then work


Problem seems to occur during abnormal power down.


These are not definitive and may be a ritual with no solid basis, but it is reproducible.