OpenOCD too slow...

Development Boards MicroMod
1

Hi,

I’m a new bie in ARM programming and OpenOCD is veeeery slow on my machine reguardless wether I’m debugging in RAM (about 300 bytes/s) or flashing (don’t remember exactly but I think around 700 bytes/s). I’ve tryed 2 different pods: IAR J-Link and usbprog and both are slow (usbprog is a little bit slower)… It takes a couple of mins to upload my code in RAM in the debugger… My target is the AT92sam7s-EK (with at91sam7s256 MPU). Here is my openocd.cfg:

---------------------------------- openocd.cfg (usbprog) -----------------------------------

telnet_port 4444

gdb_port 3333

gdb_memory_map disable

interface usbprog

jtag_speed 0

reset_config srst_only

Target is an AT91SAM7:

jtag newtap at91sam7s cpu -irlen 4 -ircapture 0x1 -irmask 0xf

The target

target create at91sam7s.cpu arm7tdmi -endian little -chain-position at91sam7s.cpu-variant arm7tdmi

at91sam7s.cpu configure -work-area-virt 0 -work-area-phys 0x00200000 -work-area-size 0x4000 -work-area-backup 0

flash bank at91sam7 0 0 0 0 0

---------------------------------- openocd.cfg (J-Link) -----------------------------------

telnet_port 4444

gdb_port 3333

gdb_memory_map disable

interface jlink

jtag_speed 0

reset_config trst_and_srst srst_pulls_trst

Target is an AT91SAM7:

jtag newtap at91sam7s cpu -irlen 4 -ircapture 0x1 -irmask 0xf

The target

target create at91sam7s.cpu arm7tdmi -endian little -chain-position at91sam7s.cpu-variant arm7tdmi

at91sam7s.cpu configure -work-area-virt 0 -work-area-phys 0x00200000 -work-area-size 0x4000 -work-area-backup 0

flash bank at91sam7 0 0 0 0 0

The script I use with GDB to upload and debug my code in RAM is:

---------------------------------- debug.script -----------------------------------

AT91SAM7Sxx debug programming script.

target remote :3333

set remotetimeout 1000

monitor gdb_breakpoint_override hard

load

I have the hardware setup at work but I can post the output of openOCD tomorrow if needed… Does anyone have an idea why opne OCD is so slow?

Thanx in advance :slight_smile:

2

Hi (again),

This is the output of openOCD with usbprog:

Open On-Chip Debugger 1.0 (2009-01-19-10:10) svn:unknown

BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS

$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $

jtag_speed: 0

usb_set_debug: Setting debugging level to 10 (on)

usb_os_init: Found USB VFS at /dev/bus/usb

usb_os_find_busses: Found 007

usb_os_find_busses: Found 006

usb_os_find_busses: Found 005

usb_os_find_busses: Found 004

usb_os_find_busses: Found 003

usb_os_find_busses: Found 002

usb_os_find_busses: Found 001

usb_os_find_devices: Found 001 on 007

usb_os_find_devices: Found 002 on 006

usb_os_find_devices: Found 001 on 006

error obtaining child information: Inappropriate ioctl for device

usb_os_find_devices: Found 016 on 005

skipping descriptor 0x0

skipped 1 class/vendor specific endpoint descriptors

Descriptor data still left

usb_os_find_devices: Found 001 on 005

error obtaining child information: Inappropriate ioctl for device

usb_os_find_devices: Found 001 on 004

usb_os_find_devices: Found 076 on 003

skipped 1 class/vendor specific interface descriptors

skipped 1 class/vendor specific interface descriptors

usb_os_find_devices: Found 032 on 003

skipped 1 class/vendor specific interface descriptors

skipped 1 class/vendor specific interface descriptors

usb_os_find_devices: Found 031 on 003

usb_os_find_devices: Found 001 on 003

error obtaining child information: Inappropriate ioctl for device

error obtaining child information: Inappropriate ioctl for device

usb_os_find_devices: Found 001 on 002

usb_os_find_devices: Found 116 on 001

usb_os_find_devices: Found 001 on 001

