I tried a device reset after reflashing twice, and dump_image still gives the wrong data. I restarted OpenOCD and things appeared ok. (In the source I used, I added my own fix for the write truncation problem whose fix is likely the patch I listed below, but that should only affect what is written to flash.) Here's my test case:
Two telnet sessions (place where connection was closed was when I exited OpenOCD) jeremy@BFS-linux-desktop:~$ telnet localhost 4444 Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger > reset init JTAG tap: k60.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00001080 msp: 0x20010000 > flash erase_sector 1 1 1 Probing flash info for bank 1 erased sectors 1 through 1 on flash bank 1 in 0.015910s > flash write_image test 0x40800 Probing flash info for bank 0 wrote 20 bytes from file test in 0.018148s (1.076 KiB/s) > dump_image test_copy 0x40800 20 dumped 20 bytes in 0.004213s (4.636 KiB/s) > flash write_image erase test1 0x40800 auto erase enabled wrote 2048 bytes from file test1 in 0.038265s (52.267 KiB/s) > dump_image test1_copy 0x40800 21 dumped 21 bytes in 0.004187s (4.898 KiB/s) > reset init JTAG tap: k60.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00001080 msp: 0x20010000 > dump_image test1_copy2 0x40800 21 dumped 21 bytes in 0.003776s (5.431 KiB/s) > Connection closed by foreign host. jeremy@BFS-linux-desktop:~$ telnet localhost 4444 Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger > reset init JTAG tap: k60.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00001080 msp: 0x20010000 > dump_image test1_copy3 0x40800 21 dumped 21 bytes in 0.003060s (6.702 KiB/s) > File contents test: testing here ok tes test1: abcdefghijklmnopqrst test_copy: testing here ok tes test1_copy (identical to test file except with 1 more byte, which is 0xff): testing here ok tes<0xff> test1_copy2 (identical to test file except with 1 more byte, which is 0xff): testing here ok tes<0xff> test1_copy3: abcdefghijklmnopqrst Thanks for the response, Jeremy D -----Original Message----- From: Mathias K. [mailto:[email protected]] Sent: Thursday, August 23, 2012 2:53 AM To: Jeremy Dwyer Cc: [email protected] Subject: Re: [OpenOCD-devel] Weird Kinetis mdw/dump_image behavior Hello, did you get the same behavior with a device reset and not the openocd restart? Maybe some effects with the datacache? Regards, Mathias On 22.08.2012 23:12, Jeremy Dwyer wrote: > I noticed some weird things with mdw and dump_image using the TWR-K60N512. I noticed that if I > flash two different files in the same area in the same OpenOCD session in succession, I noticed with > dump_image that the flash appeared like I wrote the flash with the first binary, and not the > second. If I ctrl+c the OpenOCD session, and restart it, the flash appears like it should with mdw > and dump_image, with the second image properly written. Any advice on this? > > My question on the Kinetis write truncation appears to be answered by the patch here: > http://openocd.zylin.com/#/c/738/4 > > Jeremy D ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
