Wednesday, May 23rd 2018, 11:09am UTC+2

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

yumbrad

Beginner

Date of registration: Dec 21st 2007

Posts: 6

1

Friday, December 21st 2007, 6:37am

GDB-server/J-Link issues (one maybe solved)

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

SEGGER - Tobias

Super Moderator

Date of registration: Nov 27th 2007

Posts: 21

2

Friday, December 21st 2007, 8:41pm

Hello,

We have analyzed and fixed the single step problem.

A new beta version in which this problem is solved is
available for download from our website:

http://www.segger.com/download_jlink_beta.html

Can you please download this version
and confirm that the problem is sovled ?

Regarding the reset problem we will take a look
at it and then we will get back to you.

Best regards and happy holidays,

Tobias

yumbrad

Beginner

Date of registration: Dec 21st 2007

Posts: 6

3

Friday, December 21st 2007, 10:09pm

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

yumbrad

Beginner

Date of registration: Dec 21st 2007

Posts: 6

4

Wednesday, December 26th 2007, 9:54pm

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

yumbrad

Beginner

Date of registration: Dec 21st 2007

Posts: 6

5

Thursday, December 27th 2007, 10:56pm

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

MikeQ

Beginner

Date of registration: Dec 3rd 2007

Posts: 16

6

Friday, December 28th 2007, 11:02pm

Hi Brad,

there should be a way to properly reset the CPU.
The first thing you need to do is set the speed to either adaptive or 5kHz since the CPU starts at 32kHz;
after that, a Reset with Zero delay should work.

We had a similar problem on a SAM7S and something like

monitor speed 5 // Slow speed so we can work with 32KHz
monitor reset 0 0 // Halt CPU with 0 delay
monitor MemU32 0xfffffd00 = a5000004 // Reset peripherals ... Note that a5000005 may also work (resets also CPU, MMU, caches)
... // Set up PLL
monitor speed adaptive

fixed it. (Without comments, I am not sure they work)
In general, performing a RESET using 0xFFFFFD00 (for CPU and peripherals) should be the best solution once the CPU is halted.
If the MMU is enabled and a non-flat mapping (virtual memory != phys. memory) is used, then the MMU may need to be disabled.
However, something along that line (see above) should work fine.

Can you give it a shot and post results ?

--Mike