When receiving an OpenOCD debug log to investigate about errors or
issues, the first question is often about providing the complete
command line to better understand the use context.
Plus, when OpenOCD is lunched by an IDE, its command line is kept
hidden inside the IDE, adding troubles to the user to recover it.
Add the full command line directly inside the debug log.
It could have been useful to also search and add in the log the
full path of the OpenOCD executable, but this is not an immediate
task due to portability among OS's. See, for example:
https://stackoverflow.com/questions/933850
This part could be handled in a future change, if really needed.
Change-Id: Ia6c5b838b9b7208bf1ecac7f95b5efc319aeabf5
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8170
Tested-by: jenkins
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
ADIv6 brought more complicated rules for DP reg 0 banking.
Neither the original implementation [1] nor the later
modification [2] respected that the DP reg 0 is banked
for read only, not for write. Enforcing of an useless
SELECT write before a write to ABORT register may trigger
FAULT (CTRL/STAT bits ORUNDETECT and STICKYORUN are set)
or WAIT (DP is stalled by an outstanding previous operation)
and therefore make ABORT register virtually unusable
on some adapters (bitbang, CMSIS-DAP).
There are DP ABORT specific functions swd_queue_ap_abort()
and swd_clear_sticky_errors() which worked around the problem
using the lowest level swd->write_reg(). Using a specific
write procedure for a single DP register was error prone
(there are other DP_ABORT writes using swd_queue_dp_write_inner())
and also the Tcl command 'xx.dap dpreg 0 value' suffered
from unwanted SELECT write.
Other smaller discords in DP banking probably do not
influence normal DP operation however they may complicate
debugging in corner cases.
Adhere strictly to the DP banking rules for both ADI versions.
Fixes: [1] commit 72fb88613f ("adiv6: add low level swd transport")
Fixes: [2] commit ee3fb5a0ea ("target/arm_adi_v5: fix DP SELECT logic")
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: I3328748c1c3e0661c5ecd6eb070ac519b190ace2
Reviewed-on: https://review.openocd.org/c/openocd/+/8154
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
The bitbang driver kept retrying a SWD command as long as
the debugged device had been responding by SWD WAIT.
If the DP stalled in WAIT permanently, OpenOCD hanged.
Check 0.5 sec timeout in WAIT retry loop.
While on it insert a short alive_sleep() if the command
is retried 20 or more times.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: I744e56e21a5a2dc2c4494cc0d7bbcb4be14ddb23
Reviewed-on: https://review.openocd.org/c/openocd/+/8153
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Log SWD commands with not OK response but WAIT retries at debug level.
For commands responded OK and WAIT retries use debug io level
not to flood the log.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: Idf658e82ed970061c155945df55d06908ed25e09
Reviewed-on: https://review.openocd.org/c/openocd/+/8152
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Allow logging at a changeable level.
Add an example of usage in ftdi driver.
Log SWD commands with not OK response at debug level (3).
For commands which responded OK use debug io level (4)
not to flood the log.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: I67a472b293f7ed9ee84cadb7c081803e9eeb1ad0
Reviewed-on: https://review.openocd.org/c/openocd/+/8151
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Allow direct pointer to struct adiv5_private_config
for targets with adiv5_private_config inside of a bigger
private config container. Use it instead of the private_config
pointer toggling hack in aarch64.c
Allow optional use of -dap parameter and use it instead
of the static variable hack in xtensa_chip.c
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: I7260c79332940adfa49d57b45cae39325cdaf432
Reviewed-on: https://review.openocd.org/c/openocd/+/8138
Tested-by: jenkins
Reviewed-by: Ian Thompson <ianst@cadence.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Unify the error codes returned by adapter drivers in the case
of the received SWD ACK field differs from OK.
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: I29e478390b4b30408054a090ac6a7fac3415ae71
Reviewed-on: https://review.openocd.org/c/openocd/+/8137
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Commit [1] added a break on error to the nrf5_erase() sector loop
and the checking of the res value became useless in the for loop condition.
Removing nrf5_get_probed_chip_if_halted() later in [2]
dropped res initialization and clang static analyser complains
"The left operand of '==' is a garbage value"
Drop the useless test!
Fixes: [1] commit 491636c8b8 ("flash/nor/nrf5: check protection before flash erase/write on nRF51")
Fixes: [2] commit 2db325f539 ("flash/nor/nrf5: drop nrf5_get_probed_chip_if_halted()")
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Change-Id: Ife6071c509719f8d7dc312fe9a780bdcf2575f69
Reviewed-on: https://review.openocd.org/c/openocd/+/8174
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Running the GDB command 'flash-erase' triggers sending the remote
GDB commands 'vFlashErase' (one per flash bank) followed by one
single 'vFlashDone', with no 'vFlashWrite' commands in between.
This causes the field 'gdb_connection->vflash_image' to be NULL
during the execution of 'vFlashDone', triggering a segmentation
fault in OpenOCD.
While parsing 'vFlashDone', check if any image to flash has been
received.
Change-Id: I443021c7a531255b60f2c44c2685e52e3c34b5c8
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8164
Tested-by: jenkins
After commit d9b2607ca0 ("gdb_server: support sparse register
maps"), GDB crashes while requesting the value of 'cpsr' because
the fake register is tagged as not existing.
Change the logic and set all register as existing, while still
limiting the list for the initial GDB request at connect.
Change-Id: I1c4e274c06147683db2a59a8920ae5ccd863e15c
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/8163
Tested-by: jenkins
The command substantially complicates support of nRF53/91
series. It was not even properly ported to nRF52.
The informative value is disputable. Who wants to see
e.g. override trim values for radio or unique device ID?
Drop it and simplify the driver.
Change-Id: Ia7fb20ce2ebf16065705c5d18deaf934e58db426
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/8108
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
nrf5_get_probed_chip_if_halted() was somewhat bizarre
combination of functions:
- test if the target is halted is appropriate for flash
erase/write only, certainly not for getting chip info
- getting chip pointer takes place more frequently
and using one temporary variable for dereference
makes no harm
- probing chip is useless at all as the flash
infrastructure always calls auto_probe() before
entering a flash operation
Replace the function by ordinary and readable code.
Change-Id: Ic31f4e33d8b7b36687be3f40bfd0fe913d17b75f
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/8107
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
from Product Specification of nRF52805, 810, 811
820, 833 and 840.
While on it, rename the table to make sure the codes
are valid for nRF52 series only.
Change-Id: Id8f78fd214c5d345d1769378ae546a6be5a183ba
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/8105
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
After 'reset run' or 'reset halt' the loaded application
is expected to manipulate RAMON register to workaround
the known silicon errata.
Moreover, writing to RAMON register from 'reset-end' event
after 'reset run' may collide with application intentions.
Use the workaround in 'reset-init' event only to ensure
correct function of target algorithms.
Change-Id: I7d2d92e6805a05a83676edb46b3163ef39b9a7e4
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/8104
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Use the newer driver name 'nrf5' instead.
While on it set the unused parameters of flash bank
creation to zero.
While on it remove 2 empty comments.
Change-Id: I9cf0eadc5b696e6c8b7e6aec0ea3345967523e87
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: https://review.openocd.org/c/openocd/+/8103
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
On 2008-03-05, before git's age, commit 6d95014674 adds sending
an ACK ('+' char) at GDB connection, before receiving any GDB
remote command that requires to be ACK'ed.
Neither the text added in the commit message ("added ACK upon
connection (send +)") nor in the associated comment ("send ACK to
GDB for debug request") provide an exhaustive explanation for
sending this unsolicited ACK.
This code has never been touched since its introduction.
Analysis of GDB code doesn't show it's required, including old GDB
code.
Running gdbserver (from GDB package) and attaching it with "nc"
shows that gdbserver does not send any ACK to a new connection.
Same for lldb-server.
Drop it!
Change-Id: Id68c352ce44dd85a1ea3d67446e17e2a241ef058
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6768
Tested-by: jenkins
Reviewed-by: Jan Matyas <jan.matyas@codasip.com>
Reviewed-by: Anatoly P <anatoly.parshintsev@syntacore.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
When performing a command queue allocation larger than the default page
size of 1MiB any subsequent allocations will run into an integer under-
flow when checking for the remaining memory left in the current page.
Causing the function returning a pointer past the end of the buffer and
thus creating a buffer overflow.
This has been observed to cause some transfers to Efinix FPGAs to fail,
because another buffer can get corrupted in the process, causing its
respective free() to fail.
Change-Id: Ic5a0e1774e2dbd58f1a05127f14816c8251a7d9c
Signed-off-by: SydMontague <sydmontague@phoenix-staffel.de>
Reviewed-on: https://review.openocd.org/c/openocd/+/8126
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
