Debug Arduino Due, via JTAG

Ok, so I’m trying to debug the ATSAM3X8E with a Atmel-ICE, via the JTAG port. I tried to use openocd with the following config file:

interface cmsis-dap
set CHIPNAME at91sam3X8E
source [find target/at91samdXX.cfg]

Then I ran the following command (terminal a): openocd

Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
none separate
adapter speed: 400 kHz
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 400 kHz
Info : SWD DPIDR 0x2ba01477
Info : atsam3X8E.cpu: hardware has 6 breakpoints, 4 watchpoints

So far so good. Now I opened a second terminal (terminal b) and executed the following: arm-none-eabi-gdb -iex "target extended-remote localhost:3333"

With the following Output in terminal a:

Info : accepting 'gdb' connection on tcp/3333
Info : SWD DPIDR 0x2ba01477
Error: Failed to read memory at 0x4100201c
Error: Couldn't read Device ID register
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.
Error: attempted 'gdb' connection rejected

If I get something totally wrong please tell me where it should be, thanks. If there is another way to debug the MCU, please also tell me the right way.


I preface this answer by saying thet I never debugged anything on this MCU with a Atmel-ICE, via the JTAG port. However you have this thread to get started with the Atmel-ICE:

And as always, Sam3x datasheet may help (pages 29 and 220).

A good tool for debugging (if you can't afford a good scope) could be a Salae logic:

plus debug serial prints and break points e.g.:
#define DEBUG_VAL2(x,y) printf(#x" = %d\n",y)
//#define DEBUG_VAL2(x,y)

For USB 2.0 enumeration, a Beagle Protocol analyzer should be a good choice.

Well, maybe I should mention that I don't have a problem connecting the atmel-ICE with the arduino due via JTAG. I looked into the post you mentioned, and it seems kinda unrelated. Furthermore that was 2012/2013, I think (hope) some things changed by now.

Ok, I found the exact problem I had and solved it following the instructions from this post:

You can debug a Due with any ARM debugger e.g. ATMEL-ICE, PicKit4, SNAP, JLINK, STLinkV2, ...

Obviously Atmel Studio will only support Microchip manufactured debuggers.
But Keil, Rowley, ... do not care whose parts they use.

In the days when Atmel debuggers were expensive it was attractive to use a $3 STLinkV2
Now that SNAP is cheap, you can just buy SNAP and still use AS7.0.


I'm failing to debug the Due with an ST-Link V3 using OpenOCD. Switching to SWD works but then the probe disconnects with "NoJTagDeviceFound". Do you have any hints?

I am familiar with Keil and Rowley. I have free evaluation UV5 and hobbyist-licensed Rowley Crossworks.

I have built and debugged Due with Keil and with Rowley. Either with CMSIS-DAP or STLinkV2 dongle.
My STM32 Nucleo or Discovery targets have onboard STLinkV2. They are not V3.

If you use OpenOCD I suggest that you start with targets you are familiar with.
Then swap debugger hardware e.g. CMSIS-DAP, STLink, JLink, ...

Repeat with the SAM3X target. Both with JTAG and SWD interface.

Manufacturer-sponsored IDEs make it difficult to use different hardware.
Keil, Rowley, support most targets, debuggers, ...


openocd worked fine on other targets. Including semihosting.

Thank a lot for your suggestion to use the STLinkV2 of the Discovery - this worked out of the box!

I just didn't expect the V3 to have a worse target support >:(

I can finally just compile/run/debug/semihost any Rust program on the Arduino Due.

Invest in a $3 STLINK-V2 dongle. Much neater than a Discovery on the desk.

I can't remember the V3 features but none of my existing Nucleo or Disco boards are suitable for V3 upgrade.

V2 is obviously fine for programming. V2 is pretty good for debugging. V3 adds some extra debug features.

Manufacturers are getting wise to tying users in to their products.
If you have the genuine ST V3 dongle you might be able to downgrade to V2 via the regular ST utility.
And restore to V3 whenever you want. I suspect that OpenOCD will make a fix soon.