error obtaining child information: Inappropriate ioctl for device

Info : USB JTAG Interface ready!

Info : JTAG tap: at91sam7s.cpu tap/device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3)

Warn : Unexpected idcode after end of chain! 480 0x800000ff

Warn : Unexpected idcode after end of chain! 512 0x0000007f

Warn : Unexpected idcode after end of chain! 544 0x000000ff

Warn : Unexpected idcode after end of chain! 576 0x000000ff

Warn : Unexpected idcode after end of chain! 608 0x000000ff

Warn : no tcl port specified, using default port 6666

This is openOCD output when I debug in RAM:

Info : accepting ‘gdb’ connection from 0

target state: halted

target halted in ARM state due to debug-request, current mode: Abort

cpsr: 0xd00000d7 pc: 0x00000010

Warn : acknowledgment received, but no packet pending

force hard breakpoints

Info : dropped ‘gdb’ connection - error -400

Info : accepting ‘gdb’ connection from 0

Warn : acknowledgment received, but no packet pending

3

Hello! My processor is at91sam7s64…

grisou:
Hi,

openocd.cfg (J-Link)

Sorry, but when I using your config file, openocd shows me:

Open On-Chip Debugger 1.0 (2009-04-01-00:53) svn:1435
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
jtag_speed: 0
Runtime error, file "openocd.cfg", line 13:
    -chain-position required when creating target

How to fix that error? Where I can get information about configuration file structure?

When I delete all text after “# The target” - it shows me this:

Open On-Chip Debugger 1.0 (2009-04-01-00:53) svn:1435
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
jtag_speed: 0
Error: J-Link command EMU_CMD_VERSION failed (-110)
Error: J-Link command EMU_CMD_VERSION failed (112)
Info : J-Link compiled Jun 14 2007 14:36:33 ARM Rev.5
Info : Vref = 3.274 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 1 TRST = 1
Info : J-Link JTAG Interface ready
Info : JTAG tap: at91sam7s.cpu tap/device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3)

So, my adapter is working and processor also working…

Please, help me, how to get it working…

P.P.S.

All hardware is 100% working. My OS - Linux.

4

Sorry about the late answer… been buzy at work lately… I still have some unresolved speed issues with at91sam7s512 or any at91sam7s for that matter…

Your openocd doesn’t seem to like comments (#)…

You’ll find some more info about the structure of the cfg-files at: http://openocd.berlios.de/web/?page_id=54

I can send you my cfg files if you want… but you’ll probably have to adapt them to the at91sam7s64…

I’m also running Linux… Do you also have speed issues (It takes me 5 min to upload 60K of code into RAM and about the samt to flash)?

5

grisou:
I’m also running Linux… Do you also have speed issues (It takes me 5 min to upload 60K of code into RAM and about the samt to flash)?

No, I dont have problems with speed… because it does not work at all =))) :wink:

PS

Please, subscribe to this topic by email notifications… You can choose this mode when posting reply… “Notify me when a reply is posted”

6

Try this config file:

---------------------------------- openocd.cfg (J-Link) -----------------------------------

telnet_port 4444

gdb_port 3333

gdb_memory_map disable

interface jlink

jtag_speed 0

reset_config trst_and_srst srst_pulls_trst

jtag newtap at91sam7s cpu -irlen 4 -ircapture 0x1 -irmask 0xf

target create at91sam7s.cpu arm7tdmi -endian little -chain-position at91sam7s.cpu-variant arm7tdmi

at91sam7s.cpu configure -work-area-virt 0 -work-area-phys 0x00200000 -work-area-size 0x4000 -work-area-backup 0

flash bank at91sam7 0 0 0 0 0

you’ll probably have to change these 2 lines to conform to the at91sam7s64:

jtag newtap at91sam7s cpu -irlen 4 -ircapture 0x1 -irmask 0xf

at91sam7s.cpu configure -work-area-virt 0 -work-area-phys 0x00200000 -work-area-size 0x4000 -work-area-backup 0

Good luck

7

I forgot…

I use gdb to upload the code into the cpu: here is my debug (ram) script file

