Dirk,
https://github.com/raspberrypi/openocd.git
is a Raspberry Pi's fork of OpenOCD.
Report errors to their github, not here.
Tomas
On 03/09/2025 17:07, Dirk-Willem van Gulik wrote:
Against OpenOCD head as of today (0.12.0+dev-g5855e5c (2025-09-03-13:57)) - I
am getting an odd
$ sudo open
On 04/09/2025 10:37, Dirk-Willem van Gulik wrote:
On 4 Sep 2025, at 10:06, Tomas Vanek
wrote:
https://github.com/raspberrypi/openocd.git
is a Raspberry Pi's fork of OpenOCD.
Report errors to their github, not here.
Thanks; will try that version as well. Was hoping to do things with
Don't be fooled by this simplified diagram found in ARM documentation: it's so
simplified that it's wrong. SWDIO correctly changes on failing SWCLK edge when
the adapter transmits and on rising SWCLK edge when SWDP transmits.
See
8690: target/arm_adi: add URLs of latest ARM ADI spec |
https://re
On 26/06/2025 16:13, Ivan Kryvosheia wrote:
Hi Tomas!
I have problem building openOCD project after this patch with a change
to jimctl
https://review.openocd.org/c/openocd/+/8383
Before I just used
./bootstrap
git submodule init
git submodule update
./configure
make -j8
and it worked
but now
Liam,
I'm aware of the series of Microchip patches and believe me the slow (or
almost no) progress makes me sad.
The idea of the new patch with just the target configuration file is
good, actually the same was requested
in Antonio's review
https://review.openocd.org/c/openocd/+/8561/comment/
Martin,
On 24/05/2025 04:58, Brandon Martin wrote:
It would be handy for the FLEXSPI if there were target events for
non-GDB initiated flash erase start/end and write start/end since it
would allow deferring disabling of watchdogs, which are chip-specific,
to the relevant TCL scripts. Is that
nocd.org/c/openocd/+/846
(with 27 patches in the relation chain)
HTH
Tomas
FWIW...
-Original Message-
*From*: Tomas Vanek <mailto:tomas%20vanek%20%3ctom_...@users.sourceforge.net%3e>>
*To*: openocd-devel@lists.sourceforge.net
*Subject*: Re: DEPRECATED! use '
On 15/02/2025 02:26, Symbolic Debugger wrote:
Hi
Trying to get a NanoDAP to work with a PICO2 via SWD.
Changing the command according to the instruction does not work.
openocd --command "adapter driver cmsis-dap; cmsis_dap_backend hid"
Open On-Chip Debugger 0.12.0+dev-gcf9c0b41c-dirty (2025-02
Thanks for the report.
Could you please submit a patch to https://review.openocd.org ?
You may find details in https://openocd.org/doc/doxygen/html/patchguide.html
---
**[tickets:#449] GDB Server Should Return an Empty Response for Undefined GDB
Packets**
**Status:** new
**Milestone:** 0.10.0
Thanks for reporting!
I was able to reproduce the problem on the older K66FX1M0
Your solution is correct, but...
Please be aware that OpenOCD project requires submitting patches to the Gerrit
review system, we are not able to accept patches from mails and tickets. See
https://openocd.org/doc/d
Very strange!
Finding MEM-AP is the generic ARM ADI stuff and is used mainly for all ARM
Cortex cores.
If that part of OpenOCD were so wrong to screw up some bits of MEM-AP
read/write then no Cortex core could be debugged!
Please start over with **clean** OpenOCD and libjaylink.
Make your best
On 02/12/2024 07:59, Quentis Ghyll wrote:
Hi,
I found the following behavior which generates tons of error messages.
*OS:*
Win11 + WSL + Ubuntu 22.04.5 LTS + usbipd-win
*Target PCB/board description*: Raspberry Pi Pico W board RP2040
*Actual result*
Both the GDB and OpenOCD terminal windows
Thanks for reporting.
Please test 8641: drivers/cmsis_dap: fix segfault in quirk mode setting |
https://review.openocd.org/c/openocd/+/8641
---
**[tickets:#420] Segfault from cmsis-dap adapter quirk**
**Status:** new
**Milestone:** 0.11.0
**Created:** Wed Jan 24, 2024 04:08 PM UTC by Mark Fea
Please note that there is a bunch of pending patches adding RP2350 support.
The new RP2xxx driver code uses fixed 4k sector size for both RP2040 and
RP2350. See e.g.
8453: flash/nor/rp2040: improve flash write buffer size computation |
https://review.openocd.org/c/openocd/+/8453
Checkout whole r
> It seems like a lot of transactions return a WAIT condition, and the code
> says it's slowing down and resending, but I don't actually see how it's
> slowing down.
The transactions previously send at once to the adapter are replayed one by one
with immediate checking of returned ack. The log
On 31/07/2024 20:46, p...@dmtechnologies.eu wrote:
Does OpenOCD support stm32u5a5 microcontroller?
I use xPack OpenOCD v0.12.0-3 to program stm32u585, and it works fine.
However it fails with stm32u5a5. The command is:
STM32U5A5 support was merged to the OpenOCD git master very recently
Thanks for taking care of this, Liviu.
I looked what ARM recommends as a workaround. Unfortunately there is no hint
how the debugger could reliably detect that the execution has halted due
to 3092511 erratum.
In such case it would be safe to resume.
The workaround in OpenOCD cortex_m.c cortex_
Please try 8285: target/cortex_m: allow poll quickly get out of TARGET_RESET
state | https://review.openocd.org/c/openocd/+/8285
---
**[tickets:#360] "Could not write to register 'msp'" while trying to flash TI
CC3235SF**
**Status:** new
**Milestone:** 0.11.0
**Labels:** cc32xx
**Created:**
> 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.
> Example SOC: https://www.nordicsemi.com/Products/nRF54H20 - This is with
> combination of ARM and RISCV core on an SOC.
Ashi, does the first statem
macOS Monterey 12.6.3
Op 10 dec. 2023, om 11:02 heeft Tomas Vanek
het volgende geschreven:
Rolf,
could you please provide -d 3 log
and more info about the operating system the OpenOCD is hosted on.
Thanks
Tomas
On 09/12/2023 20:41, Rolf | Onethinx wrote:
Latest commit on cmsis_dap_bulk gives
Rolf,
could you please provide -d 3 log
and more info about the operating system the OpenOCD is hosted on.
Thanks
Tomas
On 09/12/2023 20:41, Rolf | Onethinx wrote:
Latest commit on cmsis_dap_bulk gives error on KitProg3 in CMSIS-DAP
mode (line 606):
"unable to allocate CMSIS-DAP packet bu
Hi Bohdan,
On 23/10/2023 14:51, Bohdan Tymkiv wrote:
Hello dear OpenOCD maintainers,
While working with the mem_ap target I noticed that setting a
breakpoint causes a crash in target_add_breakpoint
because target->type->add_breakpoint is NULL. I discovered this by
accident, just forgot to sw
On 15/10/2023 11:24, kristof.mul...@telenet.be wrote:
Hi Paul and Liviu,
> What happens if you use stm32f0x.cfg config?
Then I get the following problem:
** Programming Started **
Error: Cannot identify target as a stm32x
Error: auto_probe failed
embedded:startup.tcl:1524: Error: *
I played little bit with PSM control registers (using mdw/mww commands) and
find that truth is slightly different.
If you set a bit in FRCE_OFF, PSM resets all following blocks in the hierarchy
until you prevent doing so by setting FRCE_ON. Setting the XIP in FRCE_OFF bit
forces reset of not on
Core0 simply responds by SWD WAIT to any MEM-AP operation. Bus is stalled, most
probably by a broken QSPI XIP access. I see no problem at OpenOCD side.
---
**[tickets:#416] RP2040 QSPI Flash reset (no more XIP) causes debug and Flash
to fail.**
**Status:** new
**Milestone:** 0.10.0
**Created:
Hi Michael,
the fragment of OpenOCD log shows that CPU0 (M7 core) cannot be halted.
What is programmed in M7 startup?
On 11/08/2023 22:34, Banducci, Michael wrote:
I started based on the example OpenOCD configs for the STM32H745 and
H747 and attempted to build a configuration file (see below)
On 17/07/2023 00:25, Liviu Ionescu wrote:
On 17 Jul 2023, at 00:18, Tomas Vanek wrote:
Such breakpoint would collide with the induced rogue break - don't place any
breakpoint to the PendSV_Handler(), just watch `pendsv_cnt` when execution
stops at BKPT instruction.
...
We need to
On 20/07/2023 09:50, Tomas Vanek wrote:
On 19/07/2023 22:14, Liviu Ionescu wrote:
On 17 Jul 2023, at 09:13, Tomas Vanek
wrote:
Andreas sent me a hint:
On 15/07/2023 11:44, Andreas Bolsch wrote:
According to AN4891, table 7, STM32H72x/3x are r1p2, but RM0468
doesn't mention r/p fo
It's necessary to write to OTP memory (very rare used)
Please be patient until Tarek fixes the patch. The reference manual lists OTP
at 0x0FF9 and 0x0BF9 so the definition should be:
`flash bank $_CHIPNAME.otp stm32l4x 0x0FF9 0 0 0 $_TARGETNAME`
---
**[tickets:#398] Status of STM
There seems to be a mismatch in OTP bank address.
Could you try comment out OTP definition in tcl/target/stm32wbax.cfg
`# flash bank $_CHIPNAME.otp stm32l4x 0x1fff7000 0 0 0 $_TARGETNAME`
It should allow gdb attach.
---
**[tickets:#398] Status of STM fork and adding support for new STM32 s
Tarek wrote 2 moths ago:
> please test using this patch
https://review.openocd.org/c/openocd/+/7694
But I see in all logs:
Open On-Chip Debugger 0.12.0
instead of
Open On-Chip Debugger 0.12.0+dev-00xxx-gd3949b4af339
Jan,
testing a patched config file with an unpatched release OpenOCD binary has
On 22/07/2023 00:22, Tommy Murphy wrote:
> 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?
No, I meant the OS based unit test with se
On 22/07/2023 00:11, Liviu Ionescu wrote:
On 21 Jul 2023, at 20:36, Tomas Vanek wrote:
Could you try the test under ST-Link GDB server?
I might be wrong, but as far as I can tell, the ST-Link GDB server does not
implement semihosting.
Liviu
Didn't know that. No point in doing so
On 21/07/2023 18:14, Liviu Ionescu wrote:
On 21 Jul 2023, at 19:02, Tomas Vanek wrote:
Does this test code run under ST-link GDB server?
It runs in a debug session in Eclipse with J-Link.
Liviu
I asked specifically for ST-Link GDB server because I'm able to test it.
I don'
On 21/07/2023 16:33, Liviu Ionescu wrote:
On 21 Jul 2023, at 16:55, Tomas Vanek wrote:
You have to use "interface/stlink-dap.cfg" as I wrote, not
"interface/stlink.cfg"
oops!
It went a bit further, but it hang when trying to start the scheduler:
```
1: Test command: /
On 19/07/2023 22:14, Liviu Ionescu wrote:
On 17 Jul 2023, at 09:13, Tomas Vanek
wrote:
Andreas sent me a hint:
On 15/07/2023 11:44, Andreas Bolsch wrote:
According to AN4891, table 7, STM32H72x/3x are r1p2, but RM0468
doesn't mention r/p for the CPU.
I'll ask ST for one...
Any
On 17/07/2023 07:28, Liviu Ionescu wrote:
On 15 Jul 2023, at 12:09, Tomas Vanek wrote:
I'm more interested in testing the newest r1p2. Any tip to a device containing
Cortex-M7 r1p2 core?
Any owner of r1p2 device keen to run the test?
The H743 board that I have also reports r1p1, an
On 16/07/2023 21:52, Liviu Ionescu wrote:
On 16 Jul 2023, at 22:13, Tomas Vanek wrote:
Just to be sure, check the counter with J-Link and ST-LINK GDB server
I placed a breakpoint on the `pendsv_cnt++;` in the PendSV_Handler, and an
Expression watch in Eclipse on the `pendsv_cnt` variable
On 16/07/2023 20:49, Liviu Ionescu wrote:
On 16 Jul 2023, at 21:37, Tomas Vanek wrote:
The counter has a good reason: it's an easy way to check if PendSV_Handler() is
really called
and the debugger does not mask interrupts.
I see. In my test I did not check the value of this count
On 16/07/2023 19:37, Liviu Ionescu wrote:
I added the pendsv_cnt counter in the PendSV_Handler(), but I think this is not
very relevant to the test.
The counter has a good reason: it's an easy way to check if
PendSV_Handler() is really called
and the debugger does not mask interrupts.
On 15/07/2023 13:13, Tommy Murphy wrote:
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?
https://develop
On 14/07/2023 19:31, Tommy Murphy wrote:
> 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.
So far tested:
STM32F767 nucleo boar
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 to time some semihosted output get lost.
T
Not really
On 13/07/2023 23:06, Liviu Ionescu wrote:
On 13 Jul 2023, at 23:48, Tommy Murphy wrote:
I presume that the breakpoints used to implement semihosting (e.g. 0xBEAB for Cortex-M7)
do actually cause the target to go into debug halt for a period of time even if they're
subsequently automatically
On 13/07/2023 20:30, Liviu Ionescu wrote:
On 13 Jul 2023, at 19:12, Liviu Ionescu wrote:
... change OpenOCD to resume it when running with semihosting enabled but
standalone (i.e. not in a debug session).
Question: what do you think should be a correct behaviour for OpenOCD when an
explici
On 11/07/2023 09:11, Tomas Vanek wrote:
I'm not familiar with the details of semihosting implementation, I
assume that the semihosting BKPT must be
overcome by single step like any other BKPT.
I was wrong with my assumption: single stepping is used to skip over SW
breakpoints insert
On 11/07/2023 08:13, Liviu Ionescu wrote:
On 11 Jul 2023, at 08:44, Tomas Vanek wrote:
Couldn't it be related to the MASKINTS erratum of Cortex-M7 r0p1 ...
I checked the 'STM32F76xxx/77xxx device errata', ES0334 - Rev 9 - December
2022, but could not find anything related.
Liviu, Antonio,
On 11/07/2023 07:22, Liviu Ionescu wrote:
On 11 Jul 2023, at 00:50, Antonio Borneo wrote:
From what you say, it's not a matter of adapter (CMSIS-DAP and STLINK
give the same issue). It's not HLA vs Cortex-M.
That's correct
But you only get it on Cortex-M7, correct?
I can o
Yes, there are problems loading app software to a nRF5x device with a Soft
Device in the flash.
I never analysed the reasons to such depth, I used one of possible easy
workarounds:
- convert app ELF binary to ihex, then 'flash write_image' cmd does not
overwrite the Soft Device
- use gdb, load c
Good to hear that.
IIRC MCU-Link works as a CMSIS-DAP adapter. CMSIS-DAP generally works for
Kinetis Kx series MCUs with empty flash but I didn't test MCU-Link - so you
mileage may vary...
---
** [tickets:#388] RESET/WDOG Loop Lockup with Kinetis MK22**
**Status:** new
**Milestone:** 0.11.0
*
Hi Mike,
unfortunately this is a known problem.
It is broken since merging https://review.openocd.org/c/openocd/+/6548
I proposed to revert this commit in https://review.openocd.org/c/openocd/+/6753
but no other maintainer voted for it.
You may try to compile a custom OpenOCD version with the pro
Thanks for reporting and sorry: my bad!
You proposed a correct solution. Could you please submit the patch directly to
https://review.openocd.org/ ?
See https://openocd.org/doc/doxygen/html/patchguide.html for details.
Please reference the commit which caused the problem in the commit message:
~
On 30/12/2022 21:42, Antonio Borneo wrote:
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 brows
Indeed, my bad.
The fix you proposed
~~~
source [find interface/raspberrypi-gpio-connector.cfg]
~~~
seems correct. Would you like to submit a patch to https://review.openocd.org/ ?
If you do so, please reference
~~~
Fixes: bec6c0eb094f (tcl/interface: universal config for all Raspberry Pi
models)
connect_assert_srst is not usable and srst_nogate is completely wrong with SAMD
and SAME5x MCUs. See remarks in tcl/target/at91samdXX.cfg
~~~
# SAMD DSU will hold the CPU in reset if TCK is low when RESET_N
# deasserts (see datasheet Atmel-42181E–SAM-D21_Datasheet–02/2015, section
12.6.2)
...
#
RTOS used on target?
openocd -d log?
---
** [tickets:#381] gdb crashes: openocd reports that the current thread is 0**
**Status:** new
**Milestone:** 0.11.0
**Created:** Thu Feb 09, 2023 02:39 PM UTC by Jérôme Pouiller
**Last Updated:** Thu Feb 09, 2023 02:39 PM UTC
**Owner:** nobody
I have r
Thanks for the patch. Unfortunately we are not able to review and accept
patches which are not submitted to https://review.openocd.org/
See https://openocd.org/doc/doxygen/html/patchguide.html for details.
---
** [tickets:#372] at91samd.c should check NVM READY flag**
**Status:** new
**Milesto
On 20/11/2022 19:47, Nick Kraus wrote:
When trying to use a cmsis-dap debugger to capture SWO output, I think
that the command to change baudrate doesn't send enough bytes to the
debug probe. At line 663 of cmsis_dap.c (function
cmsis_dap_cmd_dap_swo_baudrate()) it appears that 4 bytes are
tra
I successfully used almost identical config (just without reset) with STM32H7
devices.
From the technical point of view there is very interesting that nonsense zero
DPIDR is read without an error. Curiously this behaviour is possible just by
the capacity of input when SWDIO signal has a weak pu
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/7230
"target: re-examine before arp_waitstate in ocd_process_reset_inner"
- https://review.openocd.org/7
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 performance degradation due to
jim_command_dispatch() / target_call_timer_callbacks_now()
https://sourceforge.ne
I think we have only two ways:
1) Risk regression on scripts
2) Make a hack to detect 'expr' in jim_command_dispatch() and suppress
target_call_timer_callbacks_now().
Considering the expr syntax workaround is mentioned to be dropped after 0.12
release, I would temporarily accept hackish 2)
---
> src/helper/command.c:939: target_call_timer_callbacks_now();
Here the correct call should be target_call_timer_callbacks().
Didn't test but I'm sure this change will fix script performance degradation.
Also the weird timing of target timers will be less broken.
On the other hand the change may
IMO target_call_timer_callbacks_now() is a hack which we should get rid of in
the future. We can substitute calling all callbacks by calling the particular
function we need, e.g. target poll.
But such change is too risky now, just before tagging 0.12 rc
---
** [tickets:#362] Script performanc
Andrey,
thanks for reporting the problem.
git bisect revealed the regression comes from
c7eaaf620488 (openocd: prepare for jimtcl 0.81 'expr' syntax change)
https://review.openocd.org/c/openocd/+/6510
The performance degradation is related to 'expr' command only.
Antonio, could you propose a fix?
The script is weird. Both flash banks are created in sourced target/nrf52.cfg
The second flash banks create in catch blocks might be related to the changed
name of the flash driver (former name nrf51, now nrf5). I doubt any official
version of OpenOCD ever needs that.
Just use the first 3 lines
Looks like the nrf52 device is not properly connected or is locked. See UICR
APPROTECT in ref man. Recent OpenOCD versions support unlocking by the command
'nrf52_recover'. This command cannot be used with a high level adapter, use -f
interface/stlink-dap.cfg for ST-Link.
Next time please attac
Thank for the pointer to AN4445. Now it's clear that my guess was wrong.
> Still, the KL series should not be affected by my change at all.
Yes
> Anyway, if only the KL series needs switching the VLPR to RUN mode, maybe we
> could just remove the entire check for the older K-series MCUs (first
On 13/04/2022 15:21, Erhan Kurubas wrote:
+Tomas Vanek for his comment.
*From:* Erhan Kurubas
*Sent:* Friday, April 8, 2022 11:57 PM
*To:* Antonio Borneo
*Subject:* alternative workarea config
Hi Antonio,
Espressif
Hey all!
Please, could anybody review
6706: flash/nor/stm32f1x: allow write fallback for flash options |
https://review.openocd.org/c/openocd/+/6706
6707: flash/nor/stm32f1x: remove write alignment code |
https://review.openocd.org/c/openocd/+/6707
6708: flash/nor/stm32f1x: tidy up async algo
On 20/11/2021 07:27, Tomas Vanek wrote:
I'll resolve these:
Done.
atsamv gpnvm
cmsis-dap cmd
documented.
kinetis_ke mdm test_securing
at91samd info
commands removed.
nrf51 mass_erase
nrf51 info
nrf51 mass_erase
nrf51 info
compatibility aliases for nrf5, already documented as
On 19/11/2021 16:42, Antonio Borneo wrote:
I would not bet on the correctness of my scripts, but the output is
already helpful.
Well done, Antonio!
Some command are documented in a group and should not be in your list, e.g.
flash fillw
flash fillh
flash fillb
flash mdb
flash mdh
mdw
mdh
mdb
m
On 20/06/2021 17:59, Andreas Bolsch wrote:
On 2021-06-20 14:12, Oleksandr Redchuk wrote:
нд, 20 черв. 2021 о 00:42 Andreas Bolsch пише:
On 2021-06-19 22:58, Oleksandr Redchuk wrote:
> FT2232D-based adapter
> The same behavior as Ali Tekin reported:
> "Error: error writing to flash at address
Andrzej,
please send such reports to openocd-devel mailing list.
Please test http://openocd.zylin.com/6256
Tom
On 17/05/2021 15:20, asier70 wrote:
Hi,
Today I compiled the newest openocd (under ubuntu on windows10). There
is error:
src/target/armv7m.c: In function ‘armv7m_read_core_reg’:
On 05/05/2021 19:45, Marc Schink wrote:
Hi Tomas,
I'm working on a new flash driver and while at it I would like to
change the 'is_erased' member to a proper enum. Do you already work on
this or do you have some opinion on this topic?
Best,
Marc
Hi Marc,
I'm not currently working on this (an
Could you please test
http://openocd.zylin.com/6096
and tell us how it works?
Tom
On 12/04/2021 14:23, Egorov Ivan wrote:
Hi,
Under the windows remote bitbang mode doesn't work.
I looked in sources and find that you used fdopen function with
socket. Thise don't work in Windows.
Look at
https:
e check if this works for you.
If so, let's fix it upstream.
Tarek
-----Original Message-
From: Tomas Vanek via OpenOCD-devel
Sent: Wednesday, February 3, 2021 7:10 PM
To: Tarek BOCHKATI
Cc: OpenOCD ML
Subject: [OpenOCD-devel] STM32H7 stepping broken by CTI
Hi Tarek,
I encountered a pr
Hi Tarek,
I encountered a problem debugging STM32H745 with "set USE_CTI 1".
The step command didn't work, PC didn't advance. I found out that the
problem depends
on setting "cortex_m maskisr auto", it disappears with other maskisr modes.
Well it seems clear: In the maskisr auto mode a dummy ru
Hi Kristof,
On 22/11/2020 11:57, kristof.mul...@telenet.be wrote:
Hi Marc, Tomas, Karl and others,
I noticed some activity on Gerrit regarding the Risc-V based GigaDevice
GD32VF103 microcontroller:
http://openocd.zylin.com/#/c/5839/
I just want to inform all of you that GigaDevice forked Ope
Hi colleagues maintainers/+2 reviewers!
http://openocd.zylin.com/5729
"arm_adi_v5: prevent possibly endless recursion in dap_dp_init()"
is the fix of IMO serious problem.
The patch has already got score +1. Considering it touches
a very important part of code, I'd feel more comfortable
if it gets
tps://pastebin.com/UZHWuh0V
On Thu, Oct 1, 2020 at 2:52 PM Tomas Vanek
mailto:tom_...@users.sourceforge.net>>
wrote:
Try this hack to persuade OpenOCD to keep running without
connectable target:
openocd . -c "catch init"
Using "catch init" instea
Hi Pieter,
On 30/09/2020 16:39, Pieter De Gendt wrote:
Hi,
The following commit adds nrf52_recover to erase and unlock nrf52
APPROTECT
https://sourceforge.net/p/openocd/code/ci/73a5f58adba73306b08b7bb22ff8a9511e79869f/
However this doesn't seem to work for my nrf52840.
There are multiple iss
Hi Christopher,
On 17/07/2020 23:15, Christopher Head wrote:
Hi folks,
I’ve noticed that there are quite a lot of Flash “protect” callbacks
that don’t actually do anything to the hardware. Some of them just loop
through and set the “is_protected” values; one of them (pic32mx)
doesn’t even do tha
Hi Benjamin,
On 06/07/2020 22:32, Benjamin Gutton wrote:
Hi Paul,
Thanks for your answer and hints,
when adding connect_assert_srst I obtain the following:
Warn : 213 455 adi_v5_swd.c:117 swd_connect(): 'srst_nogate'
reset_config option is required
This means that connect_assert_srst
I'm not saying there is no bug, just I'm not able to locate it without
debug log
and/or possibility to replicate.
I tested flashing a single bin file and no problem, went as smoothly as elf.
Be aware that driver checks FCF data to prevent locking the chip
permanently.
It might be the case - if s
Hi Kristof,
On 29/04/2020 17:34, kristof.mul...@telenet.be wrote:
Hi @jmn
I just got the following reply from Reuben Townsend from GigaDevice:
/ Hi Kristof, the GD-LINK uses the CMSIS-DAP interface/
/ and for the GD32E230 MCU, you can use the stm32f0x.cfg/
/ configuration file.///
P
Hi Kristof,
I would highly appreciate if you register to our gerrit at
http://openocd.zylin.com
and start using it instead of spamming the openocd-dev mailing list.
Some time ago you wrote:
Please let me know when you've finished the patch.
If you were in gerrit, I would add you as a review
using the command to nrf51, but your nrf52.
As you could see in the second command I sent you, you should use:
nrf5 mass_erase
BR,
Alan
---
On 3/15/20, kristof.mul...@telenet.be wrote:
Dear Mr. Alan Carvalho de Assis
and
Mr. Tomas Vanek,
Tha
On 14/03/2020 22:57, kristof.mul...@telenet.be wrote:
Unfortunately, OpenOCD has a problem with the flash protection of this
device...
https://devzone.nordicsemi.com/f/nordic-q-a/59106/i-m-trying-to-support-nrf52833-in-embeetle-ide-but-flashing-through-openocd-gdb-doesn-t-work
Your help is gre
On 14.06.2019 0:07, Antonio Borneo wrote:
Also 4290 "target: add reset-halt event" is not part of the series as
is now independent.
Did you mean 4289 "add examine-fail event" ?
4289 is really independent to reset topic, let's do not bother with it now.
4290 "reset-halt event" is used in update
t on top of current master.
> I do not think this ever failed if cherry-picking was actually possible.
In comments of http://openocd.zylin.com/5083 Tomas Vanek wrote:
> Paul, at least twice I experienced situation when change was ready
(CR+2, verified+1) but gerrit Submit button was grey.
sp563xx target
nds32 targets
ETB
EmbeddedICE
If you use any of listed HW, please check register access with OpenOCD
compiled from a recent git master.
Thanks
Tom
On 05.06.2019 21:26, Michael Schwingen wrote:
On 05.06.19 12:30, Tomas Vanek (Code Review) wrote:
Tomas Vanek has posted com
On 05.06.2019 16:10, Matthias Welwarsky wrote:
I don't see SWD multidrop as a candidate for 0.11 so that can wait,
but the reset framework is right now so utterly borked that the
breakage spills over into configuration files. Check the R-CarH3 files
for bad examples.
Neither do I. But the
On 11.05.2019 9:47, matth...@welwarsky.de wrote:
I think we're more than ripe for a new release, but there's one patch
series that I really want to see merged, which is the reset framework
stuff Tomas Vanek has done.
Matthias,
I'm afraid it is not wise to wait for any part
As you may have noticed I've merged 'tcl return values' patch series.
It is based on the Paul's old patch http://openocd.zylin.com/1815
(in gerrit since 2013!!) and the new work by Antonio Borneo.
The great point is that we get rid of all ocd_ prefixed commands.
Now we can use the return value of
due to an overlap of memory regions.
Why GDB is unable to retrieve the proper map from OpenOCD? Is the map
wrong or something else?
Thanks
On Fri, 5 Apr 2019, 17:24 Tomas Vanek, <mailto:tom_...@users.sourceforge.net>> wrote:
I think the relevant change is the commit
81d0b769a65
I think the relevant change is the commit
81d0b769a65bf15dda2fd51cd4aee50bb0dc16fb,
http://openocd.zylin.com/4429
Before this commit Cortex-M OpenOCD target used hardware breakpoints (FPB)
in 'code memory area' 0x-0x1fff, soft breakpoints were set
above 0x2000,
no matter what b
Cortex-M execution / breakpoints:
http://openocd.zylin.com/4862
http://openocd.zylin.com/4870
http://openocd.zylin.com/4887
http://openocd.zylin.com/4889
Breakpoints in general:
http://openocd.zylin.com/4513
___
OpenOCD-devel mailing list
OpenOCD-dev
On 19.11.2018 13:39, Stuart Longland (VK4MSL) wrote:
Hi Tomas,
On 19/11/18 9:34 pm, Tomas Vanek wrote:
yes we all overlooked the pitfall that CC2538 belongs to the cc26xx family.
Can you please test with the last line of tcl/target/cc2538.cfg
changed to
source [find target/ti_cc26xx.cfg
Reviewed-on: http://openocd.zylin.com/4358
Tested-by: jenkins
Reviewed-by: Tomas Vanek
Reviewed-by: Fredrik Hederstierna
The newer code might be the best thing since sliced bread (and may even
allow me to rid myself of TI Uniflash), but until *everything* that
needs it is updated (i.e
1 - 100 of 250 matches
Mail list logo
