This second half of the patch is proposed to clean up some GDB keep alive issues on arm7_9 targets that start up with very slow clocks. If an attempt is made to write to key registers on the processor with a slow jtag speed, GDB timeout warnings appear on the console (at least mine) when "reset halt" or "reset init" commands are issued from the gdb client:
*** BEFORE PATCH *** (gdb) monitor reset init fast memory access is disabled 2 kHz keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1026). Workaround: increase "set remotetimeout" in GDB JTAG tap: at91sam9g20.cpu tap/device found: 0x0792603f (mfg: 0x01f, part: 0x7926, ver: 0x0) target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x000000d3 pc: 0x00000000 MMU: disabled, D-Cache: disabled, I-Cache: disabled keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1027). Workaround: increase "set remotetimeout" in GDB keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1006). Workaround: increase "set remotetimeout" in GDB keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1006). Workaround: increase "set remotetimeout" in GDB keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1006). Workaround: increase "set remotetimeout" in GDB keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1004). Workaround: increase "set remotetimeout" in GDB RCLK - adaptive dcc downloads are enabled fast memory access is enabled NAND flash device 'NAND 256MiB 3,3V 8-bit' found (gdb) I added additional keep alive steps in areas that troubleshooting revealed were causing problems. I only did this however for non-fast write memory accesses. I don't think most people would be using fast memory accesses to write to memory when the jtag and system clocks are slow anyway. If you disagree with my feeling, think there is a more elegant way to handle the problem, or think the patch will cause other unforeseen problems with other targets, let me know. As you can see below, the patch does eliminate the problem on my development station and I suspect that it will benefit others. *** AFTER PATCH *** (gdb) monitor reset init fast memory access is disabled 2 kHz JTAG tap: at91sam9g20.cpu tap/device found: 0x0792603f (mfg: 0x01f, part: 0x7926, ver: 0x0) target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x000000d3 pc: 0x00000000 MMU: disabled, D-Cache: disabled, I-Cache: disabled RCLK - adaptive dcc downloads are enabled fast memory access is enabled NAND flash device 'NAND 256MiB 3,3V 8-bit' found (gdb) Gary Carlson Gary Carlson, MSEE Principal Engineer Carlson-Minot Inc. On 5/7/10 1:16 PM, "Gary Carlson" <gcarl...@carlson-minot.com> wrote: > Hi Øyvind, > > Yeah...that actually is the problem. When I run OpenOCD under GDB -- even > without breakpoints -- the problem goes away completely (naturally of > course). I have no doubt that your assessment that it is related to timing > is likely correct. > > In the absence of not being able to use GDB to solve this problem, any > suggestions on particular areas of the code to focus? > > Gary > > > On 5/4/10 9:22 PM, "Øyvind Harboe" <oyvind.har...@zylin.com> wrote: > >> Maybe it's a timing issue? Have you tried single stepping through assert >> reset? >> >> > > > _______________________________________________ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development
arm7_9_common.patch
Description: Binary data
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
