zcy
/
tinyriscv-openocd
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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.
__archive__
Gary Carlson 2010-05-18 20:59:00 -07:00 committed by Øyvind Harboe
parent c86d7bdad4
commit b80d0501b6
1 changed files with 40 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
src/target/arm7_9_common.c
View File

@ -2463,7 +2463,20 @@ int arm7_9_write_memory(struct target *target, uint32_t address, uint32_t size,
if (arm7_9->fast_memory_access) if (arm7_9->fast_memory_access)
retval = arm7_9_execute_fast_sys_speed(target); retval = arm7_9_execute_fast_sys_speed(target);
else 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) if (retval != ERROR_OK)
{ {
return retval; 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) if (arm7_9->fast_memory_access)
retval = arm7_9_execute_fast_sys_speed(target); retval = arm7_9_execute_fast_sys_speed(target);
else 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) if (retval != ERROR_OK)
{ {
return retval; 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) if (arm7_9->fast_memory_access)
retval = arm7_9_execute_fast_sys_speed(target); retval = arm7_9_execute_fast_sys_speed(target);
else 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) if (retval != ERROR_OK)
{ {
return retval; return retval;