Problem getting started with WinARM and ARM-USB-OCD

Development Boards MicroMod
1

I am new to ARM and just trying now to program an Olimex SAM7-MT256 board with WinARM tools (including openOCD) and the ARM-USB-OCD programmer.

In the programming phase, I get some communication going on, then the green LED on the ARM-USB-OCD becomes amber and nothing more seems to happen.

Config file:

#daemon configuration

telnet_port 4444

gdb_port 3333

#interface

interface ft2232

ft2232_device_desc “Olimex OpenOCD JTAG A”

ft2232_layout “olimex-jtag”

ft2232_vid_pid 0x15BA 0x0003

jtag_speed 0

jtag_nsrst_delay 200

jtag_ntrst_delay 200

#use combined on interfaces or targets that can’t set TRST/SRST separately

reset_config srst_only srst_pulls_trst

#jtag scan chain

#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

jtag_device 4 0x1 0xf 0xe

#target configuration

daemon_startup reset

#target

#target arm7tdmi

target arm7tdmi little run_and_halt 0 arm7tdmi

run_and_halt_time 0 30

For more information about the configuration files, take a look at:

http://openfacts.berlios.de/index-en.ph … p+Debugger

Log file from OpenOCD:

Programming with OPENOCD

C:\Program Files\openocd-2006re93\bin\openocd-ftd2xx.exe -d3 -f at91r40008_armusbocd.cfg

Info: openocd.c:82 main(): Open On-Chip Debugger (2006-08-31 15:00 CEST)

Debug: jtag.c:1209 jtag_init():

Debug: ft2232.c:941 ft2232_init(): ‘ft2232’ interface using FTD2XX with ‘olimex-jtag’ layout

Debug: ft2232.c:1010 ft2232_init(): current latency timer: 2

Debug: ft2232.c:1253 olimex_jtag_init(): 80 08 1b

Debug: ft2232.c:1296 olimex_jtag_init(): 82 09 0f

Debug: ft2232.c:224 ft2232_speed(): 86 02 00

Debug: jtag.c:247 jtag_call_event_callbacks(): jtag event: 1

Debug: jtag.c:1095 jtag_reset_callback():

Debug: jtag.c:247 jtag_call_event_callbacks(): jtag event: 1

Debug: jtag.c:1095 jtag_reset_callback():

Debug: openocd.c:98 main(): jtag init complete

Debug: arm7_9_common.c:655 arm7_9_assert_reset(): target->state: unknown

Debug: jtag.c:247 jtag_call_event_callbacks(): jtag event: 0

Debug: jtag.c:1095 jtag_reset_callback():

Debug: jtag.c:247 jtag_call_event_callbacks(): jtag event: 1

Debug: jtag.c:1095 jtag_reset_callback():

Warning: arm7_9_common.c:679 arm7_9_assert_reset(): srst resets test logic, too

Debug: jtag.c:247 jtag_call_event_callbacks(): jtag event: 0

Debug: jtag.c:1095 jtag_reset_callback():

Debug: jtag.c:247 jtag_call_event_callbacks(): jtag event: 1

Debug: jtag.c:1095 jtag_reset_callback():

Debug: ft2232.c:718 olimex_jtag_reset(): trst: 0, srst: 1, high_output: 0x03, high_direction: 0x0f

Debug: ft2232.c:718 olimex_jtag_reset(): trst: 0, srst: 1, high_output: 0x03, high_direction: 0x0f

Debug: arm7_9_common.c:718 arm7_9_deassert_reset(): target->state: reset

Debug: jtag.c:247 jtag_call_event_callbacks(): jtag event: 2

Debug: jtag.c:1095 jtag_reset_callback():

Debug: ft2232.c:718 olimex_jtag_reset(): trst: 0, srst: 0, high_output: 0x09, high_direction: 0x0f

Debug: openocd.c:102 main(): target init complete

Debug: openocd.c:106 main(): flash init complete

Debug: gdb_server.c:1115 gdb_init(): gdb service for target arm7tdmi at port 3333

Debug: embeddedice.c:156 embeddedice_read_reg_w_check(): 1

Debug: jtag.c:247 jtag_call_event_callbacks(): jtag event: 3

Debug: jtag.c:1095 jtag_reset_callback():

Debug: arm7_9_common.c:781 arm7_9_halt(): target->state: running

Debug: embeddedice.c:252 embeddedice_write_reg(): 9: 0xffffffff

Debug: embeddedice.c:252 embeddedice_write_reg(): 11: 0xffffffff

Debug: embeddedice.c:252 embeddedice_write_reg(): 12: 0x00000100

Debug: embeddedice.c:252 embeddedice_write_reg(): 13: 0x000000f7

Debug: embeddedice.c:156 embeddedice_read_reg_w_check(): 1

Debug: arm7_9_common.c:619 arm7_9_poll(): DBGACK set, dbg_state->value: 0x19

Debug: embeddedice.c:252 embeddedice_write_reg(): 0: 0x00000005

Debug: embeddedice.c:252 embeddedice_write_reg(): 12: 0x00000000

Debug: arm7_9_common.c:911 arm7_9_debug_entry(): target entered debug from Thumb state

Debug: arm7_9_common.c:915 arm7_9_debug_entry(): r0_thumb: 0x0001a677, pc_thumb: 0x000001e4

