# Problem getting started with WinARM and ARM-USB-OCD **URL:** \ **Category:** MicroMod\ **Tags:** arm-lpc\ **Created:** [September 21, 2006, 10:44pm UTC](https://community.sparkfun.com/t/problem-getting-started-with-winarm-and-arm-usb-ocd/2753 "2006-09-21T22:44:26Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![vbarre](https://avatars.discourse-cdn.com/v4/letter/v/d9b06d/32.png) [@vbarre](https://community.sparkfun.com/u/vbarre)\ **Post date:** [September 21, 2006, 10:44pm UTC](https://community.sparkfun.com/t/problem-getting-started-with-winarm-and-arm-usb-ocd/2753/1 "2006-09-21T22:44:26Z")
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](http://openfacts.berlios.de/index-en.phtml?title=Open+On-Chip+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. ---
**Author:** ![vbarre](https://avatars.discourse-cdn.com/v4/letter/v/d9b06d/32.png) [@vbarre](https://community.sparkfun.com/u/vbarre)\ **Post date:** [September 22, 2006, 3:35am UTC](https://community.sparkfun.com/t/problem-getting-started-with-winarm-and-arm-usb-ocd/2753/2 "2006-09-22T03:35:29Z")
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](http://openfacts.berlios.de/index-en.phtml?title=Open+On-Chip+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. ---
**Author:** ![mlu](https://avatars.discourse-cdn.com/v4/letter/m/f07891/32.png) [@mlu](https://community.sparkfun.com/u/mlu)\ **Post date:** [September 22, 2006, 6:37am UTC](https://community.sparkfun.com/t/problem-getting-started-with-winarm-and-arm-usb-ocd/2753/3 "2006-09-22T06:37:16Z")
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 ---
**Author:** ![vbarre](https://avatars.discourse-cdn.com/v4/letter/v/d9b06d/32.png) [@vbarre](https://community.sparkfun.com/u/vbarre)\ **Post date:** [September 22, 2006, 10:21am UTC](https://community.sparkfun.com/t/problem-getting-started-with-winarm-and-arm-usb-ocd/2753/4 "2006-09-22T10:21:47Z")
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