target remote :3333
monitor fast enabled
set remotetimeout 1000
set mem inaccessible-by-default off

monitor mww 0xfffffd44 0x00008000       # disable watchdog
monitor mww 0xfffffd08 0xa5000001       # enable user reset
monitor mww 0xfffffc20 0x00000601       # CKGR_MOR : enable the main oscillator(18.432MHz)
monitor sleep 100
monitor mww 0xfffffc2c 0x00481c0e       # CKGR_PLLR: 96.1097 MHz(18.432MHz/14*(72+1))
monitor sleep 100
monitor mww 0xfffffc30 0x00000007       # PMC_MCKR : MCK = PLL / 2 = 48 MHz
monitor sleep 100

monitor arm7_9 sw_bkpt enable
monitor arm7_9 fast_memory_access enable
monitor arm7_9 dcc_downloads disable

monitor gdb_breakpoint_override hard

monitor gdb_memory_map enable

#monitor arm7_9 force_hw_bkpts enable

load

and the flash script

# AT91SAM7Sxx flash programming script. 
target remote :3333
set remotetimeout 1000

monitor reset halt
monitor soft_reset_halt

monitor gdb_memory_map enable
monitor gdb_flash_program enable
monitor arm7_9 dbgrq enable

# speed up memory downloads
monitor arm7_9 dcc_downloads enable 

monitor armv4_5 core_state arm

## Enable fast mem access (clocks > 32kHz): 
monitor arm7_9 fast_memory_access enable

## Init - taken form the script openocd_at91sam7_ecr.script
monitor mww 0xffffff60 0x00320100       # set flash wait state (AT91C_MC_FMR)
monitor mww 0xfffffd44 0x00008000       # disable watchdog
monitor mww 0xfffffd08 0xa5000001       # enable user reset
monitor mww 0xfffffc20 0x00000601       # CKGR_MOR : enable the main oscillator(18.432MHz)
monitor sleep 100
monitor mww 0xfffffc2c 0x00481c0e       # CKGR_PLLR: 96.1097 MHz(18.432MHz/14*(72+1))
monitor sleep 100
monitor mww 0xfffffc30 0x00000007       # PMC_MCKR : MCK = PLL / 2 = 48 MHz
monitor sleep 100

monitor flash protect 0 0 31 off
monitor flash erase_sector 0 0 31
monitor flash write_image bin/D-METER-flash.bin 0x00100000 bin
#monitor flash write_image D-METER-flash.bin 0x00100000 bin

monitor flash protect 0 0 31 on

monitor mdw 0x00100000 0x100

monitor mww 0xfffffd08 0xa5000401 		# enable user reset

monitor reset

quit

good luck

8

ok, thank you :slight_smile:

9

Hello,

This is not a problem of OpenOCD, it is a speed problem of

the usbprog. I have achieve up to 165KByte/sec downloading

into RAM.

If you want to know how I have tested, take a look here:

http://www.yagarto.de/projects/jtagspeed/index.html

The test was done with a FT2232 device and a STR710 CPU.

Regards,

mifi

10

But I have about the same speed with the J-Link as well, so I don’t think it’s a usbprog problem… I even tested both J-TAGS on 2 different computers (@ work and @ home) running linux… and the same problem… I suspect either a bug in openOCD or something wrong with my cfg-file… but I cannot find wht’s wrong… I can send a log file or something if you want…

11

I also get this in my log could this be my problem?

Info : 59 23 jtag.c:1607 jtag_examine_chain(): JTAG tap: at91sam7s.cpu tap/device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3)

Warn : 60 23 jtag.c:1590 jtag_examine_chain(): Unexpected idcode after end of chain! 480 0x800000ff

Warn : 61 23 jtag.c:1590 jtag_examine_chain(): Unexpected idcode after end of chain! 512 0x0000007f

Warn : 62 23 jtag.c:1590 jtag_examine_chain(): Unexpected idcode after end of chain! 544 0x000000ff

Warn : 63 23 jtag.c:1590 jtag_examine_chain(): Unexpected idcode after end of chain! 576 0x000000ff

