[<<][arm][>>][..]
Tue Jun 7 23:47:34 CEST 2011

OpenOCD again

Now using the SAM7S Atmel EK, I get a problem at startup.  This is
right after halt.  The mmw is the first write that resets the device.
Also if I leave it at 3000 khz, gdb doesn't want to connect.

tom@zni:~/ecos-build/bin$ ./ocd.SAM7
Open On-Chip Debugger 0.5.0-dev-00886-g6152c29 (2011-05-29-14:26)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
srst_only srst_pulls_trst srst_gates_jtag srst_open_drain
Warn : use 'at91sam7s256.cpu' as target identifier, not '0'
debug_level: 2
100 kHz
dcc downloads are enabled
fast memory access is enabled
force hard breakpoints
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
Info : clock speed 100 kHz
Info : JTAG tap: at91sam7s256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
Info : Embedded ICE version 1
Info : at91sam7s256.cpu: hardware has 2 breakpoint/watchpoint units
debug_level: 1
100 kHz
Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
target state: halted
target halted in ARM state due to debug-request, current mode: Abort
cpsr: 0x200000d7 pc: 0x000006e8
requesting target halt and executing a soft reset
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x200000d3 pc: 0x00000000
Warn : memory write caused data abort (address: 0xfffffd00, size: 0x4, count: 0x1)
in procedure 'mww'

3000 kHz
receiving debug messages from current target charmsg


Checking:
/usr/local/share/openocd/scripts/target/at91sam7sx.cfg

target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm7tdmi
$_TARGETNAME configure -event reset-init {
        soft_reset_halt
        # RSTC_CR : Reset peripherals
        mww 0xfffffd00 0xa5000004
        # disable watchdog
	mww 0xfffffd44 0x00008000
	# enable user reset
	mww 0xfffffd08 0xa5000001
	# CKGR_MOR : enable the main oscillator
	mww 0xfffffc20 0x00000601
	sleep 10
	# CKGR_PLLR: 96.1097 MHz
	mww 0xfffffc2c 0x00481c0e
	sleep 10
	# PMC_MCKR : MCK = PLL / 2 ~= 48 MHz
	mww 0xfffffc30 0x00000007
	sleep 10
	# MC_FMR: flash mode (FWS=1,FMCN=73)
	mww 0xffffff60 0x00490100
	sleep 100
}


Pfff..  If I remove the "reset init" in the startup script, it seems
to come up just fine.  Maybe that never really worked properly?  I
don't remember.

One thing is clear: it doesn't like 3000 kHz.  I thought it went
faster..  If I switch to 1000 khz, it seems to work.

So, again a buch of problems that are too confusing for me to see what
is actually going on.  I got it working on the Ubi board but the EK is
borked again.

Now I do an upload at 3000 kHz and that works:

(gdb) mon jtag_khz 3000
3000 kHz
(gdb) load
Loading section .rom_vectors, size 0x40 lma 0x100000
Loading section .text, size 0x28db8 lma 0x100040
Loading section .rodata, size 0x7930 lma 0x128df8
Loading section .data, size 0x1044 lma 0x130728
Start address 0x100040, load size 202604
Transfer rate: 8 KB/sec, 13506 bytes/write.

Let's try 6000: seems to work too.

This is weird...  Do flash uploads actually talk to the processor or
directly to the flash?

Maybe it's time to start paying attention to the CPSR.

I see several different states:

0x600000d3 (normal)
0x200000d3
0x200000d7
0x400000d3


Let's summarize:
  - uploads do work at 6000 kHz if the state is ok
  - "reset init" is not reliable: mww error immediately after soft_reset_halt


Crap.. can't add comments after a line in jim tcl!


Ha.. removing the soft_reset_halt in the init routine make the data
abort error go away.





[Reply][About]
[<<][arm][>>][..]