1
\$\begingroup\$

I'm trying to set up OpenOCD debugging through a JTAG port on a custom board with an Atmel ATSAM3X8E microcontroller.

OpenOCD is running on a Raspberry Pi using the bcm2835 native GPIO. The JTAG port of the SAM3X is broken out to a header - it has NRST, TCK, TMS, TDI, TDO, GND and 3.3V on it. NRST is pulled to 3.3V through 100k, while the others are directly connected.

OpenOCD comes with a target called at91sam3ax_8x.cfg which looks like it ought to be the right thing to use, but it seems to bear no resemblence to the part I'm using. That target script expects the device's TAPID to be 0x4ba00477, while the device I have reports 0x05b2b03f as its TAPID (and this matches what's in the SAM3X datasheet). Once I've fixed that, the IR check then fails (it expects 0x1 but sees 0x9). Having fixed that, this is then the output I get from OpenOCD:

Open On-Chip Debugger 0.10.0+dev-00093-g6b2acc0 (2017-03-17-16:47)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.org/doc/doxygen/bugs.html
BCM2835 GPIO config: tck = 11, tms = 25, tdi = 10, tdo = 9
BCM2835 GPIO config: srst = 7
srst_only separate srst_gates_jtag srst_push_pull connect_deassert_srst
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
adapter speed: 500 kHz
RCLK - adaptive
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m reset_config sysresetreq
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : JTAG only mode enabled (specify swclk and swdio gpio to add SWD mode)
Info : RCLK (adaptive clock speed) not supported - fallback to 10 kHz
Info : JTAG tap: sam3.cpu tap/device found: 0x05b2b03f (mfg: 0x01f (Atmel), part: 0x5b2b, ver: 0x0)
Error: Invalid ACK (7) in DAP response
Error: JTAG-DP STICKY ERROR
Error: Invalid ACK (7) in DAP response
Error: JTAG-DP STICKY ERROR
...repeated about 40 times...
Error: Could not initialize the debug port

What's going on here? Is there something wrong with my setup? Or is the AT91SAM3AX a different part to the ATSAM3X that I'm using?

\$\endgroup\$

1 Answer 1

Reset to default
-3
\$\begingroup\$

Indeed, it is different.

But at91sam3XXX.cfg in recent versions of OpenOCD explicitly lists your SAM3X8E as supported.

This is presumably already present in your installation, probably right next to the mismatching file you are using.

\$\endgroup\$
4
  • \$\begingroup\$ No. atsam3ax_8x.cfg' just sources atsam3XXX.cfg` anyway, and the version you link to, while it does indeed claim to support the SAM3X8E, still lists the TAPID as 0x4ba00477 and expects the IR to contain 0x1 as I described. This doesn't match the SAM3X datasheet. \$\endgroup\$
    – Tom
    Commented Mar 21, 2017 at 10:25
  • \$\begingroup\$ That's not quite correct - it has a default for the TAPID which will be applied if you do not specify one before sourcing it (of course each specific chip model has a unique one). And you are misinterpreting the IR specification. \$\endgroup\$
    – Chris Stratton
    Commented Mar 22, 2017 at 15:58
  • \$\begingroup\$ Yes, that's true. However, in this case the problem is that JTAGSEL is pulled high, which puts in the boundary scan mode, hence the different TAPID. I'm not sure what you mean about the IR specification - isn't this what -ircapture 0x9 means? \$\endgroup\$
    – Tom
    Commented Mar 23, 2017 at 11:22
  • \$\begingroup\$ Your JTAGSEL issues sounds like a wiring problem or at the outside an interface configuration problem, not a device script one. And it sounds like that is the real issue. Though it remains true that you should not be using a SAM3A configuration file for a SAM3X one. Likely you need to make your own which sets the correct ID before invoking the family generic file. After getting the chip in the proper state, of course. \$\endgroup\$
    – Chris Stratton
    Commented Mar 23, 2017 at 20:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.