when locking the debug access fails on the first try, it's a
bit noisy, so print out message that it succeeded on second try.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Add "static" qualifier to private functions.
Move duplicated global declarations from "target/avrt.c"
and "nor/avrf.c" to "target/avrt.h".
Remove unused declarations form "nor/avrf.c".
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
normal code should not call jtag_get_error(), but rather check
the return code from jtag_execute_queue().
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
failure to write to memory was not propagated.
This is an interesting case of broken error handling:
with exceptions we wouldn't have had this at all,
and I also wonder if there is a GCC option to warn
about these kinds of potential bugs.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Parameter "type" of function armv4_5_mmu_translate_va()
is now not used.
Remove the parameter and the "enum" listing its values.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Function armv4_5_mmu_translate_va() now properly signals
errors in the return value.
Remove former error handling by setting variable "type" to
value "-1".
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Function arm920t_write_memory() default return value
should be ERROR_OK.
All cases of local errors are handled immediately and
not further propagated.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Commit 0538081246
introduces a compile time warning:
arm920t.c: In function ‘arm920t_write_memory’:
arm920t.c:567: warning: ‘retval’ may be used uninitialized in this function
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
ETM analyze produced no output when the trace buffer was empty.
This patch provides users with a clue.
Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
We request a id register read at the end of ahbap_debugport_init
but we never actually run the queue. In some cases this causes a
segfault.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
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.
There are a million reasons why cached protection state might
be stale: power cycling of target, reset, code executing on
the target, etc.
The "flash protect_check" command is now gone. This is *always*
executed when running a "flash info".
As a bonus for more a more robust approach, lots of code could
be deleted.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Various commands, e.g. "arm mcr xxxx" would fail if invoked upon startup
since it there was no command context defined for the jim interpreter
in that case.
A Jim interpreter is now associated with a command context(telnet,
gdb server's) or the default global command context.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
target memory allocation can be implemented not to show
bogus error messages.
E.g. when trying a big allocation first and then a
smaller one if that fails.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
This patch adds support for the length argument to the xscale implementation of
the wp command. Per discussion with David, the length argument specifies the
range of addresses over which a memory access should generate a debug exception.
This patch utilizes the "mask" feature of the xscale debug hardware to implement
the correct functionality of the length argument. Some limitations imposed by
the hardware are:
- The length must be a power of two, with a minumum of 4.
- Two data breakpoint registers are available, allowing for two watchpoints.
However, if the length of a watchpoint is greater than four, both registers
are used (the second for a mask value), limiting the number of watchpoints
to one.
This patch also removes a useless call to xscale_get_reg(dbcon) in
xscale_set_watchpoint() (value had already been read from the register cache,
and the same previously read value is then modified and written back).
I have been using and testing this patch for a couple days.
Questions, corrections, criticisms of course gratefully received.
