I'm new to OpenOCD and had it debugging out of RAM beautifully. I've been getting sporadic errors verifying binary images I write to flash. This got me interested in OpenOCD and its code. The rest of this email is a long list of issues I encountered, some of which are probably due to my own misunderstandings. I'd be happy to help in any way I can, including contributing patches, but it would be nice to have somebody orient me on some of these things first. I'd love to see OpenOCD be a robust and widely adopted tool. My setup:
OpenOCD svn version 921 built today on Cygwin Olimex ARM-USB-OCD Olimex SAM7-EX256 board with at91sam7x256 processor Default config files (see command line below) ---- This is the flash verification error that got this whole thing started. It verifies properly maybe 10% of the time. When I go through SAM-BA it's always perfect, making me think it's not a chip problem. > reset JTAG device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3) target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x600000d3 pc: 0x002058c0 > flash write_image main_flash.bin 0x00100000 bin wrote 35108 byte from file main_flash.bin in 1465.177002s (0.023400 kb/s) > verify_image main_flash.bin 0x00100000 bin checksum mismatch - attempting binary compare Verify operation failed address 0x00106e88. Was 0xe9 instead of 0xeb Trying jtag_khz settings of 100, 10, and 1 just take longer and longer to give the same error. I'm running the board from an external supply and the ARM-USB-OCD through a powered hub, but this doesn't make a difference. It often fails at 0x00106e88 or at 0x001074ab. It doesn't seem to matter if "arm7_9 dcc_downloads" is enabled or disabled. Several different MC_FMR flash mode settings (wait states and master clock cycles) were tried from examples I found on the web, all with the same results. Using the clock and flash settings that SAM-BA uses also gave same results. Increasing nsrst_delay and ntrst_delay made no difference. If it verifies once, it verifies over and over again. ---- Now some other issues. First, I can't create Wiki account -- server error. Where is the most up to date documentation? The Wiki? The doc directory? Are these synchronized? ---- Comments at the end of lines do not work in telnet, which makes pasting pieces of .cfg files in difficult. ---- Paths and command line: It seems that ideally you'd run it to use the configuration files supplied for your interface and target like this: ./openocd -f interface/olimex-arm-usb-ocd.cfg -f target/sam7x256.cfg When I build it, the executable ends up in src directory. It seems it should either end up in the top directory or end up in the src/target directory where it can find the .cfg files in interface/ and target/ directories. (Why is there a target subdirectory of target?) It should be able to find paths to interface and target directory, but both are under an "extra" target directory compared to the YAGARTO install. ---- It would be nice to have robust configuration files for all interfaces and targets that work "as is," but maybe the intention is to have these be only examples. Is the OpenOCD_scripts page on the Wiki duplicating information in svn and therefore subject to becoming out of sync (as they are)? Should this page just link to the relevant files in svn? ----- My old command-line from r717: ./openocd -f interface/olimex-arm-usb-ocd.cfg -f target/sam7x256.cfg -c init -c reset This quits. If I leave off the "-c reset", the program stays alive and I can telnet to it. This is different than how r717 behaved. I'm not sure why it should quit, especially since adding "-c reset" is suggested all over the documentation. ----- Interface config files: arm-usb-ocd.cfg and olimex-arm-usb-ocd.cfg are redundant, but different. In fact, the one starting with "olimex-" seems like it should be the preferred one, but it doesn't work. The difference is in the ft2232_device_desc: "Olimex OpenOCD JTAG A" (which works) vs "Olimex OpenOCD JTAG" (which doesn't). Even without including the " A" it still finds it (debug output below). Maybe if it only finds one device, it should assume that's the one you want to use. ... Error: 63 109 ft2232.c:1419 ft2232_init_ftd2xx(): unable to open ftdi device: 2 Error: 64 109 ft2232.c:1434 ft2232_init_ftd2xx(): ListDevices: 1 Error: 65 109 ft2232.c:1436 ft2232_init_ftd2xx(): 0: Olimex OpenOCD JTAG A ... I don't own an olimex-jtag-tiny device, but its config includes no "ft2232_vid_pid" line. The arm-usb-ocd config files don't seem to need it either (I assume you're auto-detecting or something now.) If this is the case, these lines should probably be removed to simplify all of the .cfg files. ----- The .cfg files for the chips are also non-uniform. Some atmel parts have file names that start with at91 and others just launch right into the sam7. The readme.txt file says that a target/xxx.cfg file can invoke another target/yyy.cfg file, but doesn't describe how. I'm not actually sure how it finds the sam7x256_reset.script file since I didn't include an absolute path anywhere and it had trouble finding other things. The sam7x and sam7s configurations are identical except for calling different reset scripts. But the reset scripts are identical except for extra spaces at the end of some lines (violating your style rules.) ----- When I start up and do a "flash info 0" I get an error. I think it's because the target needed to be halted: Debug: 87 9360 command.c:79 script_command(): script_command - info Debug: 88 9360 command.c:96 script_command(): script_command - info, argv[0]=ocd_flash_info Debug: 89 9360 command.c:96 script_command(): script_command - info, argv[1]=0 Debug: 90 9360 command.c:404 run_command(): Command failed with error code -304 After I halt, it works. This code -304 is ERROR_TARGET_NOT_HALTED, but other places it's actually reported back in text. ---- The info it displays looks like it could use some work: > flash info 0 #0: at91sam7 at 0x00100000, size 0x00040000, buswidth 4, chipwidth 0 #0: 0x00000000 (0x40000 256kB) protection state unknown at91sam7 information: Chip is AT91SAM7X256 cidr: 0x275b0940, arch: 0x0075, eproc: ARM7TDMI, version:0x000, flashsize: 0x00040000 master clock(estimated): 49696kHz pagesize: 256, lockbits: 16 0x0000, pages in lock region: 64 securitybit: 0, nvmbits(3): 0x4 Does the second line indicate that the same flash is also mapped to location 0x00000000? (It is, in fact, the case for me.) It says the protection state is unknown, but below it correctly displays the lockbits indicating that none of the 64 pages are protected. How is the master clock estimated? (After an erase, it gets estimated as zero.) 256 byte pagesize times 64 "pages in lock region" gives only 1/16 of the 0x40000 256kB flash size. num_pages is correct in at91sam7.c I think I'm missing something: ---- For flash, what's the difference between a bank, a sector, a plane, and a page? The flash info and flash commands do not make this clear. ---- When you do "flash banks" it doesn't know about the location and size until you do a "flash probe 0" This is not in the documentation. "flash erase_check" doesn't work -- erase state unknown "flash erase_sector 0 0 0" works "flash erase_sector 0 0 1" returns mysterious "failed erasing sectors 0 to 1 (-901)" rather than "ERROR_FLASH_SECTOR_INVALID" which it corresponds to. ---- "flash protect_check 0" returns "successfully checked protect state" but then "flash info 0" still says "protection state unknown" "flash protect 0 0 0 off" for the sam7 ---- When I manually set the lockbits by writing to the right memory address, "flash erase_sector" returns an appropriate error, but "flash info 0" still says they are not set. In fact, I need to "shutdown" and restart openocd before "flash info" will report the correct lockbits. When does this information get set? Why doesn't get it rechecked when you do another "flash info"? ---- PS I also posted this to the SparkFun forum, but it seems like it's also a development thing, and I'm willing to help write patches once my background knowledge gets cleared up.
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
