When debugging an AT91SAM9260 with a SAM-ICE and the gdb-server, we cannot single step through or set a breakpoint near certain memory accesses (seem to be accesses using a non-divisible by 4 offset from a register - the target location is aligned) - it causes an incorrect value to be loaded into the register. The correct value is loaded if we just run the code without setting breakpoints or single stepping. Here is more detail:

The first case incorrectly reads 0xff00 into r0 from a gpio register.
Setting a breakpoint and then continuing was ok, but single-
stepping the ldr instruction resulting in a bad read. Single stepping
through the other cases worked properly

Case 1:
mvn r1, #2304
ldr r0, [r1, #-195]

Case 2:
mvn r1, #2304
sub r1, r1, #195
ldr r0, [r1]

Case 3:
mov r1, #0xb0000000
mov r1, r1, asr #19
ldr r0, [r1, #60]

Playing around with different ldr offsets showed that anything that wasn't a
multiple of 4 would return a shifted value.

This seems to be a problem with the GDB server, because if I use the
jlink.exe utility to single-step through Case 1, it reads the PIO correctly.

---------------------------------------------------------------
The second issue is regarding resetting the chip, since we use a particular reset mode register setting that
disables NRST and causes the Atmel reset manager to be busy doing an external reset (using NRST) for
30ms after boot. We were having a real hard time being able to terminate and relaunch a process in
the debugger, as the j-link GDB server would try to reset the chip, then complain it could not connect.
We'd have to power cycle the board. Here is a gdb init routine that I found through trial and error that
seems to be working for now.. Note that it only works if you always use this - if it's already in the bad
state I described, this won't get it out of that state, you gotta powercycle.

target remote localhost:2331
# Wait for firmware external reset to be done?
monitor sleep 500
# Enable external reset pin
monitor long 0xFFFFFD08 0xA5000001
monitor reset
monitor speed 30
monitor speed auto
# Disable watchdog
monitor long 0xfffffd44 0xa0008000

Thanks for the quick response. We will give it a try and post the results!

Confirmed that 3.79h fixes the erroneous memory read issue we were seeing. Thanks!

Still troubled by the reset issue, as our workaround is apparently fragile - I'm working with the engineer who's got the issue today, I'll post if we figure out more details.

Thanks again,
-brad

We eventually solved our problems with reset, via a lengthier GDB script. Two issues were: we were bringing the bus clock down to 16khz (half the slow clock) at one point before we activated the PLL, which caused intermittent failures with the couple bus accesses that happened during that time. Made sure we switched to the main oscillator before we programmed the prescaler. And secondly, Atmel doesn't seem to have a reset mechanism that brings their peripheral (non-ARM) registers to sane values. We tried all your reset types (0,1,2...). Their boot ROM code resets things it seems, but that doesn't help if you're debugging by loading right into RAM, booting off directly accessible flash, or doing a warm reset. With a warm reset, you'd need to disable and clear all interrupts before resetting at a minimum, and we needed to do this via direct memory access commands in our gdb init script. Now everything seems to work great!

Thought I'd share the conclusions in case the info might help someone else out!
Thanks,
-brad