Warn : 64 23 jtag.c:1590 jtag_examine_chain(): Unexpected idcode after end of chain! 608 0x000000ff

12

Can anyone send me a working openOCD cfg file for at91sam7s512 I can try…

and most important a working gdb script for debugging in RAM/ROM…

I suspect that my gdb script file does not init the CPU at the correct speed…

here is it:

target remote :3333
monitor fast enabled
set remotetimeout 1000
set mem inaccessible-by-default off

monitor mww 0xfffffd44 0x00008000       # disable watchdog
monitor mww 0xfffffd08 0xa5000001       # enable user reset
monitor mww 0xfffffc20 0x00000601       # CKGR_MOR : enable the main oscillator(18.432MHz)
monitor sleep 100
monitor mww 0xfffffc2c 0x00481c0e       # CKGR_PLLR: 96.1097 MHz(18.432MHz/14*(72+1))
monitor sleep 100
monitor mww 0xfffffc30 0x00000007       # PMC_MCKR : MCK = PLL / 2 = 48 MHz
monitor sleep 100

monitor gdb_memory_map enable
load
13

Hello,

Can anyone send me a working openOCD cfg file for at91sam7s512 I can try…

and most important a working gdb script for debugging in RAM/ROM…

Take a look here:

http://www.yagarto.de/howto/yagarto1/index.html#htu

Here you can find a S256 file.

Regards,

mifi

14

Hi,

Thanks for the link :-)… I’ve tried it and I can load the code in RAM a little faster (around 1K/s instead of 300b/s)… But the new problem now is that I can not control the CPU… “cont”, “step” etc in gdb does not work anymore…

here is the output of gdb:

Loading section .fixed, size 0x6da0 lma 0x200000
Ignoring packet error, continuing...            
Ignoring packet error, continuing...            
Start address 0x200070, load size 28064
Ignoring packet error, continuing...
Transfer rate: 1 KB/sec, 14032 bytes/write.
Breakpoint 1 at 0x2049f4: file src/main.c, line 133.
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
warning: Invalid remote reply:
warning: Invalid remote reply:
warning: Invalid remote reply:
warning: Invalid remote reply:
warning: Invalid remote reply:
warning: Invalid remote reply:
15

Try running the jtag interface slower, this might increase speed.

slow interface → no errors → high effective speed

In the first config you used jtag_speed 0, this is for usbprog (ft2232 ) the same as jtag_khz 6000, and then the target must have a configured high speed clock.

Out of reset the AT91SAM7S uses a 32kHz low speed clock, so test with jtag_khz 10, real slow, if this works increase it.

The JLink support is unreliable, but there is currently a lot of work to fix this.

Regards,

Magnus

16

I’ve tried decreasing the speed and it didn’t help … :cry:

17

Interesting numbers. thanks for posting,

Why can’t anyone build u-boot, no source ? normaly, you try to find where they branched off, and start updating from here. I did it for the mini2440 arm board, it’s not “trivial” and it usualy needs jtag, but it’s not impossible…

I need to order a couple of plug’s myself :smiley:

18

I use jlink to upload file to SMP8634 and I got the 200 BPS only. jlink has memory read/write function for ARM7/9, but I do not know why it will be so slow to move data to MIPS base processor. Does it have any chance to improve the upload speed?

19

I agree with you steve… It shouldn’t take so long time… And it’s not related to the debugger device since it is the case with both JLink and usbprog… I gave up on openocd for flashing and I use sam7utils (http://oss.tekno.us/sam7utils) to flash the device and I debug the program with openocd… It was a bit tricky for me to compile it but once I did it worked like a charm :slight_smile:

Hope tis will help you

20

I agree with you steve… It shouldn’t take so long time… And it’s not related to the debugger device since it is the case with both JLink and usbprog… I gave up on openocd for flashing and I use sam7utils (http://oss.tekno.us/sam7utils) to flash the device and I debug the program with openocd… It was a bit tricky for me to compile it but once I did it worked like a charm :slight_smile:

Hope tis will help you