Cortex-M uses only 2 byte breakpoint instruction.
cortex_m_unset_breakpoint() does not need to check breakpoint->length,
use the length as the size argument in target_write_memory()
Change-Id: I20bb869f6abce2fc61f0469e34a638bc4dc6f7ce
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4889
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
Reviewed-by: Jānis Skujenieks <janis.skujenieks@gmail.com>
Reviewed-by: Christopher Head <chead@zaber.com>
The code for this command is currently replicated in cortex_a and
in mips_m4k and is going to be added again for cortex_m.
Plus, it is going to be obsoleted by the HW thread pseudo RTOS.
Consolidate in smp.c a single instance of the command. This will
simplify both obsoleting it and adding it to cortex_m, whatever
change comes first.
Change-Id: I03cd857e21fa3f7202fdcee36bcbd5aae30a609d
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/4991
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
Seams over-engineered having two separate commands to turn SMP
on/off. Plus it is missing the possibility to dump the current
status of SMP and would be weird adding an additional command
for it. Moreover, such commands are replicated in few targets so
it would make sense centralizing them.
- Deprecate the commands "smp_on" and "smp_off".
- Add a new command "smp" that accepts optional parameters
"[on|off]" and prints the SMP status when run without
parameters. This replaces the two commands above.
- Put the deprecated and the new command handlers in smp.c
- Update the documentation, except for mips_m4k, since it is not
available yet.
- Promote the macro foreach_smp_target to global context and use
it where possible.
Change-Id: Ia72841c1a3bd6edd4db4cc809046322f498617e6
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/4615
Tested-by: jenkins
Reviewed-by: Graham Sanderson <graham.sanderson@gmail.com>
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
This represents months of continuing RISC-V work, with too many changes
to list individually. Some improvements:
* Fixed memory leaks.
* Better handling of dbus timeouts.
* Add `riscv expose_custom` command.
* Somewhat deal with cache coherency.
* Deal with more timeouts during block memory accesses.
* Basic debug compliance test.
* Tell gdb which watchpoint hit.
* SMP support for use with -rtos hwthread
* Add `riscv set_ir`
Change-Id: Ica507ee2a57eaf51b578ab1d9b7de71512fdf47f
Signed-off-by: Tim Newsome <tim@sifive.com>
Reviewed-on: http://openocd.zylin.com/4922
Tested-by: jenkins
Reviewed-by: Philipp Guehring <pg@futureware.at>
Reviewed-by: Liviu Ionescu <ilg@livius.net>
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
These macros are missing parenthesis around the argument, which can
lead to side effects, add them. Replace the argument name to avoid
conflict with uint32_t data type, since the macro can be applied to
other data types as well.
Change-Id: I32d2ffec6c062795d7c8bb23d1dfa3378bfc3a58
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Reviewed-on: http://openocd.zylin.com/4994
Tested-by: jenkins
Reviewed-by: Freddie Chopin <freddie.chopin@gmail.com>
Write to register DP_SELECT can fail, but both functions
swd_queue_dp_bankselect() and swd_queue_ap_bankselect() return
void and do not propagate the error.
Change the return type of the two functions to int and check the
returned value.
Invalidate the cached value of DP_SELECT if the write fails.
Change-Id: Iba6ef8b0c2332e7f7efb66337d558fb7a4a0d39c
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/4980
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
When the register DP_SELECT is written directly, e.g. with command
<dap> dpreg 8 <value>
the cached value in OpenOCD is not completely updated with the new
value, thus creating issues in the following AP and DP read/write
that rely on the cached value.
Update the cached value while writing to DP_SELECT.
Change-Id: I8221b10cd6fc1fbe73e6b834b68820b43480e1a2
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/4979
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Targets can use this to expose how many address bits there are.
gdb_server uses this to send gdb the appropriate upper limit in the
memory-map. (Before this change the upper limit would only be correct
for 32-bit targets.)
Change-Id: Idb0933255ed53951fcfb05e040674bcdf19441e1
Signed-off-by: Tim Newsome <tim@sifive.com>
Reviewed-on: http://openocd.zylin.com/4947
Tested-by: jenkins
Reviewed-by: Peter Mamonov <pmamonov@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
If the function aarch64_target_create() exits for an error, the
value of pointer aarch64 get lost, causing a memory leak.
Move the allocation of aarch64 after the check on the parameters.
While there, add a check on the value returned by calloc().
Issue highlighted by clang 7.0.0.
Change-Id: Ib9ad27f4acd940da308c01fdbf33cfe51ab0c639
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/4924
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
If the function mem_ap_target_create() exits for an error, the
value of pointer mem_ap get lost, causing a memory leak.
Move the allocation of mem_ap after the check on the parameters.
While there, add a check on the value returned by calloc().
Issue highlighted by clang 7.0.0.
Change-Id: Ia2c11b14fde9694f28bf6efe01d278923db0f0d4
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/4923
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
If the function cortex_a_target_create() or the function
cortex_r4_target_create() exit for an error, the value of pointer
cortex_a get lost, causing a memory leak.
Move the allocation of cortex_a after the check on the parameters.
While there, add checks on the value returned by calloc().
Issue highlighted by clang 7.0.0.
Change-Id: Ic6eeb9c3b39922d016f6d0319eada1a97a6681f0
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/4925
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
handle_bp_command_set() showed the error message
"Failure setting breakpoint, the same address(IVA) is already used"
on any error returned from (xxx_)breakpoint_add().
Paradoxically breakpoint_add() returned ERROR_OK if it detected
duplicated bp address.
context_breakpoint_add() and hybrid_breakpoint_add() returned -1
instead of OpenOCD compatible error if they detected duplicity.
Introduce ERROR_TARGET_DUPLICATE_BREAKPOINT
Unify error handling to LOG_ERROR() any error in (xxx_)breakpoint_add()
Remove misleading error messages from handle_bp_command_set()
handle_bp_command_set() returns error if the target does not implement
add_context_breakpoint or add_hybrid_breakpoint.
Change-Id: If17dfad1756d82a77028ebdc4b305f9c8e1365ba
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4871
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
Fix "Potential leak of memory pointed to by 'cortex_m'"
and test for NULL return from calloc in cortex_m_target_create()
Change-Id: I4d2bb5bccc57f0ed60696f3d588297a858b8ea60
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4881
Tested-by: jenkins
Reviewed-by: Moritz Fischer <moritz.fischer@ettus.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Fix the write only out params TODO on armv7m.c
Fix conditional move depends on uninitialised value.
It was detected while programming a LPC8Nxx with a FTDI adapter.
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes
[...]
==8696== Conditional jump or move depends on uninitialised value(s)
==8696== at 0x16E4D3: buf_set_u32 (binarybuffer.h:52)
==8696== by 0x16E4D3: ftdi_swd_queue_cmd (ftdi.c:1206)
==8696== by 0x18D76D: swd_queue_ap_write (adi_v5_swd.c:271)
==8696== by 0x18E33B: dap_queue_ap_write (arm_adi_v5.h:382)
==8696== by 0x18E33B: mem_ap_write (arm_adi_v5.c:420)
==8696== by 0x197CD9: target_write_buffer_default (target.c:2176)
==8696== by 0x2464B3: armv7m_start_algorithm (armv7m.c:383)
==8696== by 0x246AEB: armv7m_run_algorithm (armv7m.c:330)
==8696== by 0x19D846: target_run_algorithm (target.c:814)
==8696== by 0x1DF3A6: lpc2000_iap_call.isra.3 (lpc2000.c:818)
==8696== by 0x1E0CF6: lpc2000_erase (lpc2000.c:992)
==8696== by 0x185BDF: flash_driver_erase (core.c:44)
==8696== by 0x18650D: flash_iterate_address_range_inner (core.c:541)
==8696== by 0x18650D: flash_iterate_address_range (core.c:567)
==8696== by 0x18732F: flash_erase_address_range (core.c:584)
==8696== by 0x18732F: flash_write_unlock (core.c:928)
==8696== Uninitialised value was created by a heap allocation
==8696== at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==8696== by 0x220EF9: init_mem_param (algorithm.c:30)
==8696== by 0x1DF247: lpc2000_iap_call.isra.3 (lpc2000.c:777)
==8696== by 0x1E0CF6: lpc2000_erase (lpc2000.c:992)
==8696== by 0x185BDF: flash_driver_erase (core.c:44)
==8696== by 0x18650D: flash_iterate_address_range_inner (core.c:541)
==8696== by 0x18650D: flash_iterate_address_range (core.c:567)
==8696== by 0x18732F: flash_erase_address_range (core.c:584)
==8696== by 0x18732F: flash_write_unlock (core.c:928)
==8696== by 0x18ACDF: handle_flash_write_image_command (tcl.c:457)
==8696== by 0x1B7D99: run_command (command.c:623)
==8696== by 0x1B7D99: script_command_run (command.c:208)
==8696== by 0x1B7FD9: command_unknown (command.c:1033)
==8696== by 0x2E2D37: JimInvokeCommand (jim.c:10364)
==8696== by 0x2E3865: Jim_EvalObj (jim.c:10814)
==8696==
==8696== Conditional jump or move depends on uninitialised value(s)
==8696== at 0x16E506: buf_set_u32 (binarybuffer.h:52)
==8696== by 0x16E506: ftdi_swd_queue_cmd (ftdi.c:1207)
==8696== by 0x18D76D: swd_queue_ap_write (adi_v5_swd.c:271)
==8696== by 0x18E33B: dap_queue_ap_write (arm_adi_v5.h:382)
==8696== by 0x18E33B: mem_ap_write (arm_adi_v5.c:420)
==8696== by 0x197CD9: target_write_buffer_default (target.c:2176)
==8696== by 0x2464B3: armv7m_start_algorithm (armv7m.c:383)
==8696== by 0x246AEB: armv7m_run_algorithm (armv7m.c:330)
==8696== by 0x19D846: target_run_algorithm (target.c:814)
==8696== by 0x1DF3A6: lpc2000_iap_call.isra.3 (lpc2000.c:818)
==8696== by 0x1E0CF6: lpc2000_erase (lpc2000.c:992)
==8696== by 0x185BDF: flash_driver_erase (core.c:44)
==8696== by 0x18650D: flash_iterate_address_range_inner (core.c:541)
==8696== by 0x18650D: flash_iterate_address_range (core.c:567)
==8696== by 0x18732F: flash_erase_address_range (core.c:584)
==8696== by 0x18732F: flash_write_unlock (core.c:928)
==8696== Uninitialised value was created by a heap allocation
==8696== at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==8696== by 0x220EF9: init_mem_param (algorithm.c:30)
==8696== by 0x1DF247: lpc2000_iap_call.isra.3 (lpc2000.c:777)
==8696== by 0x1E0CF6: lpc2000_erase (lpc2000.c:992)
==8696== by 0x185BDF: flash_driver_erase (core.c:44)
==8696== by 0x18650D: flash_iterate_address_range_inner (core.c:541)
==8696== by 0x18650D: flash_iterate_address_range (core.c:567)
==8696== by 0x18732F: flash_erase_address_range (core.c:584)
==8696== by 0x18732F: flash_write_unlock (core.c:928)
==8696== by 0x18ACDF: handle_flash_write_image_command (tcl.c:457)
==8696== by 0x1B7D99: run_command (command.c:623)
==8696== by 0x1B7D99: script_command_run (command.c:208)
==8696== by 0x1B7FD9: command_unknown (command.c:1033)
==8696== by 0x2E2D37: JimInvokeCommand (jim.c:10364)
==8696== by 0x2E3865: Jim_EvalObj (jim.c:10814)
Change-Id: I50f9a8c4516b686cf62ac3c76f47c53465e949da
Signed-off-by: Jean-Christian de Rivaz <jcamdr70@gmail.com>
Reviewed-on: http://openocd.zylin.com/4811
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Without this change xxx_start_algorithm() writes all register
parameters no matter of their direction. It usually results
in writing of uninitialized reg_params[].value - possibly
reported by valgrind.
While on it fix the wrong parameter direction in
kinetis_disable_wdog_algo(). This bug did not have any
impact because of unconditional write of reg_params.
Change-Id: Ia9c6a7b37f77d5eb6e5f5463012dddd50471742b
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4813
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
Stepping in the maskisr auto mode sets breakpoint to step over interrupt
service tasks. If the device has FPB rev 1, setting hard breakpoint
is impossible on address over 0x1fffffff.
Use soft type breakpoint for adresses over 0x1fffffff if FPB is rev 1.
This may eventually fail if the code memory is not writeable, but there
is nothing to do in such case.
Change-Id: Ibdeeb506903a35d550b64f82c24c37a668de62b3
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4857
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
The functions dap_to_jtag() and dap_to_swd() have been introduced by
3ef9beb52c ("ADIv5 DAP ops switching to JTAG or SWD modes") in
arm_adi_v5.c by using the JTAG queue only.
Later, in 6f8b8593d6 ("ADIv5 transport support moves to separate
files") the functions has been moved in adi_v5_swd.c and adi_v5_jtag.c
but keeping the dependency from JTAG queue.
The functions does not work if the current transport is not JTAG.
Move back the functions in arm_adi_v5.c, replace the input parameter
"target" with "dap", use the transport to detect if the JTAG queue is
present, in case of SWD transport use the proper method, for other
transports report error.
Reuse the ADI v5 sequences already present in jtag/swd.h.
Also, OpenOCD does not support switching to another transport after
the initial selection, so do not change DAP's ops vector.
Change-Id: Ib681fbaa60cb342f732bc831eb92de25afa4e4db
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/4852
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
