Hi all:

I am trying to set up a stable GDB debugging environment over JTAG with the Arduino Due, but I'm having no luck. I am confused by the error messages, and the documentation does really not help. I have found more information on the Web, but I haven't managed to make it work yet.

Has anybody got JTAG working yet? Could you share your configuration files?

I am using a Bus Pirate as the JTAG adapter, the configuration file is:

interface buspirate
buspirate_port /dev/buspirate
buspirate_speed normal ;# or fast

voltage regulator Enabled = 1 Disabled = 0

#buspirate_vreg 0

pin mode normal or open-drain

#buspirate_mode normal

pullup state Enabled = 1 Disabled = 0

#buspirate_pullup 0

this depends on the cable, you are safe with this option

reset_config srst_only
adapter_khz 10

I am not sure what settings are the right ones above, but it seems to detect the device OK.

I am on Ubuntu 12.04, and I am using the latest git version of OpenOCD (0.7.0-dev), with a standard configuration file for the Atmel chip on the Arduino Due: -f target/at91sam3XXX.cfg

By the way, I don't know whether these OpenOCD commands are necessary, or whether they should come before or after the at91sam3XXX.cfg file:

gdb_memory_map enable
gdb_flash_program enable

I tried with and without them, and there seems to be no difference.

I am using the toolchain that comes with the Arduino environment, version 1.5.2.

When I start OpenOCD, I get these messages:

Open On-Chip Debugger 0.7.0-dev-00079-g08ddb19-dirty (2013-02-26-10:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Warn : Adapter driver 'buspirate' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
srst_only separate srst_gates_jtag srst_open_drain
adapter speed: 10 kHz
adapter speed: 500 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : Buspirate Interface ready!
Info : Want to set speed to 500kHz, but not implemented yet
Error: Translation from jtag_speed to khz not implemented
Info : adapter-specific clock speed value 500
Info : JTAG tap: sam3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : sam3.cpu: hardware has 6 breakpoints, 4 watchpoints

Then, when I connect with GDB, this is what I have tried so far:

target remote :3333

I get this on OpenOCD's console:

Info : accepting 'gdb' connection from 3333
Warn : acknowledgment received, but no packet pending
undefined debug reason 6 - target needs reset

The target does not stop. I have another embedded target from another type, and it does stop when you connect with GDB.

Then I tried this on GDB's console:

set remotetimeout 1000
target remote :3333
monitor halt

If I enter "monitor reset halt", instead of "monitor halt", I get this error:

in procedure 'reset'
Info : JTAG tap: sam3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: sam3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : Halt timed out, wake up GDB.
Error: timed out while waiting for target halted
TARGET: sam3.cpu - Not halted

With "monitor halt", I get a reassuring message:

target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x81000000 pc: 0x000805d4 msp: 0x20087fe8

I can now issue a "monitor reset halt", and the output looks like this:

JTAG tap: sam3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x81000000 pc: 0x0008036c msp: 0x20087fe8

No matter what I do, I haven't managed to reset the CPU and make it stop at the reset vector address (0x00000004). This is important in order to start debugging from scratch. Otherwise, the CPU has already executed a bit of code before you try to debug.

If I enter the 'load' command, this is what I get:

Loading section .text, size 0x3a80 lma 0x80000
Loading section .relocate, size 0x9c lma 0x83a80
Start address 0x80124, load size 15132
Transfer rate: 2 KB/sec, 7566 bytes/write.

This is interesting, as I am using linker script file "hardware/arduino/sam/variants/arduino_due_x/linker_scripts/gcc/flash.ld" which comes with Arduino 1.5.2, and that specifies the flash address as 0x00080000, which matches the .text section above. However, it looks like the flash memory is not been written to, as the old program ('sketch') transferred with the Arduino environment remains there.

Is there a way to verify that the program data bytes has been properly written to flash?

Can anybody help with any of the questions above?

Many thanks in advance,
rdiez

Hi rdiez,

just examined your post, which is rather old now.
There is surprisingly no feedback at all.
Did you ever succeed with your project?

I have a similar issue with setting up openOCD for Arduino Uno and Leonardo
and looking for existing solutions for these commonly used boards.
So far I didn't find any existing cfg-files for Arduino.

Can you help?
Thanks, sepp2gl

Uno doesn’t have jtag at all, and the commands used over jtag for Leonardo are proprietary and not documented, so I don’t think either one can be used with openocd.

Personally,

1. Enable debug in the Platform.txt i.e. add -g
2. Add a Post-Build in Platform.txt to Copy the ELF file to a known directory.
3. connect a JTAG / SWD debugger to the Due.
4. Debug the Arduino built ELF in Rowley Crossworks or Atmel Studio 7.0 or even Keil UV5

I am sure that you can debug any ELF file with most of the popular ARM IDEs

You can do exactly the same with any SAMD chips. Or STM32.

David.

@david_prentice:
thanks for your kind proposal for solution.
Unfortunately I guess, that westfw is right:
Leonardo is powered by an ATmega32u4 AVR-chip, that provides an ISP-interface but not JTAG.
So avarice might be the tool of choice rather than openOCD.
If your proposal goes along with ISP-based debugging, I will nevertheless give it a try.

thanks again, sepp2gl

This is a Due Forum. The Original Post is clearly about Due and JTAG.

The Leonardo is a different board. Leonardo specific questions should be on the general Arduino Forums.
It uses a ATmega32U4 which has a JTAG interface but it is disabled.

If you can afford to lose the JTAG pins from your Arduino project, you can enable JTAG and debug the 32u4 in the normal way.
Either as standalone .CPP project in AS7.0
Or by debugging the externally built .ELF file as I described in #3.
Unfortunately, AS7.0 is fairly crap for debugging the externally built .ELF for an AVR.

David.

JTAG is essentially a hardware-level communications interface. It's only "vaguely" a "software debugging" interface. Essentially, you can use JTAG hardware to send particular commands to the "debug unit" of your microcontroller, but the actual debug commands are CPU/Chip/etc specific.
For ARM chips, there is a standard debug module that is part of the ARM specification, implemented by nearly all chip vendors, and highly documented, enabling programs like OPENOCD to implement substantial swaths of useful functions.

For AVR chips, the debug commands are proprietary, so this is next to impossible. There are some Atmel debuggers for which there is software that implements functionality similar to OpenOCD, in that it will allow gdb "remote" protocols access to AVR internals (AVRaICE)

You can probably think of the AVR debug unit as "common" to most AVRs, with different hardware (SWD, UPDI, JTAG) used to do the actual interface, each having somewhat different characteristics (Speed, number of pins, etc) But since it's undocumented, it's hard to tell for sure.

Personally, I have never worried about how the IDE works under the hood.

I just expect to be able to use Breakpoints, single-step, examine variables, classes, structs, in a HLL.
And examine, manipulate machine level registers.

I have used JTAG, SWD, PDI, UPDI, debugWIRE, ...
The HLL experience is exactly the same. The machine level access and display varies greatly with different IDEs.

Different IDEs offer different visual displays e.g. Rowley, Eclipse, Keil, ...
Configure your chosen IDE to suit your personal taste.

Modern language compilers can provide lots of debug information. You need to tell them how much to include. Arduino IDE tends to remove the debug information by default. It also hides the files so that humans can't find them.

Yes, I know that some people like to use OpenOCD at the lowest level possible. And obfuscate any views of source code or registers.

David.

@david_prentice:
you got me...I searched for openOCD, which led me here. I didn't realize, that this is for DUE and other SAM-boards.
Actually at that time I even wasn't aware, that LEONARDO might be different with respect to debugging.

A couple of weeks ago I purchased an Atmel-ICE for debugging of Arduino under Linux.
At this moment I can do uploads/downlads and fuse-programming with it using avrdude.
I will continue climbing up the learning curve with Atmel-ICE under Linux, but for future projects I might consider SAM-based boards.

thx again for this discussion, it helped a lot
sepp2gl

AS7.0 is a Windows program. You would have to run it in a Virtual Machine.

Microchip MPLABX should run on Linux. However it is not really operational with all AVRs yet. I am sure it will get there in the end.

I find Eclipse absolutely horrible. If you are happy with Eclipse it should be possible to use it with AVRs. I am not brave enough.

What sort of applications do you want to debug?
Personally, I tend to use the Arduino IDE. If I have a problem with a vanilla Arduino sketch, I debug it on a STM32 Nucleo target. (it has Arduino headers and an onboard debugger)

I suspect that you have chosen the Leonardo for USB. Whereas high level Arduino functionality should be similar on STM32, SAM, SAMD, ... the machine level code will be very different.
So you will probably need to debug on the AVR.

David.

...in fact, my application would have done with UNO,
but I needed to have two serial interfaces; one for USB, the other for the Nextion Touchscreen.
As SoftwareSerial proved to scrap for fast communication conflicting interrupts, I selected LEO as next bext choice.

My application is a throttle-body synchronizer for motorbikes.
The sample-rate is 1ms, so software uses Timer3Compare and ADC interrupts.
All HMI is performed via Nextion. Most time I spent debugging the UNO with SoftwareSerial before I realized, that it won't ever work. All that with debug-messages via USB. I'd rather use the Atmel-ICE.
Another issue: Linux Arduino compiler/linker does not succeed to build the software, whereas Win7-Arduino does.
On the other hand, Win7_Arduino does not recognize LEO for upload, whereas Linux Arduino would, if building was possible.
So for the moment I have quite some challenges to tackle.

My building process is a little complicated for the moment:

1. edit and build the source on Win7-Arduino Laptop
2. edit and compile Nextion-HMI on Win7-Laptop
3. Filezilla-sftp hexfiles (with bootloader) to Linux
4. upload hexfile to LEO using Atmel-ICE and avrdude on Linux
5. debugging on Linux

I agree with eclipse, especially if you have an "all-in" configuration.
Sloeber-IDE is pretty good as stand-alone special purpose Arduinoclipse.

In addition I made some attempts with AS7, but I find it somehow overloaded with support function.
Consequently I have some trouble finding the menu to add some include directories and library directories.

With the Throttle-Synch project I am close to completion now, so I focus on this rather than fixing the toolchain.
Nevertheless the Linux-toolchain will be my next prio.

cus, sepp2gl

I would try to stick with one machine and one Operating System.
Mind you, It is practical to keep the project on GitHub. And use whichever PC is convenient at the time.

I am happy enough with Rowley (or Keil) for ARM. And AS7 for AVR.

I have not touched the (STM32) Eclipse in two years. It has probably improved over this period.
I need to be convinced by an experienced Eclipse, Sloeber, ... user before I attempt it again.

So I can understand your struggle with AS7. But since AS7 is where you get the best AVR support, it is worth persevering.

David.

I am happy enough with Rowley (or Keil) for ARM. And AS7 for AVR.

Which ones can do reasonable debugging starting from a .elf file produced by Arduino?
I've always been pretty dis-satisfied with the way AS handles this (at least on AVR)

I will make a comparison between Rowley, Keil, AS7. Probably with an Arduino M0 Pro.

Then I will repeat for the SAM3X. Using ATMEL-ICE, PICkit4, ... which are regular CMSIS-DAP.

In theory, a $3 STLINK-V2 dongle should work too. So if the previous experience is good, I will try this with Rowley and Keil.

I only have Evaluation licence for Keil. So there will be size restrictions.
I have a hobbyist licence for Rowley. Size is no problem.
Obviously AS7 is the only option that is free.

I have not attempted any SAM projects with MPLABX yet.

David.

p.s. debugging an Arduino generated AVR .ELF was not good. From memory Class data from C++ was not displayed properly. I might try again.
Debugging an externally generated .COF file is quite reasonable for C. G++ is the only C++ compiler for AVR. (I think)

I built an .ELF file for M0 Pro (No Boot) and copied to a known directory.

I opened the .ELF as "Open Object File for Debugging" in AS7.0.1931 with SAMD21G18A

I can insert Breakpoints and watch simple variables.
It appears to recognise Classes but does not display members correctly.

If I open the .ELF as "Externally Built Executable" in Rowley CrossWorks v3.7.7.2017051100.31927
it works fairly well. I can navigate through Classes with accurate display of the members.

I am fairly sure that Keil would be able to "open" the .ELF but I don't see how to create the relevant project.

My conclusion is: AS7.0 is not worth using for externally built C++ executables

If you want to debug SAMD21 or SAM3X, you will have to compile directly in AS7.0 from source code.

There is no point in investigating STLINK-V2 since AS7.0 will never support STLINK protocol.

David.