Debug: arm7_9_common.c:938 arm7_9_debug_entry(): target entered debug state in Supervisor mode

Debug: arm7_9_common.c:949 arm7_9_debug_entry(): thumb state, applying fixups

Debug: arm7_9_common.c:974 arm7_9_debug_entry(): r0: 0x0001a677

Debug: arm7_9_common.c:974 arm7_9_debug_entry(): r1: 0x00400000

Debug: arm7_9_common.c:974 arm7_9_debug_entry(): r2: 0x000e0000

Debug: arm7_9_common.c:974 arm7_9_debug_entry(): r3: 0x00200048

Debug: arm7_9_common.c:974 arm7_9_debug_entry(): r4: 0x00000063

Debug: arm7_9_common.c:974 arm7_9_debug_entry(): r5: 0x0000000c

Debug: arm7_9_common.c:974 arm7_9_debug_entry(): r6: 0x00000000

Debug: arm7_9_common.c:974 arm7_9_debug_entry(): r7: 0x00000800

Debug: arm7_9_common.c:974 arm7_9_debug_entry(): r8: 0x00000040

Debug: arm7_9_common.c:974 arm7_9_debug_entry(): r9: 0x00010000

Debug: arm7_9_common.c:974 arm7_9_debug_entry(): r10: 0x00000000

Debug: arm7_9_common.c:974 arm7_9_debug_entry(): r11: 0x82008000

Debug: arm7_9_common.c:974 arm7_9_debug_entry(): r12: 0x00001000

Debug: arm7_9_common.c:974 arm7_9_debug_entry(): r13: 0x0020ffa4

Debug: arm7_9_common.c:974 arm7_9_debug_entry(): r14: 0x0000034d

Debug: arm7_9_common.c:974 arm7_9_debug_entry(): r15: 0x000001de

Debug: arm7_9_common.c:980 arm7_9_debug_entry(): entered debug state at PC 0x1de

Debug: target.c:442 target_call_event_callbacks(): target event 0

Any hint to help me get started will be appreciated.

2

I finally made some advances in the resolution of my problems. I realized that my config file was missing vital parts under the WinARM approach, and that I needed the supplementary script file oocd_flash_sam7.script.

So the revised config is now:

#daemon configuration

telnet_port 4444

gdb_port 3333

#interface

interface ft2232

ft2232_device_desc “Olimex OpenOCD JTAG A”

ft2232_layout “olimex-jtag”

ft2232_vid_pid 0x15BA 0x0003

jtag_speed 0

jtag_nsrst_delay 200

jtag_ntrst_delay 200

#use combined on interfaces or targets that can’t set TRST/SRST separately

reset_config srst_only srst_pulls_trst

#jtag scan chain

#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

jtag_device 4 0x1 0xf 0xe

#target configuration

daemon_startup reset

#target

#target arm7tdmi

target arm7tdmi little run_and_init 0 arm7tdmi_r4

target_script 0 reset oocd_flash_sam7.script

run_and_halt_time 0 30

working_area 0 0x00200000 0x4000 nobackup

flash bank at91sam7 0 0 0 0 0

For more information about the configuration files, take a look at:

http://openfacts.berlios.de/index-en.ph … p+Debugger

OpenOCD now goes a longer way and stumbles on

Debug: at91sam7.c:246 at91sam7_wait_status_busy(): status: 0x30005

Error: at91sam7.c:250 at91sam7_wait_status_busy(): status register: 0x30005

Error: at91sam7.c:252 at91sam7_wait_status_busy(): Lock Error Bit Detected, Operation Abort

This means that lock bits 0 and 1 are locked in my board (probably by the preinstalled software by Olimex), and I have now to find a way to unlock these bits with OpenOCD. Solutions are welcome.
3

Hello

You are correct, the default bootloader, SAM-BA, installed by ATMEL does protcet the first

two flash regions. The command to unprotect them is

flash protect 0 0 1 off

You can test things by not running oocd_flash_sam7.script automatically

but starting openocd and then from another command window running

telnet localhost 4444

Then you can simply enter the comnmands interactively.

also try:

flash info 0

and look at the line with lockbits information, if it is

pagesize: 128, lockbits: 16 0x0003, pages in lock region: 32

then lockbits 0 and 1 are set and the command above will fix it.

Regards

Magnus

4

Thanks Magnus, this worked perfectly and I was able to program my first ARM project with this setup : a magnificent blinking led !

I will now attack my next project, which is to interface the board to a C3188A CMOS Camera module. The plan is as follows:

  • remove the 27 MHz crystal from the camera module

  • program the camera as slave through the I2C interface

  • feed my own clock (at 12 MHz =1/4 the processor clock), and synchronized vsync an hsync built from 3 pwm channels of the AT91

  • in this way, the frame rate will be completely predictable, without resorting to interrupts

  • grab live a portion of the picture in internal RAM (reserve about 50k for that): I figured that for QVGA resolution, I have 8 processor clocks available to transfer each pixel to ram.

This way, a full image can be grabbed in several 50k passes. For autonomous robotic projects, a single pass will probably provide enough information to be useful, or the main robot processor can ask the AT91 for consecutive or targeted passes, with or without some useful post-processing by the AT91.

Custom small robot vision is coming!

Michel