[openocd:tickets] #439 OpenOCD failed with code (-1073741819)

Looks like you are using a fork of OpenOCD from MicroChip. I don't expect we could help you on that code. I even cannot find the code published anywhere. --- **[tickets:#439] OpenOCD failed with code (-1073741819)** **Status:** new **Milestone:** 0.10.0 **Labels:** OpenOCD **Created:** Fri Oc

[openocd:tickets] #435 Broken file

> Good point. But is using a pointer to copy it from e.g. "ls" output not a comfortable option? indeed, it works! --- **[tickets:#435] Broken file** **Status:** new **Milestone:** 0.10.0 **Created:** Mon Sep 23, 2024 06:14 PM UTC by Paul **Last Updated:** Tue Sep 24, 2024 01:25 PM UTC **Owner:

[openocd:tickets] #435 Broken file

my only feedback on this topic is that I work with linux commandline and I have problems typing characters that are not on the international keyboard. Today I still can run ~~~ openocd -f target/*1879*.cfg ~~~ and for the other file I type "1986" and auto complete it with TAB. No big problems for

[openocd:tickets] #434 Deprecated commands with spaces require quotes

Thanks for reporting it. This is already fixed in other deprecated commands, like "hla", by adding a proc to concatenate the arguments. In case of "ipdbg" we need to add in src/jtag/startup.tcl ~~~ proc ipdbg {cmd args} { tailcall "ipdbg $cmd" {*}$args } ~~~ I think we need the same for

Re: OpenOCD outputs everything on stderr

On Sun, Sep 15, 2024, 16:08 Tommy Murphy wrote: > > In our IDE (Embeetle IDE) this causes the OpenOCD output to be always > red - even when nothing goes wrong. > > Same in the Eclipse console where, by default, stdout output is coloured > black and stderr output is coloured red. > > > You can red

Re: OpenOCD outputs everything on stderr

Hi Kristof, Yes, it's a design choice. OpenOCD can be started by within GDB and it has to use stdin/stdout for communication channel for the GDB remote protocol. This has forced the default log to be sent on stderr. You can redirect the log on another channel through the command 'log_output' if

[openocd:tickets] #340 ChibiOS rtos support broken by recent changes in ChibiOS

It should be nice to get such fixes upstream. Please rebase the fixes on current master branch, test and then push them on gerrit at review.openocd.org --- **[tickets:#340] ChibiOS rtos support broken by recent changes in ChibiOS** **Status:** new **Milestone:** 0.11.0 **Created:** Sun Feb 27,

Re: RTT - data dropped when using copy paste to telnet console

On Wed, Aug 28, 2024 at 5:03 PM fanoush wrote: > > Hello, > > looks like the RTT server code does not verify how much data was sent to > device and simply drops received data if it does not fit into buffer on > first try. This does work when typing slowly on keyboard but fails on > anything faster

Re: About a new way of improving openocd

On Thu, Aug 8, 2024 at 5:30 AM Ray Zhang wrote: > > Hello everyone: > I'm new here and not familiar with the ways of how work is done here. > I want to discuss a new kind of way of improving the performance of > openocd. Currently, all JTAG/SWD low-level communication is done in > openocd, on the

Re: submodule jimtcl failure

On Wed, Jun 26, 2024 at 8:35 PM Marc Schink wrote: > > On Tue, 2024-06-25 at 10:33 +0200, Antonio Borneo wrote: > > On Mon, Jun 24, 2024 at 11:46 PM Marc Schink wrote: > > > > > > On Sun, 2024-06-23 at 10:27 +0200, Antonio Borneo wrote: > > > > ...

Re: submodule jimtcl failure

On Mon, Jun 24, 2024 at 11:46 PM Marc Schink wrote: > > On Sun, 2024-06-23 at 10:27 +0200, Antonio Borneo wrote: > > ... > > - git2cl is only used for OpenOCD releases. We could keep it as a > > submodule and change the default of bootstrap to no-submodule. > &

Re: submodule jimtcl failure

On Sat, Jun 22, 2024 at 9:20 AM Marc Schink wrote: > A more general question: what is the reason for integrating jimtcl as a > submodule in the first place? According to repology it seems to be > widespread. We deprecated the libjaylink submodule, what is the reason > to keep jimtcl? > I'm not a

Re: submodule jimtcl failure

On Fri, Jun 21, 2024 at 8:09 PM Tommy Murphy wrote: > > The root cause is that .gitmodules entry for jimtcl was changed but > > not the submodule itself and that the required checkout was not > > available at the old repository. > > Sorry, but I'm still confused. > > After a clean checkout I see

Re: submodule jimtcl failure

On Fri, Jun 21, 2024 at 2:50 PM Antonio Borneo wrote: > > > On Fri, Jun 21, 2024 at 2:42 PM wrote: > >> ... >> >> Strange that jimtcl/DEVELOPING says that: >> >> Jim's sources are kept in Git Version Control System. Global reposito

Re: OpenID and gerrit login (Re: submodule jimtcl failure)

On Fri, Jun 21, 2024 at 2:59 PM wrote: > Antonio: > ... > > I will send the patch on gerrit with your email as reported-by. > > Great. > > > But as you are an active user of OpenOCD, it would be nice if you give > > another try to install an openid for any further contribution or to > review > >

Re: submodule jimtcl failure

On Fri, Jun 21, 2024 at 2:42 PM wrote: > ... > > Strange that jimtcl/DEVELOPING says that: > > Jim's sources are kept in Git Version Control System. Global repository of > Jim project is placed on this Web site: > > http://repo.or.cz/w/jimtcl.git > I will inform the developer. He used t

Re: submodule jimtcl failure

You can try this, on a clean clone, simulating that it was an old clone on which you suddenly run an update: git clone https://github.com/openocd-org/openocd cd openocd git checkout v0.10.0 -- .gitmodules ./bootstrap It will fail because it cannot get access to the jimtcl required by current Open

Re: submodule jimtcl failure

On Thu, Jun 20, 2024 at 10:15 PM wrote: > Tommy Murphy: > > Are you sure that you're not using a very old clone of the repo? > > The JimTcl submodule was switched from https://repo.or.cz/jimtcl.git to > https://github.com/msteveb/jimtcl.git back in December 2020. > > Thanks, that was probably the

Re: Possible small bug in the Cortex-M7 core used by STM?

By the way, arm errata reports that there is no HW fix, yet; all the Cortex-M7 today in production should have this bug. This mail's subject mentions STM, but the issue should be more general. Antonio On Sat, Jun 8, 2024, 15:48 Antonio Borneo wrote: > We also detect the CPU as Cortex

Re: Possible small bug in the Cortex-M7 core used by STM?

We also detect the CPU as Cortex-M7 with cortex_m->core_info. There could be an additional check to restrict the workaround to Cortex-M7 only. Antonio On Fri, Jun 7, 2024, 13:02 Liviu Ionescu wrote: > > > > On 7 Jun 2024, at 12:23, Tomas Vanek > wrote: > > > > The workaround in OpenOCD cortex_

Re: CPU ID for Cortex-M52

Thanks Liviu and Joseph. The ideal way to proceed would be to have Joseph sending one or two patches to OpenOCD Gerrit. But so far we have never received any direct contribute from arm employees, no idea if is there any real blocking point there. I plan to work on C-M52 in the near future for add

Re: style error when submitting GERRIT request 8287: src/flash/nor/spi.c: add XIAO RP support

On Sun, May 19, 2024, 17:34 Jan Cumps wrote: > I submitted GERRIT request 8287: > https://review.openocd.org/c/openocd/+/8287?forceReload=true > > Validation fails, with style error: > > checking patch ... > ERROR:SPACING: space required after that ',' (ctx:VxV) > #23: FILE: src/flash/nor/spi.c:1

Re: Finding syntax errors with tclint

On Thu, May 16, 2024, 05:13 Noah Moroze wrote: > Hi, > > I maintain tclint , an open-source > linter/static analysis tool for Tcl. Someone pointed to OpenOCD > as something to run tclint > against, which led me to fi

Re: rtt setup handler fails on macos

Hi, I have never used RTT, but looking at the code it looks like it is for Cortex-M only! With your SOC you are trying to use it on aarch64 CPUs. No idea if it is a valid setup for RTT. A set of commands "rtt server XXX" are registered in src/server/rtt_server.c All other RTT commands, like "rtt s

[openocd:tickets] #306 libgpiod API changes since 1.6.3

**Created:** Fri May 28, 2021 11:48 AM UTC by Michael Brown **Last Updated:** Mon Jan 08, 2024 02:37 PM UTC **Owner:** Antonio Borneo New API changes to libgpiod are breaking calls to gpiod_chip_close gpiod_chip_open_by_number. Assigning to Antonio as it looks like they've done the most work o

[openocd:tickets] #423 Update for JEP106BI

- **status**: new --> closed - **assigned_to**: Antonio Borneo - **Resolution**: --> https://review.openocd.org/8132 --- **[tickets:#423] Update for JEP106BI** **Status:** closed **Milestone:** 0.11.0 **Created:** Tue Feb 06, 2024 07:05 PM UTC by Véronique Allard **Last Updated:** Tue

[openocd:tickets] #423 Update for JEP106BI

Thanks for the alert. https://review.openocd.org/c/openocd/+/8132 --- **[tickets:#423] Update for JEP106BI** **Status:** new **Milestone:** 0.11.0 **Created:** Tue Feb 06, 2024 07:05 PM UTC by Véronique Allard **Last Updated:** Tue Feb 06, 2024 07:05 PM UTC **Owner:** nobody JEP106BI has bee

Re: License issue: OpenOCD and riscv/debug_defines.h

On Thu, Jun 30, 2022 at 6:22 PM Tim Newsome wrote: > On Wed, Jun 29, 2022 at 1:46 PM Antonio Borneo > wrote: > >> On Wed, Jun 29, 2022 at 9:48 PM Tim Newsome wrote: >> > >> > On Tue, Jun 28, 2022 at 3:09 PM Antonio Borneo < >> borneo.anto...@gmail.com

Re: erase/write flash error when flash-addr-width > 32bit on windows

Hi, thanks for your patch and your work on OpenOCD. Could it be possible for you to push your patch on OpenOCD gerrit? The relevant information to do it are in HACKING file in the source code, and also online in https://openocd.org/doc-release/doxygen/patchguide.html I also see a few other inter

Re: Character conflict in the remote-bitbnag protocol

I don't think there is any preference. You are the first to implement this remote delay, so any character currently unused can do the job Thanks Antonio On Sun, Jan 14, 2024 at 12:00 AM Jeremy Herbert wrote: > > Hi all, > > No problems, happy to change to whatever you think is best. > > Thanks,

Re: Character conflict in the remote-bitbnag protocol

Jeremy, your patch to OpenOCD https://review.openocd.org/c/openocd/+/7472 that introduced the remote delay for remote_bitbang driver uses the 'd' character that is already used for SWD. Do you think it's possible to move the remote delay functionality to another character? Tommy, thanks for the al

[openocd:tickets] #418 Reading ROMTABLEs with "dap info" seems to irrecoverably hang the DAP

SWD DAP has a ABORT register. See online https://developer.arm.com/documentation/ihi0031/a/Debug-Port-Registers/Debug-Port--DP--register-descriptions/The-AP-Abort-Register--ABORT?lang=en or download a newer version in PDF In SWD you can send an ABORT request with command DAPNAME dpreg 0 1 In JTAG i

[openocd:tickets] #418 Reading ROMTABLEs with "dap info" seems to irrecoverably hang the DAP

I also have few SoC that present the same issue. If one CoreSight device is not clocked, the debug bus (between DAP AP and CoreSight) hangs, waiting for transfer to complete. It is possible for OpenOCD to send an ABORT request (it works in JTAG, apparently it does not work well in SWD) so the DAP

Re: different GDB port for Trusted Execution Environment

On Wed, Nov 29, 2023 at 7:05 PM Randy Li wrote: > > Hello Hello Randy, sorry for replying late to your email. > The TEE OS and trusted applications have been widely used in many ARM > platforms. The JTAG debugger would not longer only serve the Rich > Operating System Execution Environment kerne

[openocd:tickets] #215 Add Xilinx XVC support to OpenOCD

- **status**: new --> closed - **Resolution**: --> https://review.openocd.org/c/openocd/+/6867 --- **[tickets:#215] Add Xilinx XVC support to OpenOCD** **Status:** closed **Milestone:** 0.9.0 **Created:** Mon Dec 10, 2018 08:35 AM UTC by Alex Forencich **Last Updated:** Thu Dec 28, 2023 03:59

[openocd:tickets] #215 Add Xilinx XVC support to OpenOCD

It's ongoing in https://review.openocd.org/c/openocd/+/6867 which is under review and closed to be completed and merged. I'm going to close this ticket. If you can, please review and/or test the change above. Thanks --- **[tickets:#215] Add Xilinx XVC support to OpenOCD** **Status:** new **Mile

Re: First time commit - checkpatch errors

It's added automatically with flag -s at git commit -s but you first need to set, in git, user and email On Sun, Dec 10, 2023, 18:49 Rolf | Onethinx wrote: > That works, thanks! > > Where / how do I use Signed-off-by? > > Op 10 dec. 2023, om 18:35 heeft Antonio Borneo >

Re: First time commit - checkpatch errors

Hi, checkpatch has "limited" capabilities, so it can easily get into such types of issues. What about adding an article, e.g.: * @param first the first sector to erase Antonio On Sun, Dec 10, 2023 at 6:22 PM Rolf | Onethinx wrote: > Hi, > > I’m about to commit my first patch which includes u

Re: Error with latest commit - use asynchronous libusb transfer 65/7365/11

Tomas, the last three merged commits on cmsis-dap also add two new clang warnings https://build.openocd.org/job/openocd-clang/1195/ Would you mind checking them? Thanks Antonio On Sun, Dec 10, 2023 at 12:36 PM Tomas Vanek wrote: > > Rolf, > > The problem is probably related to libusb @ macOS. >

Re: SRST inconsistency between multiple adapters

s the one currently in > the repo is one of the first versions made by Cypress at the time and if > has many defects. Will commit the update after testing. > > Regards, > Rolf > > > > Op 7 dec. 2023, om 23:04 heeft Antonio Borneo > het volgende geschreven: > >

Re: SRST inconsistency between multiple adapters

Rolf, you can try with reset_config srst_only srst_nogate connect_assert_srst but this is not valid for every SoC, so give it a try. You can find more details in OpenOCD documentation, but shortly this command will instruct OpenOCD to: 1) start and keep the SoC under reset 2) while the SoC is und

[openocd:tickets] #306 libgpiod API changes since 1.6.3

changes since 1.6.3** **Status:** new **Milestone:** 0.10.0 **Labels:** libgpiod **Created:** Fri May 28, 2021 11:48 AM UTC by Michael Brown **Last Updated:** Wed Oct 25, 2023 08:11 PM UTC **Owner:** Antonio Borneo New API changes to libgpiod are breaking calls to gpiod_chip_close

Re: cjtag support?

Hi Nima, as far as I know there are two forks of OpenOCD that support cJTAG: - risc-v at https://github.com/riscv/riscv-openocd/commit/6749c70a3ae891552296888986e6eeae1e17f11a - ARC by synopsys at https://github.com/foss-for-synopsys-dwc-arc-processors/openocd/commit/74f33f0fddb3e22b5fbc8e2633ab1

Re: Xilinx XVC support (client)

Hello, I have missed it, too many patches in the queue. Thanks for the alert. Just reviewed. Regards Antonio On Thu, Aug 24, 2023 at 3:36 PM Augusto Fraga Giachero wrote: > > Hello, > > We've been using the XVC client implementation provided in > https://review.openocd.org/c/openocd/+/6867 with

Re: STM32H7x5 M4 Core Debug Issues

On Sat, Aug 12, 2023 at 6:38 AM Tomas Vanek wrote: > ... > The part of openocd.cfg up to here is +- standard. > > The following part is a folklore added by zephyr project, which changes > OpenOCD > startup behaviour and gdb attach. TBH I see no reason why they need it for. > > $_CHIPNAME.cpu0 con

Re: semihosting unexpected breakpoint not acknowledged

On Fri, Jul 14, 2023 at 6:53 PM Tomas Vanek wrote: > > On 14/07/2023 00:30, Tomas Vanek wrote: > > > Unfortunately (if I'm not completely wrong guessing the mechanism of the > errata) each rogue break also means that > one semihosting operation gets skipped. So your test will keep running, time

Re: semihosting unexpected breakpoint not acknowledged

I was ignoring the errata, as it's titled "single stepping", which is not Liviu's case. But reading it carefully, under "Conditions" that can trigger the issue there is "The processor exits Debug state." So we could assume that at the resume from a semihosting BKPT, a SysTick interrupt is pending a

Re: semihosting unexpected breakpoint not acknowledged

nio On Mon, Jul 10, 2023 at 8:58 PM Liviu Ionescu wrote: > > > > > On 10 Jul 2023, at 21:37, Antonio Borneo wrote: > > > > the log: > >> 1: Info : adapter_poll > >> 1: Info : stlink_usb_v2_read_debug_reg 0xE000EDF0 0x01030003 > > reports that, w

Re: semihosting unexpected breakpoint not acknowledged

Hi Liviu, the log: > 1: Info : adapter_poll > 1: Info : stlink_usb_v2_read_debug_reg 0xE000EDF0 0x01030003 reports that, while reading register DHCSR, OpenOCD found that the CPU is halted. Then it expects it is due to a breakpoint. Are you sure there is not any pending HW breakpoint? The address

[openocd:tickets] #405 arm semihosting_cmdline documentation is incorrect

Agree! Thanks for spotting it. Would you mind sending a fix for this issue, adding in the commit message the line: Fixes: https://sourceforge.net/p/openocd/tickets/405/ --- **[tickets:#405] arm semihosting_cmdline documentation is incorrect** **Status:** new **Milestone:** 0.11.0 **Created:**

Re: Add zlib dependency to OpenOCD?

On Sat, Jun 24, 2023 at 11:59 AM Michael Schwingen wrote: > > On 23.06.23 14:12, Antonio Borneo wrote: > > Hi, > > I would like to have your feedback on this topic. > > > > Today a binary package of OpenOCD should include: > > - the binary openocd[.exe] &

Add zlib dependency to OpenOCD?

Hi, I would like to have your feedback on this topic. Today a binary package of OpenOCD should include: - the binary openocd[.exe] - the TCL scripts from tcl folder - the file contrib/60-openocd.rules (for Linux only) - documentation - license files All the small binaries for flashing are embedde

[openocd:tickets] #375 ti_cjtag.cfg: JTAG scan chain interrogation failed: all ones

- **status**: new --> closed - **Resolution**: --> https://review.openocd.org/7419/ --- **[tickets:#375] ti_cjtag.cfg: JTAG scan chain interrogation failed: all ones** **Status:** closed **Milestone:** 0.11.0 **Created:** Sat Dec 17, 2022 01:47 PM UTC by Phil Wiggum **Last Updated:** Sat Jun

[openocd:tickets] #375 ti_cjtag.cfg: JTAG scan chain interrogation failed: all ones

Merged https://review.openocd.org/7419/ --- **[tickets:#375] ti_cjtag.cfg: JTAG scan chain interrogation failed: all ones** **Status:** new **Milestone:** 0.11.0 **Created:** Sat Dec 17, 2022 01:47 PM UTC by Phil Wiggum **Last Updated:** Sun Jun 04, 2023 12:25 PM UTC **Owner:** nobody ** 1. S

[openocd:tickets] #375 ti_cjtag.cfg: JTAG scan chain interrogation failed: all ones

Please check https://review.openocd.org/7419/ --- **[tickets:#375] ti_cjtag.cfg: JTAG scan chain interrogation failed: all ones** **Status:** new **Milestone:** 0.11.0 **Created:** Sat Dec 17, 2022 01:47 PM UTC by Phil Wiggum **Last Updated:** Sat Dec 17, 2022 01:47 PM UTC **Owner:** nobody *

[openocd:tickets] #397 OpenOCD TCL script execution failure with commit 95603fae1

Daniel, the issue is caused by the code in aarch64_step() that at the end does not check the status of the core and does not call the event TARGET_EVENT_HALTED. You can compare the code with the one in cortex_m.c and cortex_a.c. cortex_a_step() directly calls cortex_a_poll(). The former incorrec

[openocd:tickets] #395 segfault: jtag drscan 32 1

If you have any 'target' (a CPU to be debugged) in your config file, then OpenOCD will run continuously polling on the target to check if it has hit a breakpoint. This polling can happen anytime, also within a sequence: irscan ... drscan ... with the result that the IR is modified under the hood.

Re: Making historical committed code/patches comply with latest checkpatch

On Fri, Apr 7, 2023 at 1:13 PM Tommy Murphy wrote: > > Hi there > > As many of you probably know, RISC-V OpenOCD development continues to be done > on this fork: > > https://github.com/riscv/riscv-openocd > > Periodically, changes here are upstreamed to the "main" OpenOCD project > and/or patche

[openocd:tickets] #386 OpenOCD can't connect to Dialog DA1469x

Good that it work now! I see that your dia.cfg is inspired from some STM32Lxx. It has inside some STM32 specific initialization that is probably causing issues with your chip. - Remove the lines related to the flash, - check that the SRAM is at the specified physical address 0x2000 in the com

[openocd:tickets] #378 SWD support for RISCV artchitecture

One update on the (almost off-topic) discussion started with this ticket "Allwinner R128 wireless SoC features 64-bit RISC-V core, Arm Cortex-M33 core, and HiFi 5 audio DSP" https://www.cnx-software.com/2023/03/06/allwinner-r128-wireless-soc-features-64-bit-risc-v-core-arm-cortex-m33-core-and-hifi

[openocd:tickets] #384 Error in interface/raspberrypi-native.cfg

- **status**: new --> closed - **Resolution**: --> ttps://review.openocd.org/7512 - **Comment**: patch merged --- ** [tickets:#384] Error in interface/raspberrypi-native.cfg** **Status:** closed **Milestone:** 0.11.0 **Created:** Tue Feb 28, 2023 07:11 PM UTC by Tomáš Deingruber **Last Updat

Re: libusb_init is now deprecated

Thanks for the alert. I don't see LIBUSB_API_VERSION incremented. Just forgot, or it's not supposed to change for this case? Antonio On Wed, Jan 25, 2023 at 1:26 PM Xiaofan Chen wrote: > > With the merging of libusb PR #1026 recently, libusb_init() is now deprecated. > > This will cause issues

[openocd:tickets] #378 SWD support for RISCV artchitecture

Cinly, yes, that's a grey area out of tech domain and more on lawyer sides. But I see Risc-V cores used as control integrated in HW accelerators, like GPUs or AI. People that build SoCs could feel comfortable keeping the ARM main processor while integrating such third-party accelerators. This kin

Re: review.openocd.org issues?

On Fri, Dec 30, 2022 at 8:36 PM Paul Fertser wrote: > > On Fri, Dec 30, 2022 at 07:56:40PM +0100, Antonio Borneo wrote: > > I have just sent 4 new patches to gerrit, then opened one of them to > > add a comment. > > The page didn't open, and after some time the browse

Re: review.openocd.org issues?

On Mon, Dec 19, 2022 at 10:31 AM Paul Fertser wrote: > > On Wed, Dec 14, 2022 at 06:48:55PM +, Tarek BOCHKATI wrote: > > I confirm the issue, but I have more findings. When Jenkins is > > running a job (build, scan-build) the access to gerrit starts to be > > very slow, sometimes unreachable.

[openocd:tickets] #378 SWD support for RISCV artchitecture

Agree with Tommy, SWD is ARM proprietary protocol part of ARM CoreSight, Nevertheless, somewhere or sometimes we could have a SoC that integrates together some ARM core with some RISC-V cores. In this hybrid SoC the debug port can either be: * a JTAG chain with two TAPs (one for ARM and the othe

[openocd:tickets] #376 configure --enable-verbose triggers compilation error in arm-jtag-ew.c & opendous.c

- **status**: new --> closed - **assigned_to**: Antonio Borneo - **Resolution**: --> https://review.openocd.org/7403/ - **Comment**: Merged --- ** [tickets:#376] configure --enable-verbose triggers compilation error in arm-jtag-ew.c & opendous.c ** **Status:** closed **Milestone

[openocd:tickets] Re: #376 configure --enable-verbose triggers compilation error in arm-jtag-ew.c & opendous.c

Try again the link, The gerrit server becomes not responsive when jenkins is building... painful situation In the fix I have left "%04x" so the output will not change as I don't expect the length to be more than 64k. In case length exceeds 64k, than "%04x" will simply use more than 4 characters.

[openocd:tickets] #370 profile : Assertion `address_space >= 2' failed.

- **status**: new --> closed - **assigned_to**: Antonio Borneo - **Resolution**: --> https://review.openocd.org/7394/ https://review.openocd.org/7400/ - **Type**: --> bug - **Comment**: Patches merged --- ** [tickets:#370] profile : Assertion `address_space >= 2' fa

[openocd:tickets] #376 configure --enable-verbose triggers compilation error in arm-jtag-ew.c & opendous.c

Please check https://review.openocd.org/7403/ --- ** [tickets:#376] configure --enable-verbose triggers compilation error in arm-jtag-ew.c & opendous.c ** **Status:** new **Milestone:** 0.10.0 **Created:** Sat Dec 17, 2022 06:00 PM UTC by Tommy Murphy **Last Updated:** Sat Dec 17, 2022 06:00 P

[openocd:tickets] #370 profile : Assertion `address_space >= 2' failed.

This extra patch addresses the case of PC constant due to 'while (1);' https://review.openocd.org/7400/ --- ** [tickets:#370] profile : Assertion `address_space >= 2' failed.** **Status:** new **Milestone:** 0.11.0 **Created:** Wed Nov 23, 2022 04:10 PM UTC by fenugrec **Last Updated:** Tue Dec

[openocd:tickets] #370 profile : Assertion `address_space >= 2' failed.

Would you mind checking https://review.openocd.org/7394/ and report if it fixes your use case? --- ** [tickets:#370] profile : Assertion `address_space >= 2' failed.** **Status:** new **Milestone:** 0.11.0 **Created:** Wed Nov 23, 2022 04:10 PM UTC by fenugrec **Last Updated:** Thu Nov 24, 2022

Re: JLink target power

On Sat, Dec 10, 2022 at 4:03 PM Rolf | Onethinx wrote: > > Hi, > > There is a problem with setting JLink power on. JLink has a possibility to > feed the target hardware from the J-Link debugger. > > There is a command already in OpenOCD: `jlink config targetpower on`, however > the current imple

[openocd:tickets] #373 ST-LINK V3SET fails to enter SWD

I think that the part before the highlighted is the switch from JTAG to SWD. The part highlighted looks like the read of DAP register DPIDR. On STLink V2 you get the ACK reply and the value On STLink V3 clone looks like the ACK is missing. But it would require zooming in the picture and analyze th

[openocd:tickets] #373 ST-LINK V3SET fails to enter SWD

reverse engineered STLink V3! Interesting! Did someone already succeed to make it working? Or this is the first tentative to use the cloned FW? The signals you sent from logic analyzer cannot show if there is any signal integrity issue. Do you have an oscilloscope to check them? But looks like th

[openocd:tickets] #373 ST-LINK V3SET fails to enter SWD

Hi, no it's not related with #325 and #308. I can get the same error STLINK_JTAG_GET_IDCODE_ERROR (code 0x09) with an STLink V3 stand-alone not connected to any target. Are you sure the SWD connection is ok? The target board is powered on? --- ** [tickets:#373] ST-LINK V3SET fails to enter SWD

[openocd:tickets] #370 profile : Assertion `address_space >= 2' failed.

yes, this code has two ugly abort() when it should just report an error or a warning. That's a kind of old coding style that is still present here and there in OpenOCD. In your case, the PC is sampled but it always returns the same value Is target running in an infinite loop? Or maybe your M0 do

Re: Call for OpenOCD v0.12.0

On Wed, May 18, 2022 at 2:29 PM Antonio Borneo wrote: > > On Wed, May 18, 2022 at 12:23 PM Jonathan McDowell wrote: > > > > On Wed, May 18, 2022 at 11:00:58AM +0200, Antonio Borneo wrote: > > > Dear OpenOCD developers, > > > > > > it's pro

[openocd:tickets] #369 about openocd install question

The code you are using is not from OpenOCD main repository. The last image shows "cJTAG" in the configuration summary. cJTAG is not available yet. Where did you get the code? Maybe you should ask there. --- ** [tickets:#369] about openocd install question** **Status:** new **Milestone:** 0.10.

Re: handler vs jim_handler

On Sat, Nov 5, 2022 at 5:10 PM R. Diez wrote: > > Hi all: > > In file src/helper/command.h , "struct command", there are these 2 members: > > command_handler_t handler; > Jim_CmdProc *jim_handler; > > OpenOCD commands seem to use the one or the other. What is the difference? If > one preferable?

[openocd:tickets] #368 openocd don't proper fallback and not work on cmsis-dap-v1(hid) with `CMSIS DAP` in name of its usb serial

I'm afraid that this issue could happen again in future with other adapters. If you have a linux machine, can you please plug the KitProg3 and post here the output of "lsusb -v -d 04b4:"? This could help keeping a log of problematic devices and take care of them if further fixes has to be applied

[openocd:tickets] #367 Raspberry Pi 4 through SWD with STM32F4x (version: 0.12.0)

- **status**: new --> closed - **Resolution**: --> not an openocd bug - **Comment**: Thanks! I'm closing it! --- ** [tickets:#367] Raspberry Pi 4 through SWD with STM32F4x (version: 0.12.0)** **Status:** closed **Milestone:** 0.11.0 **Labels:** raspberry pi 4 stm32f4x **Created:** Sat Oct 0

Re: merge for v0.12.0-rc2

On Sat, Oct 8, 2022 at 10:28 AM Tomas Vanek wrote: > > Antonio, > > On 08/10/2022 09:33, Antonio Borneo wrote: > > I would like to go ahead with merge for v0.12.0-rc2, but I have not > > clear if you agree merging this series: > > - https://review.openocd.org/7

Re: preparing for v0.12.0-rc1

With last (late night) merges, I have no more patches to add, with the exclusion of checkpatch. Updated https://review.openocd.org/6192/ "The openocd-0.12.0-rc1 release candidate" and moved to +1. Ready! Also rebased checkpatch due to one SPDX tag with "WITH" word not recognized (my fault) and upda

[openocd:tickets] #362 Script performance degradation due to jim_command_dispatch() / target_call_timer_callbacks_now()

It's strange that it's still slower than 0.11.0. Do debug_level 3 traces show anything strange/different? --- ** [tickets:#362] Script performance degradation due to jim_command_dispatch() / target_call_timer_callbacks_now()** **Status:** new **Milestone:** 0.11.0 **Created:** Thu Sep 01, 202

Re: preparing for v0.12.0-rc1

On Tue, Sep 6, 2022 at 10:13 AM Tomas Vanek wrote: > > On 06/09/2022 09:56, Antonio Borneo wrote: > > On my side I was interested to fix this ticket before tagging, but we > > have a workaround so not a big deal anymore: > > - [tickets:#362] Script perfor

[openocd:tickets] #362 Script performance degradation due to jim_command_dispatch() / target_call_timer_callbacks_now()

Andrey, Tomas, could you please check this patch? https://review.openocd.org/c/openocd/+/7174 --- ** [tickets:#362] Script performance degradation due to jim_command_dispatch() / target_call_timer_callbacks_now()** **Status:** new **Milestone:** 0.11.0 **Created:** Thu Sep 01, 2022 07:13 PM UT

preparing for v0.12.0-rc1

The deadline for tagging v0.12.0-rc1, proposed for mid September, is approaching. Nothing is fixed in stone, such a deadline is not a hard schedule, but I would like to respect it. We already have 832 patches merged from the last v0.11.0 release (2021-03-07) and ~35 are in my local branch ready for

[openocd:tickets] #362 Script performance degradation due to jim_command_dispatch() / target_call_timer_callbacks_now()

Andrey, possible workaround: use command 'poll off' before CRC and 'poll on' after? But with a GDB attached, GDB could timeout... --- ** [tickets:#362] Script performance degradation due to jim_command_dispatch() / target_call_timer_callbacks_now()** **Status:** new **Milestone:** 0.11.0 **Cr

[openocd:tickets] #362 Script performance degradation due to jim_command_dispatch() / target_call_timer_callbacks_now()

Yep, there could be side effects on scripts. Andrey, what is the performance degradation that you see? Would it be acceptable for a release? --- ** [tickets:#362] Script performance degradation due to jim_command_dispatch() / target_call_timer_callbacks_now()** **Status:** new **Milestone:**

[openocd:tickets] #362 Script performance degradation due to jim_command_dispatch() / target_call_timer_callbacks_now()

Tomas, the reason "should" be linked to moving "expr" command from a jimtcl command to an openocd command. Running an openocd command triggers: src/helper/command.c:939: target_call_timer_callbacks_now(); Here the correct call should be target_call_timer_callbacks(). Can you please verify th

[openocd:tickets] #256 `gdb_actual_connections` is never initialized?

Personally I will not consider initializing the variable. In OpenOCD we use the implicit initialization in several cases, this is not different from them. I prefer closing this as it's not a bug. --- ** [tickets:#256] `gdb_actual_connections` is never initialized?** **Status:** new **Milestone

[openocd:tickets] #277 No release since 3 years after 0.10.0 hampers collaboration with other projects

- **status**: new --> closed - **Milestone**: 0.9.0 --> 0.10.0 - **Resolution**: --> v0.11.0 released - **Component**: --> release --- ** [tickets:#277] No release since 3 years after 0.10.0 hampers collaboration with other projects** **Status:** closed **Milestone:** 0.10.0 **Created:** We

[openocd:tickets] #361 STM32H7 flash error

- **status**: new --> closed - **Resolution**: --> Issue not in OpenOCD upstream --- ** [tickets:#361] STM32H7 flash error** **Status:** closed **Milestone:** 0.11.0 **Created:** Thu Sep 01, 2022 06:38 AM UTC by Mohos Tamás **Last Updated:** Thu Sep 01, 2022 08:45 AM UTC **Owner:** nobody H

[openocd:tickets] #356 fail to debug a micro:bit v2 application

There are better ways to write the script, instead of using 'catch', e.g.: ~~~ if { [flash list] == "" } { flash bank $_CHIPNAME.flash nrf51 0x 0 1 1 $_TARGETNAME flash bank $_CHIPNAME.uicr nrf51 0x10001000 0 1 1 $_TARGETNAME } ~~~ or ~~~ if { [llength [flash list]] == 0 } { ...

Re: Build error: target: add generic Xtensa LX support

I should definitely have rerun static > analysis on a more recent patchset of 7055. Is upgrading my GCC required > also? > > > > Apologies for the trouble and thank you again @Erhan Kurubas for the very > timely fixes. > > > > Best, > > --ian > > >

Re: Build error: target: add generic Xtensa LX support

Plus 5 new clang warnings https://build.openocd.org/job/openocd-clang/1106/ Actually 3 are surely from xtensa code. The other 2 are not clear. Antonio On Sat, Aug 20, 2022, 19:52 Antonio Borneo wrote: > I have made the mistake to merge the patch > https://review.openocd.org/c/openocd/

Build error: target: add generic Xtensa LX support

I have made the mistake to merge the patch https://review.openocd.org/c/openocd/+/7055 without pre-building it locally on my PC for test, which is what I usually do (but not today!). BOOM. Master branch does not compile anymore I tried to fix it, but I ended up with one issue! Could you please inv

[openocd:tickets] #357 digilent-hs2.cfg not working with Digilent HS2 JTAG adapter

Searching with google https://www.google.com/search?q=%22iProduct%22+%22Digilent+Adept+USB+Device%22 reports that the 'iProduct' string 'Digilent Adept USB Device' was really existing. Then if, why and when Digilent changed it, that's hard to find. Personally I consider this string match as not st

[openocd:tickets] #357 digilent-hs2.cfg not working with Digilent HS2 JTAG adapter

The string in optional command 'ftdi device_desc' is compared with USB field 'iProduct', that in your case is 'Digilent USB Device'. There are 4 config files with such string: - tcl/interface/ftdi/digilent_jtag_smt2_nc.cfg - tcl/interface/ftdi/digilent_jtag_hs3.cfg - tcl/board/digilent_nexys_video

  1   2   3   4   >