target: slow targets could cause GDB to time out
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.
This commit is contained in:
parent
c86d7bdad4
commit
b80d0501b6
|
@ -2463,7 +2463,20 @@ int arm7_9_write_memory(struct target *target, uint32_t address, uint32_t size,
|
|||
if (arm7_9->fast_memory_access)
|
||||
retval = arm7_9_execute_fast_sys_speed(target);
|
||||
else
|
||||
{
|
||||
retval = arm7_9_execute_sys_speed(target);
|
||||
|
||||
/*
|
||||
* if memory writes are made when the clock is running slow
|
||||
* (i.e. 32 kHz) which is necessary in some scripts to reconfigure
|
||||
* processor operations after a "reset halt" or "reset init",
|
||||
* need to immediately stroke the keep alive or will end up with
|
||||
* gdb "keep alive not sent error message" problem.
|
||||
*/
|
||||
|
||||
keep_alive();
|
||||
}
|
||||
|
||||
if (retval != ERROR_OK)
|
||||
{
|
||||
return retval;
|
||||
|
@ -2499,7 +2512,20 @@ int arm7_9_write_memory(struct target *target, uint32_t address, uint32_t size,
|
|||
if (arm7_9->fast_memory_access)
|
||||
retval = arm7_9_execute_fast_sys_speed(target);
|
||||
else
|
||||
{
|
||||
retval = arm7_9_execute_sys_speed(target);
|
||||
|
||||
/*
|
||||
* if memory writes are made when the clock is running slow
|
||||
* (i.e. 32 kHz) which is necessary in some scripts to reconfigure
|
||||
* processor operations after a "reset halt" or "reset init",
|
||||
* need to immediately stroke the keep alive or will end up with
|
||||
* gdb "keep alive not sent error message" problem.
|
||||
*/
|
||||
|
||||
keep_alive();
|
||||
}
|
||||
|
||||
if (retval != ERROR_OK)
|
||||
{
|
||||
return retval;
|
||||
|
@ -2534,7 +2560,20 @@ int arm7_9_write_memory(struct target *target, uint32_t address, uint32_t size,
|
|||
if (arm7_9->fast_memory_access)
|
||||
retval = arm7_9_execute_fast_sys_speed(target);
|
||||
else
|
||||
retval = arm7_9_execute_sys_speed(target);
|
||||
{
|
||||
retval = arm7_9_execute_sys_speed(target);
|
||||
|
||||
/*
|
||||
* if memory writes are made when the clock is running slow
|
||||
* (i.e. 32 kHz) which is necessary in some scripts to reconfigure
|
||||
* processor operations after a "reset halt" or "reset init",
|
||||
* need to immediately stroke the keep alive or will end up with
|
||||
* gdb "keep alive not sent error message" problem.
|
||||
*/
|
||||
|
||||
keep_alive();
|
||||
}
|
||||
|
||||
if (retval != ERROR_OK)
|
||||
{
|
||||
return retval;
|
||||
|
|
Loading…
Reference in New Issue