[OpenOCD-user] Help debugging with an Atmel AT91SAM3X8E ARM Cortex-M3

[R. D. <rdi...@ya...>]

Hi all:

I recently ordered an Arduino Due, which sports an Atmel AT91SAM3X8E 
(with an ARM Cortex-M3 core), and I am trying to set up a stable GDB 
debugging environment over JTAG, see here for more information about my 
environment (OS, versions, config files, etc):

   http://arduino.cc/forum/index.php/topic,153583.0.html

Since I posted that message I have got a little further, but I still 
need some help with the JTAG reset.

The CPU has some sort of hidden bootloader called SAM-BA, which probably 
has some secret encryption key inside, so I expect I won't be able to 
see what is inside. I thought that might interfere with debugging, but 
as far as I understand, you can disable the bootloader and start 
directly from the first flash bank.

I have managed to flash new firmware over JTAG, but I cannot reset the 
CPU and let it stop at the first instruction (at the reset vector). When 
I type "monitor soft_reset_halt" in GDB, it does reset the CPU, but it 
looks like the ARM core runs for a little while before OpenOCD is able 
to stop it. I have also tried "monitor reset halt" and "monitor reset 
init" to no avail.

Setting a hardware breakpoint right at the beginning before resetting 
the CPU does not help, it just gets ignored. When the CPU finally stops, 
the "info reg" display is also wrong, especially the $pc. If I quit GDB 
and restart it, the CPU does not move in the mean time, but "info reg" 
displays the real values the second time around.

I have read that such ARM cores slow down to 32 KHz upon reset. I am 
using a Bus Pirate as a JTAG adapter at the moment, and I think it works 
at a fixed 700 KHz frequency and cannot slow down. Of course it has no 
support for JTAG "adaptive clocking" or anything fancy.

I have also been looking at OpenOCD's documentation about option 
"reset_config", but I cannot work out what settings I need. The JTAG 
reset signal is connected to the general reset line on the board, so all 
other chips get reset too. I guess I need option "srst_only", but I 
don't understand the other options well enough to be able to tell if 
they are applicable for this chip and board.

Can anyone tell me whether the ARM core can be talked to over JTAG while 
the JTAG adapter is asserting the JTAG Reset signal (pin 10 on the 
10-pin JTAG connector)? I read that some CPUs support this, but others 
do not. During that time that reset is asserted, should I expect the 
core to use the slow 32 KHz system clock in order to sample the JTAG 
signals?

Does anybody know if this CPU supports stopping at the first instruction 
upon JTAG reset at all? Can someone confirm if this is possible with any 
of the expensive, proprietary JTAG debuggers?

If I cannot reset properly, I guess I could issue a "monitor halt" and 
then manually reset the CPU from GDB. I would probably need to reset the 
$pc and disable interrupts. Could someone give me some script to achieve 
this? I haven't found any good examples yet. Or is it just not possible 
to reset the CPU reliably this way? I guess the CPU peripherals cannot 
be reset so easily this way.

I need to reliably reset the CPU because I have experienced often that 
stopping the CPU, flashing a new firmware with JTAG (with GDB's 'load' 
command) and then letting it run tends to make it hang. Afterwards, no 
matter what I try with GDB, I cannot get it to run properly. However, if 
I press the reset button, then the firmware starts fine, so the firmware 
itself must have been correctly flashed over JTAG.

Many thanks in advance,
   rdiez