Pages: [1]   Go Down
Author Topic: Help with OpenOCD JTAG debugging  (Read 1163 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 4
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Pages: [1]   Go Up
Jump to: