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
This is really strange.
The log shows that your nRF52840 does not acknowledge debug power up
(CDBGPWRUPACK, bit[29])
although CDBGPRWUPREQ, bit[28] is correctly set. With powered off the
debug domain there
is no wonder that CTRL-AP can't be read.
I loaded almost original nRF sdk17 examples 'b
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
Kristof,
I confim there is a problem in mass_erase of nRF52833 and 840
Paradoxicallythe mass erase is completed just fine
(you may check using 'flash erase_check 0')
and the bogus error message is generated afterwards because protection
cannot be read. I'll prepare a patch.
http://openocd.zylin
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
In comments of http://openocd.zylin.com/5083 Paul Fertser wrote:
> Tomas, I do not remember ever seeing Gerrit refusing to merge a
commit without a reason.
> The default merge strategy is "cherry-pick" so when you press
"Submit" it just tries to cherry-pick the commit on top of current master.
Hi all,
Michael discovered a regression after merging
http://openocd.zylin.com/4113 "register: support non-existent registers"
See http://openocd.zylin.com/5136 for Michael's XScale specific fix.
I'm afraid that other targets/functions can be influenced too:
avr32 target
dsp563xx target
nds32
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 particular patch or seri
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
Hmm, the gdb 'mem' command needs first to free a mem region by 'delete
mem /number/' - not too handy.
OpenOCD creates memory map based on address regions of the defined flash
banks - all other memory
is marked as rw.
But yes, there is way how to describe the aliased ITCM flash region in
Open
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]
On 19.11.2018 0:38, Stuart Longland (VK4MSL) wrote:
Hi,
Silly question. Can we get 7b03129916aa050f4d120a532659dbbba279f7be
rolled back temporarily?
commit 7b03129916aa050f4d120a532659dbbba279f7be
Author: Edward Fewell
Date: Thu Jan 18 20:48:11 2018 -0600
flash/nor: Add support for T
On 20.08.2018 15:42, Andreas Fritiofson (Code Review) wrote:
Line 66:while (!(*((volatile unsigned *)CMNSR) & TEND));
The style check complains that this empty while loop should look like this:
while (...)
;
This should be mentioned in the style guide. Really not intuitive...
On 05.08.2018 13:33, Svetoslav Enchev wrote:
However, I created a Merge Conflict with this patch:
7d62a54ea0866e59a5bfe0f850dde0a7090deeab "flash/at91sam4: different
erase sector and lock region sizes" and I'm not sure what I should do
about it. It conflicts with the previous patch I made: they
On 03.08.2018 2:28, Christopher Head wrote:
On August 1, 2018 12:15:18 PM PDT, Tomas Vanek via OpenOCD-devel
wrote:
and MEM-AP access goes through DCache.
Of course, some fancy ui wold be nice. Might be set by default in
target.cfg or so.
Yes, that’s perfect, thanks! I’m a little curious why
On 02.08.2018 15:35, Antonio Borneo wrote:
On Wed, Aug 1, 2018 at 9:15 PM, Tomas Vanek via OpenOCD-devel
wrote:
On 01.08.2018 19:13, Christopher Head wrote:
Hello!
I was wondering about how OpenOCD was meant to interoperate with CPU
caches. Right now, the Cortex M target has no cache
On 01.08.2018 19:13, Christopher Head wrote:
Hello!
I was wondering about how OpenOCD was meant to interoperate with CPU caches.
Right now, the Cortex M target has no cache management at all, which means
that, on devices whose debug buses connect directly to RAM, any memory access
through Open
On 04.04.2018 23:18, Tim Newsome wrote:
Let's say I get my target in a state where examine() fails, but a
reset would revive it. It appears that OpenOCD can't do that, because
until `init` has completed, there is no `reset` command. Am I missing
something? How should this kind of situation be d
On 04.04.2018 1:28, Tim Newsome wrote:
src/flash/nor/core.h defines:
|struct flash_bank { ... uint32_t base; /**< The base address of this
bank */ uint32_t size; /**< The size of this chip bank, in bytes */ |
Obviously this is limiting on targets that have 64-bit addresses.
Sure we need to ch
On 20.03.2018 8:54, Matthias Welwarsky wrote:
currently the DAP support for ARMv7 and v8 targets is undergoing a major
restructuring. As a result many target configurations and possibly board
configurations need to be adjusted.
The big change might be also a good opportunity to improve related
Hi Augusto,
see my comments in your message.
On 15.03.2018 14:12, Augusto Fraga Giachero wrote:
I've tried posting (twice) this message to the openocd-devel mailling
list, but it didn't showed up in the archives. Anyway, this list seems
more apropriate.
The mail archives are probably influenced
On 13.03.2018 21:14, Christopher Head wrote:
On March 13, 2018 12:21:47 PM PDT, Tomas Vanek via OpenOCD-devel
wrote:
Obviously faster DAP WAIT handling on USB HS.
The question remains: why are you getting DAP WAITs with algo, is the
reason
different adapter FT2232H vs FT2232C (should not be
On 13.03.2018 19:04, Christopher Head wrote:
OK, here are my test results. All are taken on a JTAG chain with two STM32F745
chips, using an Olimex ARM-USB-TINY-H. In all cases the data is written to the
second chip in the chain and is 473 kilobytes using the command “flash
write_bank 1 filenam
On 13.03.2018 10:40, Uwe Bonnes wrote:
Just for reference: Can anybody test what number gdb reports for the
"load" command in that circumstances? Thanks
Good point, Uwe. Here you go:
FT2232, JTAG, STM32F722-nucleo:
> reset init
...
> adapter_khz
adapter speed: 3000 kHz
> dap memaccess
memory
On 12.03.2018 21:53, Christopher Head wrote:
On March 10, 2018 11:25:15 PM PST, Tomas Vanek via OpenOCD-devel
wrote:
I wouldn't call this case as an obscure one. The reason could be
insufficient device clock rate,
not very high adapter_khz. Anyway all these cases could be solv
Hi Christopher,
On 10.03.2018 19:40, Christopher Head wrote:
One option is I could submit a patch that moves the CR and SR accesses
in the non-algorithm-based code.
Please do.
However, there is a risk that it might possibly cause WAITs where there
weren’t any before if someone was already usi
On 01.03.2018 10:25, Matthias Welwarsky wrote:
WAITs are very strange. It looks like the stalled access to flash
blocks also JTAG access to RAM.
And SWD access doesn't suffer this silicon bug... who knows... maybe
some NOPs in algo busy wait loop would fix it.
BTW The programming algo should avoi
Mattias,
I move our discussion to mailing list to get wider audience.
Recapitulation for others:
OpenOCD used to support old fashioned gdb remote protocol commands 'c' a
's' for resume and step.
These commands can also server as a native synchronization point between
OpenOCD and gdb.
Mattias
On 24.02.2018 0:04, Jay Maynard wrote:
With Paul’s help, I wiggled the SRST line from the console. It’s
showing low pretty much no matter what I do.
Strange. If SRST were asserted why SWD fails randomly?
The SWD lines are pulled up to 3.3V (the same supply that powers the
processor) by 10
I connected my custom SAME70 board to a FT2232 based adapter just to
make sure that current git master works.
It does. See attached log in -d4 level as you used.
There must be some electrical problem in SWD signals, grounding or supply.
Tom
On 23.02.2018 23:06, Jay Maynard wrote:
Apologies f
A FAQ probably for you, Paul... Well, I'm interested too.
Forwarded Message
Subject: Re: Change in openocd[master]: Added support for
STMicroelectronics BlueNRG-1 and BlueNRG-2...
Date: Thu, 22 Feb 2018 15:48:59 +0100
From: Michele Sardo
To: van...@fbl.cz
CC: Ka
Hi all,
I found OpenOCD (git master) with a KitProg adapter hangs when a memory
write of some specific length is issued.
I tested it with CY8CKIT-059 (PSoC5LP) KitProg 2.17 and CY8CKIT-043
(PSoC4200M) KitProg 2.12
on two different PCs with different Ubuntu versions and the problem
appears ever
Hi Fredrik,
On 03.02.2018 11:05, sa...@hederstierna.com wrote:
hi Tomas,
yes lets hope EFR32 support will come soon,
it seems sometimes it real hard to get attention to get patches merged, eg in
the past for CC13xx, EFR32,
and also NRF52.
Then in the other hand sometimes stuff gets merged
Paul,
I see you're working hard on cleaning Clang static analyzer reported
warnings.
I introduced one reported problem in
77a1c01ccbb1150ffe749a7373cf6c4dc15ecad0
in core.c:411
iterate_protect_blocks = false;
is set and no more used. It is intentional guard if somebody touches the
code
and
On 14.01.2018 20:06, Tomas Vanek via OpenOCD-devel wrote:
On 14.01.2018 18:01, Christopher Head wrote:
none of the above attacks would work if you had to, say, type a
password before OpenOCD would accept your Telnet (or GDB, or TCL, or
…) session.
If OpenOCD would require a password it also
On 14.01.2018 18:01, Christopher Head wrote:
none of the above attacks would work if you had to, say, type a password before
OpenOCD would accept your Telnet (or GDB, or TCL, or …) session.
If OpenOCD would require a password it also needs a safe channel to
transfer it. Drop telnet and use a ss
Happy new year to all.
First of all two fixes (important in my opinion):
arm_adi_v5: fix wrong addressing after change of CSW_ADDRINC
http://openocd.zylin.com/4162
(and related http://openocd.zylin.com/4163 )
target: use correct target in target-prefixed commands and event handlers
Choose eithe
On 28.12.2017 19:08, Thomas Sailer wrote:
Tomas,
I have implemented PSoC4 acquire in the ftdi driver, see the attached
patch. Since the ftdi driver cannot use a close polling loop for
determining when the PSoC4 is finished resetting like the KitProg
firmware does, the ftdi driver needs to iss
Oh yes, version 2 of KitProg complicates it further as the USB protocol
substantially differs.
I'm not aware of any documentation on it - ask Cypress.
Are you volunteer to implement KitProg2 protocol in OpenOCD?
BTW KitProg(1) driver was reverse engineered, no doc as well.
Although not working '
Bad luck. Looks like a sudden death of the internal flash.
Please don't blame the mass_erase command in OpenOCD:
the command just sets one bit (bit 0 in MDM-AP control register) to instruct
the internal flash controller to erase the device. And it was tested
many times
on many devices including
Try
kinetis mdm halt
for the case if reset is not properly connected on the board.
And if it fails, proceed as suggested in the message:
If MCU cannot be halted, it is likely secured and running
in RESET/WDOG loop. Issue 'kinetis mdm mass_erase'
There is no point
The log is normal for a blank kinetis device.
You've configured reset correctly. Just continue.
So either issue 'reset init' command to see target halted
or start programming by 'program your_shiny_fw.elf'
On 04.12.2017 15:59, mark.vandoesb...@hetnet.nl wrote:
Hello Tom,
Forgot to mail the list
Have you tried what the warning message recommends you?
You probably have to add -c 'reset_config srst_only'
to OpenOCD command line and then programming should work.
If not, attach -d3 log.
Tom
On 04.12.2017 9:46, mark.vandoesb...@hetnet.nl wrote:
Hello,
I have bought a NXP Kinetis TWR-KV58F2
On 22.11.2017 1:47, Thomas Sailer wrote:
do you know whether your PSoC4 flash driver supports the 4S devices?
If not what would be needed to make it work?
Both the latest release 0.10 and git master support only the oldest
PSoC4 without suffix.
There is a pending change http://openocd.zylin
Hi Bohdan,
On 21.11.2017 14:55, Bohdan Tymkiv wrote:
>> psoc6.cpu.cmX configure -event reset-deassert-post
> PSoC6 clears AP TAR and OpenOCD does not know about it - ROM 0 is
read instead of DHSCR.
> arp_examine should be added to both post-deassert event handlers.
> mww does not work in 'rese
Hi Bohdan,
The PSoC4 autoerase trick is a must as PSoC4 does not implement row
erase - only mass erase is available.
In principle it is possible to use /flash_bank->sectors[i]->is_erased
/The problem is how to keep flags in sync when user firmware programs or
erases the flash.
Therefore most
On 04.11.2017 22:40, Andreas Fritiofson wrote:
On Sat, Nov 4, 2017 at 10:13 PM, Tomas Vanek
mailto:tom_...@users.sourceforge.net>>
wrote:
On 04.11.2017 21:53, Andreas Fritiofson wrote:
Why isn't the corresponding target always passed to the Tcl event
handler (in target_handle_
I redirected CC to mailing list, maybe somebody knows more.
On 04.11.2017 22:49, Åke Rehnman wrote:
I have been staring at this piece of code in stm8_reset_assert which
is stolen form hla_target:
if (target->reset_halt) {
target->state = TARGET_RESET;
target->debug_reason
On 04.11.2017 22:40, Andreas Fritiofson wrote:
On Sat, Nov 4, 2017 at 10:13 PM, Tomas Vanek
mailto:tom_...@users.sourceforge.net>>
wrote:
On 04.11.2017 21:53, Andreas Fritiofson wrote:
Why isn't the corresponding target always passed to the Tcl event
handler (in target_handle_
On 04.11.2017 21:53, Andreas Fritiofson wrote:
On Wed, Nov 1, 2017 at 8:22 AM, Tomas Vanek via OpenOCD-devel
<mailto:openocd-devel@lists.sourceforge.net>> wrote:
Hi all,
I need to create an event routine which is aware of a currently
processed target.
The ea
On 02.11.2017 23:13, Åke Rehnman wrote:
On 2017-11-02 11:14, Tomas Vanek wrote:
So I propose for #3952 (the real code should check errors of course):
Were you able to have a look at the implementation I cooked up in the
latest change set? Basically I just emit a mode enter before
stlink_usb_
A comment in my proposal:
On 02.11.2017 11:14, Tomas Vanek via OpenOCD-devel wrote:
/* preliminary SRST assert:
* We want SRST is asserted before activating debug signals (mode_enter).
* As the required mode has not been set, the adapter may not know what
pin to use.
* Tested firmware STLINK
I looked to a STM32F4Disco schematics and it confirms my thought - SWIM
RST is on PB7,
T_NRST is on PB0. So you're right too: before entering a mode the dongle
does not know,
what pin to use. This is only a default value in dongle fw, what selects
T_NRST to be asserted.
So I propose for #3952 (
Hi all,
In startup.tcl, ocd_process_reset_inner() there are loops invoking
events for
all targets. Like this one:
set targets [target names]
foreach t $targets {
$t invoke-event reset-assert-pre
}
I need to create an event routine which is aware of a currently
processed target.
The e
On 27.09.2017 0:04, David 'Miller' Lowe wrote:
Hi Tomas,
Thanks for looking into this. I ran the command in the same session
that I started yesterday and it looks in the ball park but I'm not
sure what it's supposed to say.
Should I try to load an image with GDB or the openocd flash command
On 25.09.2017 21:48, David 'Miller' Lowe wrote:
I think the listing got truncated.. Here is the same output with the
commands issued from a connected telnet session.
Sorry David, flash banks command does not trigger flash probe.
Try 'flash info 0' and if result is wrong, send -d3 log of this co
On 25.09.2017 20:40, David 'Miller' Lowe wrote:
I have replaced KEAZ128 my processor and am stepping more lightly now
(as trying to flash with GDB caused the chip to brick last time).
Should the 'flash banks' command reply accurately? It replies size=0
but should be 0x2
Miller
Please
Hi,
Paul suggested target/kx.xfg from OpenOCD distribution.
You are using kinetis_256k.cfg you've found somewhere on the net.
Although your config might work with some ancient OpenOCD version,
it does not work well with current OpenOCD.
BTW Programming worked, the verify error is caused by FCF
Two small fixes of Kinetis flash driver:
http://openocd.zylin.com/4173
http://openocd.zylin.com/4180
Thanks
Tom
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! ht
On 29.06.2017 21:05, David 'Miller' Lowe wrote:
src/flash/nor/kinetis.c
In kinetics_read_part_info() I had to add a 'case 0x01' to the
switch(fcfg1_nvmsize) around line 1373.
You are referring to some old code and it is not clear what version.
Moreover "switch(fcfg1_nvmsize)" can hardly ma
Thanks a lot, Freddie.
There is also a part of Mark Shink's series ready:
http://openocd.zylin.com/3859
http://openocd.zylin.com/3860
http://openocd.zylin.com/3861
http://openocd.zylin.com/3862
Tom
On 17.06.2017 13:02, Freddie Chopin (Code Review) wrote:
Freddie Chopin has submitted this chang
Repeating request after almost 2 months of waiting:
On 21.04.2017 21:38, Tomas Vanek wrote:
Kinetis pack:
http://openocd.zylin.com/3896
http://openocd.zylin.com/3897
http://openocd.zylin.com/3898
http://openocd.zylin.com/3900
http://openocd.zylin.com/3901
http://openocd.zylin.com/3924
http://ope
openocd -f interface/cmsis-dap.cfg -f target/at91samdXX.cfg -c
cmsis_dap_init_samd_cold_plug -c init -c "at91samd chip-erase"
On 08.06.2017 17:34, William Hanna wrote:
Ok, swapped over to cmsis-dap adapter and still no luck.
https://pastebin.com/6k6ULseG
Thanks for you help.
On Jun 8, 2017,
The cold-plug solution (4044) is for CMSIS-DAP adapter only.
No wonder it does not work with J-Link.
On 08.06.2017 16:09, William Hanna wrote:
Tom,
I read your post, which I somehow missed when searching for a
solution, and pulled the latest master. Changed atsamd91.c and
cmsis_dap_usb.c to pa
On 08.06.2017 13:51, William Hanna wrote:
Has anyone had any success with using openocd to erase ATSAMDA1 or
ATSAMC21 devices which have the security enabled?
The command:'at91samd chip-erase’ says it will erase the device when
security enabled. However when the security is set openocd doesn’t
77 matches
Mail list logo
