> **openocd 0.10.0 log**
0.10.0 is very old and there have been significant development changes to its
implementation since then.
You should probably consider using a more recent build of OpenOCD either from
your distro's software repositories or manually built from the latest OpenOCD
0.12.0+
> **openocd 0.10.0 log**
0.10.0 is very old and there have been significant development changes to its
implementation since then.
You should probably consider using a more recent build of OpenOCD either from
your distro's software repositories or manually built from the latest OpenOCD
0.12.0+
FWIW...
According to this:
*
https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/
> Supported by ARM Cortex-A/R/M, RISC-V and Renesas RX
Even though they initially say:
> SEGGER RTT can be used with any J-Link model and any supported target
> processor
Just to clarify - I can't see any relevant patch here that addresses the 'd'
packet duplication/clash:
* https://review.openocd.org/q/bitbang+sleep
I can see the patch that introduced the problem though:
* https://review.openocd.org/c/openocd/+/7472
This issue was previously identified here:
*
https://sourceforge.net/p/openocd/mailman/openocd-devel/thread/670d28d2-75a1-45ec-afe5-541415701d7a%40codasip.com/#msg58723494
But I can't see that any patch was ever submitted to fix the issue - e.g. by
changing to Z and z for millisecond and
> Gerrit being the place for the PR (if such thing) ?
https://sourceforge.net/p/openocd/code/ci/master/tree/HACKING
> (is the RTIC channel on Element the right place to discuss this as most of
> you guys pop-up over there ?)
https://openocd.org/pages/irc.html
You haven't described the nature of the failure or provided a verbose `openocd
-d3` log to help with analysis.
---
**[tickets:#421] OpenOCD v12 - STLink-v3Minie & STM32 f334 Not Working**
**Status:** new
**Milestone:** 0.10.0
**Labels:** bug v12.0
**Created:** Tue Jan 30, 2024 12:46 AM UTC
You haven't described the nature of the failure or provided a verbose `openocd
-d3` log to help with analysis.
> I haven't check if the RISC-V fork already has merged a JTAG-AP
> implementation.
FWIW, I'm pretty sure that it hasn't.
* https://github.com/search?q=repo%3Ariscv%2Friscv-openocd%20jtag-ap=code
* https://github.com/search?q=repo%3Ariscv%2Friscv-openocd%20jtag_ap=code
*
How about:
Z - Sleep for 1 millisecond
z - Sleep for 1 microsecond
as in "Zz" for sleeping/snoring? :-)
https://www.grammarly.com/blog/zzz-meaning/
> Tommy, thanks for the alert.
Just to clarify, it was Marek who flagged the issue.
I just linked to the documentation for the conflicting 'd' requests to give
some additional context. :-)
Just for context - the description of the two 'd' remote bitbang "packets":
* SWD write 0 0:
https://github.com/openocd-org/openocd/blob/44e02e1f49cc09703cb3b4088d0c1c4f9e2d9c87/doc/manual/jtag/drivers/remote_bitbang.txt#L70
* Sleep for 1 microsecond:
> I have came across custom SOCs where there is a single ARM Coresight DAP and
> a riscv processor connected on APB bus on a particular APB port.
Do you happen to mean the WCH CH32VXXX MCUs by any chance? If so then maybe
this is of relevance?
*
What's the context here?
This, perhaps?
* https://github.com/openocd-org/openocd/blob/master/HACKING
> How can I implement an SRST procedure of let’s say 10mS assert
Using the `adapter assert/deassert` and `sleep` commands maybe?
*
https://openocd.org/doc/html/General-Commands.html#:~:text=Command%3A%20adapter%20assert%20%5Bsignal,%5Bsignal%20%5Bassert%7Cdeassert%20signal%5D%5D
*
I wonder if there's anything useful in this (admittedly old) thread about the
IPQ8064?
https://sourceforge.net/p/openocd/mailman/openocd-devel/thread/0e021734-0b7a-0cfa-8dc5-a810bb8c4...@suse.de/
Bear in mind that some aspects of OpenOCD (e.g. script command names etc.) may
have changed since
I presume that it should refer to the HACKING file and maybe the INSTALL file
used to exist but was removed/renamed at some stage?
https://sourceforge.net/p/openocd/code/ci/master/tree/HACKING
Might be worth posting a verbose `openocd -d3` log?
> Unfortunately, the patch was not accepted. I don't know why exactly
It's explained in the review comment from Tomas Vanek:
Thanks for the patch.
Unfortunately the flash driver is a copy of stm32 original with a couple of
changes.
We cannot accept such huge duplicity of code. Imagine we would
Not sure if anybody mentioned this patch already just in case it's relevant
here?
https://sourceforge.net/p/openocd/mailman/message/37753998/
> Great! But where can I find the ID for the MCU? How do I change it in the
> config file?
What happens if you try autoprobing?
See section 10.7 - Autoprobing of the OpenOCD User's Guide:
https://openocd.org/pages/documentation.html
Once you know the IDCODE for the APM32F0 you can try making a
> the OpenOCD documentation doesn’t ever actually explain
what it does.
Why would the OpenOCD documentation cover what's already explained in the gdb
documentation?
* https://ftp.gnu.org/old-gnu/Manuals/gdb/html_chapter/gdb_5.html#SEC18
To see what it does in the context of a remote GDB server
---
**[tickets:#413] Issues with OpenOCD Gerrit Bitbucket/GitHub Oath2
registration**
**Status:** new
**Milestone:** 0.11.0
**Created:** Thu Aug 17, 2023 10:32 AM UTC by Tommy Murphy
**Last Updated:** Thu Aug 17, 2023 10:32 AM UTC
**Owner:** nobody
As far as I can see there seem
Has to be done via Gerrit.
* https://github.com/openocd-org/openocd
> Official OpenOCD Read-Only Mirror (no pull requests)
---
**[tickets:#412] Add "xmc xm25qh32c" spi flash id**
**Status:** new
**Milestone:** 0.11.0
**Created:** Wed Aug 16, 2023 06:45 AM UTC by eZioPan
**Last Updated:** Wed
Can't you submit/propose a patch yourself?
* https://github.com/openocd-org/openocd/blob/master/HACKING
---
**[tickets:#412] Add "xmc xm25qh32c" spi flash id**
**Status:** new
**Milestone:** 0.11.0
**Created:** Wed Aug 16, 2023 06:45 AM UTC by eZioPan
**Last Updated:** Wed Aug 16, 2023 12:00
Have you tried using the ST fork of OpenOCD?
https://github.com/sysprogs/openocd-st/
Is this of any use?
https://visualgdb.com/tutorials/arm/stm32/multicore/startup/
> Do you have a link?
This perhaps?
https://community.st.com/t5/stm32-mcu-products/stm32f746-cortex-m7-silicon-bug-singlestep-lands-in-interrupt/m-p/357481
---
**[tickets:#411] Configuration summary doesn't list "Linux GPIO bitbang through
libgpiod" when enabled**
**Status:** new
**Milestone:** 0.11.0
**Created:** Wed Aug 09, 2023 04:06 PM UTC by Tommy Murphy
**Last Updated:** Wed Aug 09, 2023 04:06 PM UTC
**Owner:** nobody
Minor is
The RISC-V OpenOCD fork is under constant development/refinement.
You really need to build from the latest sources to get the latest updates.
You could try, say, the xPack binary builds but they will still usually lag
behind the bleeding edge RISC-V fork repo sources.
*
Hi Liviu - could you perhaps clarify - maybe in pseudo code - what you mean by
a "rogue breakpoint"? The exact nature of what you mean by this is still
unclear to me.
From: Liviu Ionescu
Sent: Wednesday, July 26, 2023 6:47:54 AM
To: Christopher Head
Cc:
ped
Sent: Tuesday 25 July 2023 20:09
To: Tommy Murphy ; mich...@schwingen.org
; Paul Fertser ;
dietmar@outlook.com ;
openocd-devel@lists.sourceforge.net
Subject: Re: Olimex ARM-USB-OCD-H Driver Issue
Understood, thank you. I'm now at a point where I can interact with the SOC and
write to its mem
Please attach/post logs rather than screenshots as not everybody can read the
latter easily. I also can't see your post on the mailing list archive so it may
have been blocked because of the images.
> I am also referring to an open change set here:
> https://review.openocd.org/c/openocd/+/7694
Maybe if you post review feedback on that change set it might help?
As far as I can see nobody has reviewed it so that may be one reason why it's
lying dormant.
---
**[tickets:#398] Status of STM
OpenOCD is open-source so anybody is free to submit changes for consideration
and inclusion. Including any changes in the STM fork - or any other fork. Of
course, it would be nice if STM would do this themselves (and maybe they do
from time to time?) but it's open to anybody else, in particular
> I might be wrong, but as far as I can tell, the ST-Link GDB server does not
> implement semihosting.
I presumed that Tomas was referring to the earlier minimal self-contained test
that didn't use semihosting?
This whole thread is getting a bit confusing in my opinion.
Why not run the
> Can this be implemented in OpenOCD?
Was it clearly ascertained earlier that this cannot be done via a Tcl script
debug-halted (or similar - I think that there was another handler that was more
relevant but I can't seem to find it in the user manual?) event handler? That
would be preferable
> But later comparisons of OpenOCD runs of my simple
test code with J-Link and ST-link GDB servers suggested that J-link and ST-link
GDB servers keep interrupts masked.
> Your last test shows it's not as easy as that, they implement some fiddling
> with C_MASKINTS. Perhaps they unmask interrupts
> I rechecked the command and run a similar one myself.
> You probably missed the message
> "target must be stopped for "maskisr" command"
> and cut it out from the mailed part of the log as well.
This is why attaching a full and unmodified `openocd -d3` verbose log is so
important when
Hi Liviu
I'm a bit confused by this:
> With the OpenOCD that comes within CubeIDE, 'maskisr on' prevents the PendSV
> to fire, execution stops only on the BRK and pendsv_cnt remains 0.
>
> With 'maskisr auto' the behaviour is the initial one, each run has a rogue
> break and pendsv_cnt
> With J-Link and ST-LINK GDB server, the counter does not go past 1, so it
> looks like the debuggers indeed mask interrupts
Does OpenOCD with `cortex_m maskisr on` (or `auto`?) give the same results? I
know that you tried it before but in a different test scenario so maybe it's
worth trying
Thanks for checking Tomas.
Perhaps the issue is not related to the dual issue nature of the CPU after all.
Any Arm or STM people reading who might want to chip in perhaps? ;-)
> Maybe set it to 0x3F and see if that makes any difference?
Sorry, 0x1F. :-)
Thanks Tomas.
I wonder if playing with ACTLR[20:16] aka DISDI has any impact on this test? I
don't think that dual issue can be completely disabled in case it's a factor
here? Maybe set it to 0x3F and see if that makes any difference?
> The code reliably replicating the issue on STM32F767
Hi Tomas - that's very interesting and presumably something that Liviu might
try on his target? Can you clarify the rXpY version of your target please?
Thanks.
Also, you said that the target device is a Microchip KSZ8695X, but what is the
board or is it some custom board? If it's a custom board then how was the debug
connection verified as working?
From: Tommy Murphy
Sent: Friday, July 14, 2023 5:02:01 PM
To: Abe
What happens when you simply do the following - using the Olimex configuration
script already bundled with OpenOCD and not any custom scripts that you have
created yourself?
`openocd -f interface/ftdi/olimex-arm-usb-ocd-h.cfg`
> Not 'debug-halted' but 'halted' (the 'debug-halted' event is issued at the
> end of a target algo, we have to fix the doc)
If breakpoints can be ignored/resumed automatically using this event handler
mechanism then, in my opinion, this arguably renders moot the suggestion of
adding a flag
> I tried unplugging the cable from the target completely and running again,
> and got the same error.
That makes sense since TDO on the Olimex will most likely be pulled or floating
high by default so it'll be read as 1 when disconnected. The fact that it's
reading high when connected is the
> and I thought that perhaps OpenOCD can do it. Was I too optimistic?
To be fair, there is no clear evidence so far that the problem that you're
hitting here - with the SysTick handler stopping as if there was a breakpoint -
is the fault of OpenOCD and not, perhaps, a bug in the target
Are you absolutely sure that the debugger connector is orientated correctly
with pin 1's matching?
ent: Thursday, July 13, 2023 9:50:25 PM
To: Tommy Murphy ;
openocd-devel@lists.sourceforge.net ;
dietmar@outlook.com ; fercer...@gmail.com
Subject: Re: Olimex ARM-USB-OCD-H Driver Issue
Thank you all for your input. I've downloaded the xPack version and updated my
drivers (hopefully correctly).
>> BTW combining semihosting with interrupts is not a good practice anyway.
>> Except some basic tests the interrupts are unusable due
>> to giant latencies caused by debug halts.
> Hmmm... Can you be more specific on this? What halts do you mean? I
> definitely do not set any breakpoints in my
> so IMO there is nothing like "standalone" mode.
Even if all ports (GDB, Tcl, telnet) are disabled (and there is no pipe
connection from GDB?) and the only commands used are passed from the OpenOCD
command line directly or via scripts? Wouldn't that be a sort of "standalone"
mode?
Zadig 2.5 is also outdated.
I would use the latest, 2.8.
And, as mentioned earlier, a much more up to date version of OpenOCD.
Note that if you're writing you own scripts then some commands may differ with
a later OpenOCD - e.g. `ftdi vid_pid` rather than the legacy `ftdi_vid_pid`
command
> Please use current version of OpenOCD, not something from year 2015.
I'd second that! If you can't build it yourself or find another binary
distribution then you could try the xPack version:
* https://xpack.github.io/dev-tools/openocd/
* https://xpack.github.io/dev-tools/openocd/releases/
> Excuses that someone else seeing the error in a less confusing situation may
> have an easier time figuring out what to do don't do anything to fix the
> problem.
I'm not sure who/what you're referring to, but all I and others offered here
are tips on understanding the issue and I think
> Couldn't it be related to the MASKINTS erratum of Cortex-M7 r0p1 ...
Liviu - can you clarify the revision of your target Cortex-M7?
If it's not r0p2 or later then presumably this erratum does not apply?
> It could be interesting to test with -c 'init;cortex_m maskisr on'
And if that does
> Do you know how to check if there was a HW breakpoint set? I guess there are
> some registers in the debug logic which store these addresses. can we dump
> these registers?
The FP_COMPn registers?
https://developer.arm.com/documentation/ddi0489/f/debug/about-the-fpb/fpb-programmers-model
> If you really want to keep the current behavior, it would at least be good to
> point the developer to build OpenOCD from source and add a line to the file
> `src/flash/nor/spi.c`
If you run OpenOCD in verbose mode (`openocd -d3`) doesn't the log output flag
that file at the point at which
FWIW OpenOCD uses its static list of flash ids and characteristics to identify
the target flash device here - and reports the "unknown device" message if it
can't:
*
https://github.com/openocd-org/openocd/blob/56fd04832abc0ebadc21ee6127be4be9c7b46e15/src/flash/nor/jtagspi.c#L377
---
You might want to attach a verbose (`openocd -d3`) log.
---
**[tickets:#407] Error by connecting to the target via ICE (tlsr9518fd80d kit)**
**Status:** new
**Milestone:** 0.10.0
**Created:** Thu Jul 06, 2023 08:47 AM UTC by Majd Abdullah
**Last Updated:** Thu Jul 06, 2023 08:47 AM UTC
> My feeling is that having not history whatsoever with the project is a good
> way to got shot down early with such a patch.
Well, not proposing a patch and expecting someone else to do the spade work is
probably a good way for nothing to change.
---
**[tickets:#406] "Failed to read
Maybe submit a strawman patch and see what discussion ensues in the review?
Maybe it's still an issue on the GDB side for targets that you're not using?
I notice that no bundled Tcl scripts enable the option which may or may not be
relevant.
I can't find much detail about it, its provenance etc.
> I think that this should be the default state
Based on the comments here that may not be the most judicious approach:
*
https://github.com/openocd-org/openocd/blob/56fd04832abc0ebadc21ee6127be4be9c7b46e15/src/server/gdb_server.c#L1518
/* TODO : Here we have to lie and send
---
**[tickets:#405] arm semihosting_cmdline documentation is incorrect**
**Status:** new
**Milestone:** 0.11.0
**Created:** Wed Jun 28, 2023 08:35 PM UTC by Tommy Murphy
**Last Updated:** Wed Jun 28, 2023 08:35 PM UTC
**Owner:** nobody
The documentation for `arm semihosting_cmdline
trst)
args are in wrong order**
**Status:** new
**Milestone:** 0.11.0
**Created:** Wed Jun 28, 2023 08:01 AM UTC by Tommy Murphy
**Last Updated:** Wed Jun 28, 2023 08:01 AM UTC
**Owner:** nobody
`src/jtag/interface.h adapter_driver::reset(int srst, int trst)` args are in
wrong order with respect
---
**[tickets:#404] src/jtag/interface.h adapter_driver::reset(int srst, int trst)
args are in wrong order**
**Status:** new
**Milestone:** 0.11.0
**Created:** Wed Jun 28, 2023 08:01 AM UTC by Tommy Murphy
**Last Updated:** Wed Jun 28, 2023 08:01 AM UTC
**Owner:** nobody
`src/jtag
---
**[tickets:#403] `program` script/command and documenation not consistent?**
**Status:** new
**Milestone:** 0.11.0
**Created:** Tue Jun 27, 2023 08:41 PM UTC by Tommy Murphy
**Last Updated:** Tue Jun 27, 2023 08:41 PM UTC
**Owner:** nobody
As far as I can see, the implementation
> zlib is a basic library, present in every system.
Maybe every Linux system but what about, say, Windows, Mac, FreeBSD etc.?
> Also Jimtcl has optional dependency from zlib
I presume that option is not "enabled" for OpenOCD - by default or at all?
When I build openocd I get this - I presume
> Just tried what's available on mainline
You mean you built OpenOCD from the repo master branch?
https://github.com/openocd-org/openocd
Or you got the latest from your OS's software repo?
The latter may not be the very latest.
> and it doesn't seem to be supported there.
What happens?
Thanks - these seem to be the key errors in the verbose log file:
```
Line 357: Error: 308 224554 arm_adi_v5.c:570 mem_ap_read(): Failed to read
memory at 0x40015800
Line 370: Error: 321 224559 arm_adi_v5.c:570 mem_ap_read(): Failed to
read memory at 0x40015800
Line 377: Error:
You should post (attach) a verbose OpenOCD log for the failed attempt to debug
to assist with investigation. Use `openocd -d3 ...` to get the verbose log.
---
**[tickets:#398] Status of STM fork and adding support for new STM32 silicon**
**Status:** new
**Milestone:** 0.11.0
**Created:** Wed
> The current script does not work, for starters the STM32WBA has different
> JTAG/SWD IDs.
Have you tried adding the relevant STM32WBA ID(s) to the `stm32wbx.cfg` script?
(I presume that the 'x' in the name is a placeholder so that script should -
eventually, if not right now - also support
> 1. What is the status of that fork?
You probably need to ask STM that question?
> 2. I am struggling with creating a working target config file for the
> STM32WBA chip.
What's wrong with the target script that's in the mainline OpenOCD?
> 1. What is the status of that fork?
You probably need to ask STM that question?
> 2. I am struggling with creating a working target config file for the
> STM32WBA chip.
What's wrong with the target script that's in the mainline OpenOCD?
It's easy to build a custom version of OpenOCD (particularly on Linux) with
additional printf logging in the relevant files to shed more light on such an
issue when the built-in logging isn't sufficient.
From: kristof.mul...@telenet.be
Sent: Thursday, April 20,
Hi Antonio
Thanks a lot for the quick reply.
> Can you use Checkpatch-ignore in the fork?
Maybe that would be a more pragmatic option alright.
Let me check with Tim Newsome who leads the work on the RISC-V OpenOCD fork.
Unless he's reading this and wants to pitch in himself? :-)
Thanks again.
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
patches upstream are pulled down to more closely sync/align the two
> What should be done if some targets have already been resumed (e.g., selected
> hart has been stopped because of a software breakpoint, but others in the SMP
> group continue to run)?
When using GDB (a/the common case, I guess) then it depends on the scheduler
locking mode(s):
> As for address, I don't see that it would ever make sense for all cores to
> resume at the same address.
There are cases where it could make sense. E.g. common startup code executed by
all cores (aka RISC-V harts). In fact, a lot of multi-hart RISC-V implementions
do exactly that at startup
FWIW, my reading of the OpenOCD docs is that where SMP mode is enabled then
resume (and halt) take effect on all cores/threads in the SMP group. That seems
to be the case wherever the two are mentioned together in the user
documentation. Whether or not that is appropriate in all cases,
Seems to be fixed now?
https://github.com/openocd-org/openocd/blob/b6b4f9d46a48aadc1de6bb5152ff4913661c9059/tcl/target/stm32h7x.cfg#L213
although I haven't been able to identify the specific commit/patch that
effected this change...
---
** [tickets:#382] errorin target/stm32h7x.cfg**
You should probably attach a full verbose -d3 log for analysis.
---
** [tickets:#387] [OpenOCD JTATG] Invalid ACK (0) in DAP response**
**Status:** new
**Milestone:** 0.10.0
**Labels:** jtag
**Created:** Tue Mar 21, 2023 01:20 PM UTC by Ashi Gupta
**Last Updated:** Tue Mar 21, 2023 01:20 PM
You might want to explain how you built OpenOCD such that it ended up not being
able to find scripts in the usual places?
---
** [tickets:#388] RESET/WDOG Loop Lockup with Kinetis MK22**
**Status:** new
**Milestone:** 0.11.0
**Created:** Wed Mar 22, 2023 12:17 AM UTC by Mike Aoun
**Last
You seem to be using an old OpenOCD.
Line 202 of that script is different now.
https://github.com/openocd-org/openocd/blob/1998b1e5a89e57b2d1109bc36d6af916106103ff/tcl/target/stm32h7x.cfg#L202
You should try the latest 0.12.0 release or even a build from the head of the
source repository.
You seem to be using an old OpenOCD.
Line 202 of that script is different now.
https://github.com/openocd-org/openocd/blob/1998b1e5a89e57b2d1109bc36d6af916106103ff/tcl/target/stm32h7x.cfg#L202
You should try the latest 0.12.0 release or even a build from the head of the
source repository.
Can you explain the rationale for this suggested change?
The existing `reset-halt-post` event handler has been in place since the
original version of this script in 2009 so it seems strange that it would prove
problematic at this stage?
*
FWIW, Some Microchip FPGAs/SoC FPGAs can support hard and/or soft IP Cortex-M
and RISC-V CPUs. But my recollection (from working for Microchip in the past)
is that neither supported SWD. Certainly there is no SWD debug access to the
RISC-V.
---
** [tickets:#378] SWD support for RISCV
Apologies Paul - if I had been aware that it had been asked already, and
potentially involved closed source/GPL breaches, I would not have answered
here.
---
** [tickets:#379] Create custom jtag driver in openocd **
**Status:** new
**Milestone:** 0.10.0
**Labels:** openocd
**Created:** Thu
In my en my eIxperience, there's not much/any documentation about this but it's
relatively straightforward to look at existing debug interface drivers and
follow those as a guide:
https://github.com/openocd-org/openocd/tree/master/src/jtag
The main task is to implement the public methods for
That seems to be about using ESP32 as an SWD debug interface.
Not about debugging ESP32 using SWD.
And nothing there is obviously about the RISC-V based ESP32-C3.
As such, I don't see its relevance in this thread?
---
** [tickets:#378] SWD support for RISCV artchitecture**
**Status:** new
You mean ESP32-C3?
I don't think so.
As far as I can see it only has JTAG.
https://www.espressif.com/en/products/socs/esp32-c3
---
** [tickets:#378] SWD support for RISCV artchitecture**
**Status:** new
**Milestone:** 0.10.0
**Labels:** openocd
**Created:** Wed Dec 28, 2022 07:00 AM UTC by
You probably want to look at the RISC-V OpenOCD fork for latest RISC-V support.
https://github.com/riscv/riscv-openocd
Changes there periodically get upstreamed to here (the master OpenOCD project).
As far as I know, cJTAG support has been added there.
I don't think that SWD support will ever
us.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 10:44 PM UTC
**Owner:** nobody
When `--enable-verbose` is passed to `configure` it enables code conditionally
compiled if `_DEBUG_USB_COMMS_` is defined in `src/jt
---
** [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 PM UTC
**Owner:** nobody
When `--en
> - I was sure that it is upstream OpenOCD mailing list
Sorry. My mistake. You're correct. I'm usually on the RISC-V lists so thought
that I was still there! :-D
Apropos of a question/comment from you about this yesterday I was having a root
around and got the impression that the telnet interface may have no awareness
of the OpenOCD SMP support. Only gdb does. I'm still not sure but it would seem
to tally with what you're seeing? Might be worth asking
Did you try patching it locally like that and testing it?
Did it work as expected for setting and unsetting the watchpoint?
If so, it might be worth submitting that as a patch/PR via the normal OpenOCD
process?
This PR seems to have changed how watchpoints are set and may be relevant here?
https://github.com/openocd-org/openocd/commit/fb43f1ff4e2f0638110ffcc4e63bee8b5361db64#diff-18b6c875f0bfee773f2a5e6e0a100e4d9c641fec9c870d4da22ca0aa957259c8L914
- watchpoint->set = wp_num + 1;
+ watchpoint->number =
> Are you sure? Seems to me that breakpoints are set in each SMP target:
Oh - maybe only for hardware breakpoints?
My mistake, I think. :-(
From: Tommy Murphy
Sent: Thursday, December 1, 2022 9:53:42 AM
To: Kirill Radkin ; Tim Newsome
Cc: openocd-de
1 - 100 of 294 matches
Mail list logo
