Hi! > 63a23e6fc862b94f00e0833ab474bd02901a019f is the first bad commit > commit 63a23e6fc862b94f00e0833ab474bd02901a019f > Author: Spencer Oliver <[email protected]> > Date: Thu Aug 16 11:05:47 2012 +0100 > > target: remove unused working area 'user' field > > working_area::user has never been used so lets remove it. > > Change-Id: I1200311b34248549c1fe30c9f675e6129b7bebee > Signed-off-by: Spencer Oliver <[email protected]> > Reviewed-on: http://openocd.zylin.com/781 > Tested-by: jenkins > Reviewed-by: Freddie Chopin <[email protected]> > > :040000 040000 21a1f55fd50f255203e29d33cb73d5cd53ac8175 > e3d38874825972a64a92dc104dd17ed87cac36f0 M src
Today when working with LPC1769 and 0.6.0 I noticed a strange problem. When debugging using GDB mostly everything works fine. When you flash the chip it also works fine. The thing that fails is the SECOND flashing of the chip (all using GDB). After that flashing the chip is stuck in bootloader. Restarting GDB (without flashing) works fine. All subsequent flashing via GDB will fail, until you restart OpenOCD - then ONE flashing will work. The problem does not occur for STM32 ); > Open On-Chip Debugger 0.6.0 (2012-09-07-10:48) > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.sourceforge.net/doc/doxygen/bugs.html > Info : only one transport option; autoselect 'jtag' > adapter_nsrst_delay: 200 > jtag_ntrst_delay: 200 > adapter speed: 10 kHz > adapter speed: 100 kHz > trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain > Info : clock speed 100 kHz > Info : JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: > 0xba00, ver: 0x4) > Info : lpc1768.cpu: hardware has 6 breakpoints, 4 watchpoints > Info : accepting 'gdb' connection from 3333 > Warn : acknowledgment received, but no packet pending > undefined debug reason 6 - target needs reset > Info : JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: > 0xba00, ver: 0x4) > target state: halted > target halted due to debug-request, current mode: Thread > xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc > Info : Padding image section 0 with 4 bytes > Warn : Verification will fail since checksum in image (0x00003b8d) to be > written to flash is different from calculated vector checksum (0xeffe4a1a). > Warn : To remove this warning modify build tools on developer PC to inject > correct LPC vector checksum. > Info : dropped 'gdb' connection > Info : accepting 'gdb' connection from 3333 > Warn : acknowledgment received, but no packet pending > Info : JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: > 0xba00, ver: 0x4) > target state: halted > target halted due to debug-request, current mode: Thread > xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc > Error: timed out while waiting for target halted > Warn : lpc2000 prepare sectors returned 4259928 > Error: failed erasing sectors 0 to 16 > Error: flash_erase returned -902 > Warn : stepi ignored. GDB will now fetch the register state from the target. > Error: JTAG-DP STICKY ERROR > Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc > Error: JTAG-DP STICKY ERROR > Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc > Warn : Block read error address 0xfffffff8 > Error: JTAG-DP STICKY ERROR > Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc > Error: JTAG-DP STICKY ERROR > Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc > Warn : Block read error address 0xfffffff8 I can also trigger this behavior with telnet: > Open On-Chip Debugger >> reset init > JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, > ve > r: 0x4) > target state: halted > target halted due to debug-request, current mode: Thread > xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc >> flash write_image erase d:/f.hex > auto erase enabled > Padding image section 0 with 4 bytes > Verification will fail since checksum in image (0x00003b8d) to be written to > fla > sh is different from calculated vector checksum (0xeffe4a1a). > To remove this warning modify build tools on developer PC to inject correct > LPC > vector checksum. > wrote 98304 bytes from file d:/f.hex in 29.693359s (3.233 KiB/s) >> reset init > JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, > ve > r: 0x4) > target state: halted > target halted due to debug-request, current mode: Thread > xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc >> flash write_image erase d:/f.hex > auto erase enabled > Padding image section 0 with 4 bytes > timed out while waiting for target halted > lpc2000 prepare sectors returned 126 > failed erasing sectors 0 to 16 > in procedure 'flash' >> It also fails for small files: > Open On-Chip Debugger >> reset init > JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, > ve > r: 0x4) > target state: halted > target halted due to debug-request, current mode: Thread > xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc >> flash write_image erase d:/g.hex > auto erase enabled > Verification will fail since checksum in image (0x00000559) to be written to > fla > sh is different from calculated vector checksum (0xefffe476). > To remove this warning modify build tools on developer PC to inject correct > LPC > vector checksum. > wrote 4096 bytes from file d:/g.hex in 1.867187s (2.142 KiB/s) >> reset init > JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, > ve > r: 0x4) > target state: halted > target halted due to debug-request, current mode: Thread > xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc >> flash write_image erase d:/g.hex > auto erase enabled > Verification will fail since checksum in image (0x00000559) to be written to > fla > sh is different from calculated vector checksum (0xefffe476). > To remove this warning modify build tools on developer PC to inject correct > LPC > vector checksum. > lpc1768.cpu -- clearing lockup after double fault > lpc2000 returned 130 > error writing to flash at address 0x00000000 at offset 0x00000000 > in procedure 'flash' >> It fails for both 32- and 64-bit version. It fails for both ft2232 and mpsse drivers. The commit that is supposedly broken and the fact that it works for STM32 makes me think that it's some hidden bug in LPC17xx flashing code /; You can do multiple flashings without reset and it works fine. When you reset it fails to the point that in telnet I cannot even start the target: > Open On-Chip Debugger >> halt >> flash write_image erase d:/g.hex > auto erase enabled > Verification will fail since checksum in image (0x00000559) to be written to > fla > sh is different from calculated vector checksum (0xefffe476). > To remove this warning modify build tools on developer PC to inject correct > LPC > vector checksum. > wrote 4096 bytes from file d:/g.hex in 1.962890s (2.038 KiB/s) >> flash write_image erase d:/g.hex > auto erase enabled > Verification will fail since checksum in image (0x00000559) to be written to > fla > sh is different from calculated vector checksum (0xefffe476). > To remove this warning modify build tools on developer PC to inject correct > LPC > vector checksum. > wrote 4096 bytes from file d:/g.hex in 1.912110s (2.092 KiB/s) >> reset halt > JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, > ve > r: 0x4) > target state: halted > target halted due to debug-request, current mode: Thread > xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc >> flash write_image erase d:/g.hex > auto erase enabled > Verification will fail since checksum in image (0x00000559) to be written to > fla > sh is different from calculated vector checksum (0xefffe476). > To remove this warning modify build tools on developer PC to inject correct > LPC > vector checksum. > lpc1768.cpu -- clearing lockup after double fault > lpc2000 returned 14 > error writing to flash at address 0x00000000 at offset 0x00000000 > in procedure 'flash' >> resume > lpc1768.cpu -- clearing lockup after double fault > target state: halted > target halted due to debug-request, current mode: Handler HardFault > xPSR: 0x00000003 pc: 00000000 msp: 0x100000b4 > Polling target failed, GDB will be halted. Polling again in 100ms > Polling succeeded again >> resume > lpc1768.cpu -- clearing lockup after double fault > target state: halted > target halted due to debug-request, current mode: Handler HardFault > xPSR: 0x00000003 pc: 00000000 msp: 0x100000b4 > Polling target failed, GDB will be halted. Polling again in 100ms > Polling succeeded again >> reset halt > JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, > ve > r: 0x4) > target state: halted > target halted due to debug-request, current mode: Thread > xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc >> reset init > JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, > ve > r: 0x4) > target state: halted > target halted due to debug-request, current mode: Thread > xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc >> resume >> halt > target state: halted > target halted due to debug-request, current mode: Thread > xPSR: 0xa1000000 pc: 0x1fff0ba4 msp: 0x10007fb8 >> Any ideas? Can anyone reproduce? 4\/3!! ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
