The deprecation was already in the documentation since v0.11.0
through commit 85ba2dc4c6 ("rtos/hwthread: add hardware-thread
pseudo rtos") but OpenOCD was not informing the user printing a
runtime message.
Remove the deprecated method from the documentation and print a
deprecated message at runtime.
There is no reliable way to print the same message in GDB console,
so we have to rely on user noticing it in the OpenOCD log.
Target is to remove the functionality after v0.12.0.
Change-Id: Idd2d9e3b6eccc92dcf0432c3c7de2f8a0fcabe9f
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6862
Tested-by: jenkins
on macos (homebrew base) `pkg-config --cflags capstone` output with
`-I/opt/homebrew/Cellar/capstone/4.0.2/include/capstone`
gcc not find headers on parent "include" path,
causes build error `fatal error: 'capstone/capstone.h' file not found`
it's ok to change to <capstone.h> for all platforms.
Signed-off-by: fatalc <cnfatal@gmail.com>
Change-Id: Ia2e2058024d4fc1a57a8b4ea847c664d74f67efb
Reviewed-on: https://review.openocd.org/c/openocd/+/6946
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Handle JIM_CONTINUE return value of adiv5_jim_mem_ap_spot_configure(),
otherwise OpenOCD silently quits when an unknown option is provided.
Change-Id: I9b1351c0911e74999d8dd1260ede9760088510d7
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/6944
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
The SWDIO buffer requires a direction pin to select input or output
direction. Output is selected by a high logic level (matches
bcm2835gpio driver).
Change-Id: I240cb99a5dfea08121bb33d4b5e2108ce7597468
Signed-off-by: Steve Marple <stevemarple@googlemail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6936
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
According to GigaDevice user manuals the devices have OBRLD bit in FMC_CTL
register which is functionally compatible with OBL_LAUNCH @ FLASH_CR
of STM32 counterparts.
Change-Id: I84d231b38815fcb6452fd73b9153b269cce3b737
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/6759
Tested-by: jenkins
Reviewed-by: Andrzej Sierżęga <asier70@gmail.com>
The flash is compatible with stm32f1x, reuse the driver.
Extend the size of work area to RAM size of the smallest device.
Stop watchdogs before flash programming.
Change-Id: I67a7654a6e196f9d4b2409edaa7990c53334437e
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/6711
Tested-by: jenkins
Reviewed-by: Tim Newsome <tim@sifive.com>
The device has compatible flash macro with STM32F1 family, reuse
stm32f1x driver code.
Detect non-ARM target - for simplicy test target type name 'riscv'
and the address has 32 bits.
In case of RISC-V CPU use simple chunked write algo - async algo
cannot be used as the core implemented in this device doesn't
allow memory access while running.
Change-Id: Ie3886fbd8573652691f91a02335812a7300689f7
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/6704
Tested-by: jenkins
Reviewed-by: Tim Newsome <tim@sifive.com>
Zephyr plan to remove openocd specific symbols in favour
of more generic one.
These generic symbols has been introduced in Zephyr 2.6.
Signed-off-by: Julien Massot <julien.massot@iot.bzh>
Change-Id: I89418c9c378fb8b8baa29763fc6f1b6e652dc7ef
Reviewed-on: https://review.openocd.org/c/openocd/+/6844
Tested-by: jenkins
Reviewed-by: Stephanos Ioannidis <root@stephanos.io>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Current implementation for gdb remote monitor command uses the
command_run_line() to execute the command.
While command_run_line() has several advantages, it unfortunately
hides the error codes and outputs the result of the command
through LOG_USER(), which is not what gdb requires. See 'qRcmd' in
https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html
Replace command_run_line() with Jim_EvalObj() and parse the output
to provide the proper result to gdb.
Can be tested by defining in OpenOCD:
proc a {} {return hello}
proc b {} {return -code 4}
proc c {} {return -code 4 "This is an error!"}
then by executing in gdb console:
monitor a
monitor b
monitor c
monitor foo
Change-Id: I1b85554d59221560e97861a499e16764e70c1172
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reported-by: Torbjorn Svensson <torbjorn.svensson@st.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6886
Tested-by: jenkins
The target nds32 and its companion adapter aice have not received
any real improvement since 2013.
It has been hard to keep them aligned during the evolution of
OpenOCD code, with no way for maintainers to really check if they
are still working.
No real documentation is present for them in OpenOCD.
The arch nds32 has been dropped from Linux kernel v5.18-rc1.
Deprecate both nds32 target and aice adapter with the target of
dropping them for v0.13.0.
Remove automatic build of aice, forcing user to select it.
Change-Id: Ib465d676246fa3b4e95c3d399ba9a5cf1f8b3baf
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6887
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested-by: jenkins
The current code locks the flash controller in case of error during
flash write only. An error in other flash operations may cause the
flash is left unlocked.
Implement locking also after error in erase, mass erase, options
write and erase.
Change-Id: I26c2ed7914e7847122306f29b777b9eefd1dc580
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/6710
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
stm32x_wait_status_busy() has two side effects in case of flash programming error:
- reports error
- clears error bit in status register
Use stm32x_wait_status_busy() to report also flash error during target
algo flash write.
While on it use more descriptive error codes in stm32x_wait_status_busy().
Change-Id: I6e1cffc2aa5411b918a23ed62d5194910888a9d1
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/6709
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Use target_get_working_area_avail() instead of try-fail iteration.
Call destroy_reg_param() in a for cycle.
Change-Id: I1891d1ffdea99010c6ab66b9578400b9d7922e20
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/6708
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Mostly refactoring.
Rename original stm32x_write_block() to stm32x_write_block_async()
as it uses target async algo.
Introduce new stm32x_write_block() and move slow, host controlled
fallback flash write there.
The change allows stm32x_write_options() to use slow flash write fallback.
While on it rename variables where halfword count is stored.
Change-Id: I386ae15cf052b1490461ed8f7eea5b4403d466f7
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/6706
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
When we debug a target that works as a USB device, halting
the target causes the USB communication with the USB host to
become unresponsive. The host will try to reconnect/reset/setup
the unresponsive device during which communication with other
devices on the same USB bus can get stalled for several seconds.
If the JTAG adapter is on the same bus, we need to make sure
openOCD will wait for packets at least as long as the host USB
stack. Otherwise the USB stack might deliver a valid packet, but
openOCD would ignore it due to the timeout. The xHCI spec uses 5
sec timeouts, so let's use that in openOCD with some margin.
Use this value in all libusb calls. HID API might have a libusb
backend and would probably be victim to the same bug, so it
should use this timeout, too.
Ticket: https://sourceforge.net/p/openocd/tickets/343/
Signed-off-by: Gabor Csapo <gaborcsapo@google.com>
Change-Id: Ia3dc1356e676fe550f57a4c72f7a24ba296b6af2
Reviewed-on: https://review.openocd.org/c/openocd/+/6882
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
