Please include a debug_level 3 log. This will tell me the origin of the error.
> > And then retry. > > > flash erase_address 0x00000000 0x00070000 > error erasing flash bank, status: 0xa2 > failed erasing sectors 0 to 6 (-902) > Runtime error, file "?", line 1: > error erasing flash bank, status: 0xa2 > failed erasing sectors 0 to 6 (-902) > > In procedure 'flash' called at file "?", line 1 > In procedure 'unknown' called at file "?", line 1 > In procedure 'flash_erase_address' called at file "?", line 1 > > > flash protect 0 0 2 off > cleared protection for sectors 0 through 2 on flash bank 0 > > > flash erase_address 0x00000000 0x00030000 > erased address 0x00000000 length 196608 in 5.485549s > > Finally. > > > Now I'd like to just point out two things: > > - it's difficult to find out what to do, since the user interface > doesn't explain the problems (what do the error codes mean, for > example?) The error codes are not part of the user interface. They are sometimes used to communicate specific failures internally. If you do not get a human-readable error message as the origin, then there is a bug in OpenOCD, as errors should be logged at the lowest level where they are reported. Additional context is logged as the stack is unwound. I've committed a change that will avoid a false error message in the case that there is a bug for error message not being logged when writing to the target fails. Take it for a spin. > > - then there is an oddity: > > > > flash info 1 > #1: str9x at 0x00080000, size 0x00008000, buswidth 0, chipwidth 0 > #0: 0x00000000 (0x2000 8kB) protected > #1: 0x00002000 (0x2000 8kB) protected > #2: 0x00004000 (0x2000 8kB) protected > #3: 0x00006000 (0x2000 8kB) protected > str9x flash driver info > > flash erase_address 0x00000000 0x00030000 > erased address 0x00000000 length 196608 in 5.485549s > > flash info 0 > #0: str9x at 0x00000000, size 0x00080000, buswidth 0, chipwidth 0 > #0: 0x00000000 (0x10000 64kB) protected > #1: 0x00010000 (0x10000 64kB) protected > #2: 0x00020000 (0x10000 64kB) protected > #3: 0x00030000 (0x10000 64kB) protected > #4: 0x00040000 (0x10000 64kB) protected > #5: 0x00050000 (0x10000 64kB) protected > #6: 0x00060000 (0x10000 64kB) protected > #7: 0x00070000 (0x10000 64kB) protected > str9x flash driver info > > Why are those sectors still listed as protected? You'll need to include debug_level 3 log. I've committed some more error propagation fixes to str9x. > > > Also, is the "BUG: keep_alive() was not invoked .." message really a > bug? It also happens when I issue > > (gdb) monitor reset halt > jtag_khz: 16 > JTAG device found: 0x04570041 (Manufacturer: 0x020, Part: 0x4570, Version: > 0x0) > JTAG device found: 0x25966041 (Manufacturer: 0x020, Part: 0x5966, Version: > 0x2) > JTAG device found: 0x2457f041 (Manufacturer: 0x020, Part: 0x457f, Version: > 0x2) > target state: halted > target halted in ARM state due to debug request, current mode: Supervisor > cpsr: 0x000000d3 pc: 0x00000000 > BUG: keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet > not sent! (1091) The problem here is that some part of the the reset sequence takes a long time without keep_alive() being called. This will cause alive packets to be sent to GDB so as to avoid weird error messages as below. again: debug_level 3 log will point out *where* the keep_alive() call is missing as the debug_level 3 log contains time for each logged statement. > > > Also, if (after a restart of everything) I connect to openocd with > "gdb someimage.elf", openocd prints: > > Info: accepting 'gdb' connection from 0 > waiting for target halted... > Error: timed out while waiting for target halted > Warning:acknowledgment received, but no packet pending > Warning:target not halted > Warning:target not halted > > Is this error serious? Yes. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
