openocd-user — User support list for OpenOCD

Re: [OpenOCD-user] STM32F3 - 'flash write_image' failed with error code -4. Flashing with STM32CubeProgrammer works.

[Zixian Z. <syc...@gm...>]

Hi Paul:

On Fri, Jul 18, 2025 at 05:24:11PM +0000, Paul Rothhammer-Ruiz wrote:
> Hello OpenOCD developers,
> 
> I am using OpenOCD version 0.12.0 on a windows machine (openOCD is running on MSYS2). I have successfully used openOCD for years. Recently when using an STM32F334 (64KB flash size), I am occasionally getting  errors when flashing. The error message is: "Error: error writing to flash at address 0x08000000 at offset 0x00000000." This error seems to be binary file dependent. Flashing will immediately work again on openOCD if I switch over to flashing a "known good" binary file. In fact, I can often get a problematic binary file to flash successfully if I delete random lines of code in the file.
> I would think the issue is the size of the binary file, however, I am able to successfully flash the "bad" binary file using the STM32CubeProgrammer. I confirmed this by doing a simple LED blink program; it would not flash with OpenOCD but LEDs did blink once I tried with STM32CubeProgrammer. When using the size utility (arm-none-eabi-size) I get text=12652, data=120, bss=1696, dec=14468. I should have plenty of space left on the STM32F334. I am using default the default linker script generated by the STM32CubeProgrammer.
> When I enable a verbose output on OpenOCD, I see the following error message:
> "Error: 596 2811 core.c:96 flash_driver_write(): error writing to flash at address 0x08000000 at offset 0x00000000
> Debug: 597 2815 command.c:545 run_command(): Command 'flash write_image' failed with error code -4"
> Please advise how I can best troubleshoot this issue. I rely on OpenOCD for flashing and debugging.
> Thank you in advance!
> 
> Regards,
> Paul

I have similar issue before when I was using the STM32H755ZI-Q with dual
cores. The most possible reason I can guess is "You LOCKED your flash
accidentally".

If I remembered correctly, flash memory on STM32 might trap
into a "broken state" when you did something "bad".

According to STM32H755ZI-Q user guide, STM32CubeProgrammer can help to
erase the broken flash sector. I have try it and after that I find a
similar feature in OpenOCD, you can use "-c help" option and search
keyword "flash" on your board.

For your reference, I used the similar commands like following one:
	openocd -f interface/stlink.cfg -f target/stm32h7x_dual_bank.cfg -c init -c "flash erase_sector 0 0 last"

I not a develop of OpenOCD, Sorry if I was misleading.

Best regards,
Zixian

[OpenOCD-user] STM32F3 - 'flash write_image' failed with error code -4. Flashing with STM32CubeProgrammer works.

[Paul Rothhammer-R. <Pau...@lu...>]

Hello OpenOCD developers,

I am using OpenOCD version 0.12.0 on a windows machine (openOCD is running on MSYS2). I have successfully used openOCD for years. Recently when using an STM32F334 (64KB flash size), I am occasionally getting  errors when flashing. The error message is: "Error: error writing to flash at address 0x08000000 at offset 0x00000000." This error seems to be binary file dependent. Flashing will immediately work again on openOCD if I switch over to flashing a "known good" binary file. In fact, I can often get a problematic binary file to flash successfully if I delete random lines of code in the file.
I would think the issue is the size of the binary file, however, I am able to successfully flash the "bad" binary file using the STM32CubeProgrammer. I confirmed this by doing a simple LED blink program; it would not flash with OpenOCD but LEDs did blink once I tried with STM32CubeProgrammer. When using the size utility (arm-none-eabi-size) I get text=12652, data=120, bss=1696, dec=14468. I should have plenty of space left on the STM32F334. I am using default the default linker script generated by the STM32CubeProgrammer.
When I enable a verbose output on OpenOCD, I see the following error message:
"Error: 596 2811 core.c:96 flash_driver_write(): error writing to flash at address 0x08000000 at offset 0x00000000
Debug: 597 2815 command.c:545 run_command(): Command 'flash write_image' failed with error code -4"
Please advise how I can best troubleshoot this issue. I rely on OpenOCD for flashing and debugging.
Thank you in advance!

Regards,
Paul


This message and any attachments are Confidential Information, for the exclusive use of the addressee and may be legally privileged. Any receipt by anyone other than the intended addressee does not constitute a loss of the confidential or privileged nature of the communication. Any other distribution, use or reproduction is unauthorized and prohibited. If you are not the intended recipient, please contact the sender by return electronic mail and delete all copies of this communication

Re: [OpenOCD-user] ti: using GDB debugging MSPM0G3507-launchpad?

[Paul F. <fer...@gm...>]

On Thu, Jul 17, 2025 at 12:28:16PM +0800, Zixian Zeng wrote:
> On Wed, Jul 16, 2025 at 11:42:06AM +0300, Paul Fertser wrote:
> > On Wed, Jul 16, 2025 at 01:01:37PM +0800, Zixian Zeng wrote:
> > > I like using OpenOCD and GDB to debug programs on STM32. On STM32 I just
> > > need to do
> > > > openocd -f board/stm32f3discovery.cfg
> > > > arm-none-eabi-gdb <executable> #in other terminal
> > > And using `tar ext :3333`
> > 
> > Good to hear you like it and it's easy with STM32F3, your commands are
> > correct. BTW, you can use gdb-multiarch (or just gdb on Fedora) from
> > your distro repository, no need for a special arm-none-eabi version.
> > 
> Thanks for your suggestion, but I use Gentoo as Linux distribution,
> which doesn't have gdb-multiarch package. :-(

But it has "multitarget" USE flag for GDB ebuild.

> > > I found board/ti_mspm0_launchpad.cfg in mainline repo, and using the
> > > latest openocd right away. I can connect to the board and program it.
> > > But I can not debug it
> > 
> > What exactly "can not debug" implies? You can see full interaction
> > between GDB and OpenOCD if you do "set debug remote 1" before running
> > "target" command.
> > 
> I try enable the debug information and dump the log to:
> https://nopaste.net/sDiGiAeWyS

Are you sure there's anything inside that while (1) loop you're trying
to step through? Please look through the disassembly. Also try going
instruction by instruction with "stepi".

> > > and nothing happens when I reset board through GDB "monitor
> > > mspm0_board_reset" command.
> > 
> > That is a special command to simulate power on reset it seems. Why
> > exactly are you trying to use it, what you expect and what actually
> > happens?
> > 
> 
> Simply I want to reset the board and let it execute the first
> instruction.

Then it would be "mon reset halt" and then "si".

> I also try using "monitor reset [halt]" but nothing
> happens.

It can not be nothing, and it's not there in your log.

Monitor commands is something GDB doesn't track, they're just passed
through, so if you something like "mon reset halt" and you want to see
the result in GDB you need to do "mon gdb_sync" and then "si" to let
GDB sync.

BTW, "reset" without argument is "reset run" so a different command,
it doesn't even try to halt.

> So I doubt that I can not use GDB debugging programs compiled by
> "tiarmclang". Or can I use GNU toolchain to develop MSPM0G3507-LaunchPad ?

GDB seem to be picking up debugging info from your ELF file properly,
at least your current log doesn't show anything obviously wrong about
it.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [OpenOCD-user] ti: using GDB debugging MSPM0G3507-launchpad?

[Zixian Z. <syc...@gm...>]

On Wed, Jul 16, 2025 at 11:42:06AM +0300, Paul Fertser wrote:
> Hi Zixian,
> 
> On Wed, Jul 16, 2025 at 01:01:37PM +0800, Zixian Zeng wrote:
> > I like using OpenOCD and GDB to debug programs on STM32. On STM32 I just
> > need to do
> > > openocd -f board/stm32f3discovery.cfg
> > > arm-none-eabi-gdb <executable> #in other terminal
> > And using `tar ext :3333`
> 
> Good to hear you like it and it's easy with STM32F3, your commands are
> correct. BTW, you can use gdb-multiarch (or just gdb on Fedora) from
> your distro repository, no need for a special arm-none-eabi version.
> 
Thanks for your suggestion, but I use Gentoo as Linux distribution,
which doesn't have gdb-multiarch package. :-(

> > I found board/ti_mspm0_launchpad.cfg in mainline repo, and using the
> > latest openocd right away. I can connect to the board and program it.
> > But I can not debug it
> 
> What exactly "can not debug" implies? You can see full interaction
> between GDB and OpenOCD if you do "set debug remote 1" before running
> "target" command.
> 
I try enable the debug information and dump the log to:
https://nopaste.net/sDiGiAeWyS

At the same time, the OpenOCD side shows the error messages:
	Info : Listening on port 3333 for gdb connections
	Info : accepting 'gdb' connection on tcp/3333
	[mspm0x.cpu] halted due to debug-request, current mode: Thread
	xPSR: 0x01000000 pc: 0x0000016a msp: 0x20208000
	Info : Data region NOT available!
	Info : [mspm0x.cpu] Not running when halt was requested, stopping GDB.
	(state=2)
	Info : [mspm0x.cpu] Not running when halt was requested, stopping GDB.
	(state=2)
	Info : [mspm0x.cpu] Not running when halt was requested, stopping GDB.
	(state=2)

> > and nothing happens when I reset board through GDB "monitor
> > mspm0_board_reset" command.
> 
> That is a special command to simulate power on reset it seems. Why
> exactly are you trying to use it, what you expect and what actually
> happens?
> 

Simply I want to reset the board and let it execute the first
instruction. I also try using "monitor reset [halt]" but nothing
happens. Since that I find the "mspm0_board_reset" command from the
help page.

> > Info : accepting 'gdb' connection on tcp/3333			<----- GDB attaching
> > [mspm0x.cpu] halted due to debug-request, current mode: Thread
> > xPSR: 0x01000000 pc: 0x0000016a msp: 0x20208000
> > Info : Data region NOT available!
> 
> Everything looks correct so far. The last message means target MCU
> doesn't have any dedicated data flash region but that's to be
> expected, right?
> 
Yes, you're right, so I think the problem is mainly caused by the error
messages above.

> > I want to ask if the GDB debugging feature is under developing or I used
> > it incorrectly? Thanks for any suggestions.
> 
> It should just work, Cortex-M is not a new target.
> 

I hope it will, thanks you very much.

I want to say one thing, which might important. Or not? I'm not sure.
On STM32 platform which I rather familiar with I compile my code using
the full GNU toolchain. But I'm not familiar with TI MSPM0G3507-LaunchPad
so far, I used the CCS (Code Composer Studio™ integrated development environment)
provided by TI and compiled code in "tiarmclang" tool chain.

So I doubt that I can not use GDB debugging programs compiled by
"tiarmclang". Or can I use GNU toolchain to develop MSPM0G3507-LaunchPad ?

> -- 
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fer...@gm...

Best regards,
Zixian

Re: [OpenOCD-user] ti: using GDB debugging MSPM0G3507-launchpad?

[Paul F. <fer...@gm...>]

Hi Zixian,

On Wed, Jul 16, 2025 at 01:01:37PM +0800, Zixian Zeng wrote:
> I like using OpenOCD and GDB to debug programs on STM32. On STM32 I just
> need to do
> > openocd -f board/stm32f3discovery.cfg
> > arm-none-eabi-gdb <executable> #in other terminal
> And using `tar ext :3333`

Good to hear you like it and it's easy with STM32F3, your commands are
correct. BTW, you can use gdb-multiarch (or just gdb on Fedora) from
your distro repository, no need for a special arm-none-eabi version.

> I found board/ti_mspm0_launchpad.cfg in mainline repo, and using the
> latest openocd right away. I can connect to the board and program it.
> But I can not debug it

What exactly "can not debug" implies? You can see full interaction
between GDB and OpenOCD if you do "set debug remote 1" before running
"target" command.

> and nothing happens when I reset board through GDB "monitor
> mspm0_board_reset" command.

That is a special command to simulate power on reset it seems. Why
exactly are you trying to use it, what you expect and what actually
happens?

> Info : accepting 'gdb' connection on tcp/3333			<----- GDB attaching
> [mspm0x.cpu] halted due to debug-request, current mode: Thread
> xPSR: 0x01000000 pc: 0x0000016a msp: 0x20208000
> Info : Data region NOT available!

Everything looks correct so far. The last message means target MCU
doesn't have any dedicated data flash region but that's to be
expected, right?

> I want to ask if the GDB debugging feature is under developing or I used
> it incorrectly? Thanks for any suggestions.

It should just work, Cortex-M is not a new target.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

[OpenOCD-user] ti: using GDB debugging MSPM0G3507-launchpad?

[Zixian Z. <syc...@gm...>]

Hi, dear OpenOCD users and developers:

I'm new bird and currently trying to changing developing board from
STM32F3-discovery to TI MSPM0G3507-LaunchPad.

I like using OpenOCD and GDB to debug programs on STM32. On STM32 I just
need to do
> openocd -f board/stm32f3discovery.cfg
> arm-none-eabi-gdb <executable> #in other terminal
And using `tar ext :3333`

I found board/ti_mspm0_launchpad.cfg in mainline repo, and using the
latest openocd right away. I can connect to the board and program it.
But I can not debug it and nothing happens when I reset board through
GDB "monitor mspm0_board_reset" command.

Log below:
$ sudo openocd -f board/ti_mspm0_launchpad.cfg
Open On-Chip Debugger 0.12.0+dev-01084-gcbc32c383 (2025-07-15-10:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Warn : DEPRECATED: auto-selecting transport "swd". Use
'transport select swd' to suppress this message.
Warn : Transport "swd" was already selected
cortex_m reset_config sysresetreq
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : XDS110: connected
Info : XDS110: vid/pid = 0451/bef3
Info : XDS110: firmware version = 3.0.0.38
Info : XDS110: hardware version = 0x0028
Info : XDS110: connected to target via SWD
Info : XDS110: SWCLK set to 2500 kHz
Info : clock speed 10000 kHz
Info : SWD DPIDR 0x6ba02477
Info : [mspm0x.cpu] Cortex-M0+ r0p1 processor detected
Info : [mspm0x.cpu] target has 4 breakpoints, 2 watchpoints
Info : [mspm0x.cpu] Examination succeed
Info : [mspm0x.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333			<----- GDB attaching
[mspm0x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0000016a msp: 0x20208000
Info : Data region NOT available!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I want to ask if the GDB debugging feature is under developing or I used
it incorrectly? Thanks for any suggestions.

Best regards,
Zixian

Re: [OpenOCD-user] Openocd does not appear to reset the target properly.

[Paul F. <fer...@gm...>]

On Sun, Jun 22, 2025 at 09:51:53AM -0700, Thomas D. Dean wrote:
> Here is the question: Why did cycling power also fix the problem? There is
> no OS, so memory use should be static. Something in core 0 is using the
> stack allocated to core1_main. Maybe in cyw43? I don't think pico-sdk.

I suspect some race condition. What OpenOCD does (have to) is using
SYSRESETREQ on one core, then on the other (probably, not sure,
haven't worked with SMP targets like that, you can see what exactly is
happening in that regard with -d3 option). While Power-On-Reset I
guess is doing it simultaneously so they start running (or the second
core starts stopped?) at the same time.

Regular targets just have an external RESET (SRST) signal which
adapter pulls down same as a reset button or external watchdog would.

I do not have a good explanation of why it can lead exactly to what
you describe (I'm not sure what "starting core 1" and "exiting main"
implies on this platform to begin with).

I wonder if it behaves differently if you instead try
-c "program /path/to.elf verify; reset halt; resume; shutdown"

(reset halt should make the cores stop at reset vector first)

> Thanks for your help. Sorry for the noise. We did find one problem. Is
> someone going to make the change in git?

Eventually, yes :) Thank you for reporting it.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [OpenOCD-user] Openocd does not appear to reset the target properly.

[Thomas D. D. <to...@wa...>]

On 6/21/25 22:23, Paul Fertser wrote:

I found a what but not a why.

Near the start of main, I launch core 1. core1_main starts some DMA, 
PIO, allocates an alarm pool starts a repeating timer, then exits. For 
now, there is nothing for core1_main to do. All the action of core 1 is 
in the timer callback, DMA, or PIO.

Stopping core1_main from exiting fixed the problem. Interestingly, 
delaying the exit of core1_main by 250 msec, also fixed the problem.

The alarm pool variable was on the stack! If core1_main exited too soon, 
something messed up core 0 and the web page was not available. The 
repeating timer fired at least one time after core1_main exited.

Making the alarm pool variable static (as it should have been) also 
fixed the problem.

This will be mixed with some code I don't control, so I want to limit 
variable scope.

Here is the question: Why did cycling power also fix the problem? There 
is no OS, so memory use should be static. Something in core 0 is using 
the stack allocated to core1_main. Maybe in cyw43? I don't think pico-sdk.

Thanks for your help. Sorry for the noise. We did find one problem. Is 
someone going to make the change in git?

Tom Dean

Re: [OpenOCD-user] Openocd does not appear to reset the target properly.

[Paul F. <fer...@gm...>]

On Sat, Jun 21, 2025 at 04:28:33PM -0700, Thomas D. Dean wrote:
> On 6/21/25 15:49, Paul Fertser wrote:
> > On Sat, Jun 21, 2025 at 03:31:56PM -0700, Thomas D. Dean wrote:
> > > If I
> > > 1. connect the RPi debug probe to USB and pico_w.
> > > 2. power on the pico_w.
> > > 3. sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg \
> > >       -c "adapter speed 5000" -c "program $1 verify reset exit"
> > 
> > This looks correct, I have nothing to suggest here.
> > 
> > > Openocd seems to finish without error.
> > > 
> > > Attempting to connect with firefox never does, just sets there
> > > spining.
> > 
> > And here I would suggest to connect with GDB to see what it is doing
> > and why it is stuck where.
> > 
> > > I noticed that cmake says the build type for my project is release, the
> > > *.elf file has debug symbols. and openocd output has debug and breakpoint.
> > 
> > Debug symbols are used by GDB, OpenOCD doesn't parse any of it from
> > ELF. And BTW, adding full debug information doesn't increase the
> > amount of flash used, it's all in special ELF sections which are not
> > copied to the target at all.
> > 
> 
> I looked with gdb. The code is in a while loop, waiting for the html, as it
> should be.
> 
> The only concern is the need to cycle power after writing flash.

I hope looking with GDB before power cycling should provide the
clues about what specifically is different with power-on-reset
vs. SYSRESETREQ.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [OpenOCD-user] Openocd does not appear to reset the target properly.

[Thomas D. D. <to...@wa...>]

On 6/21/25 15:49, Paul Fertser wrote:
> On Sat, Jun 21, 2025 at 03:31:56PM -0700, Thomas D. Dean wrote:
>> If I
>> 1. connect the RPi debug probe to USB and pico_w.
>> 2. power on the pico_w.
>> 3. sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg \
>>       -c "adapter speed 5000" -c "program $1 verify reset exit"
> 
> This looks correct, I have nothing to suggest here.
> 
>> Openocd seems to finish without error.
>>
>> Attempting to connect with firefox never does, just sets there
>> spining.
> 
> And here I would suggest to connect with GDB to see what it is doing
> and why it is stuck where.
> 
>> I noticed that cmake says the build type for my project is release, the
>> *.elf file has debug symbols. and openocd output has debug and breakpoint.
> 
> Debug symbols are used by GDB, OpenOCD doesn't parse any of it from
> ELF. And BTW, adding full debug information doesn't increase the
> amount of flash used, it's all in special ELF sections which are not
> copied to the target at all.
> 

I looked with gdb. The code is in a while loop, waiting for the html, as 
it should be.

The only concern is the need to cycle power after writing flash.

Thanks,
Tom Dean

Re: [OpenOCD-user] Openocd does not appear to reset the target properly.

[Paul F. <fer...@gm...>]

On Sat, Jun 21, 2025 at 03:31:56PM -0700, Thomas D. Dean wrote:
> If I
> 1. connect the RPi debug probe to USB and pico_w.
> 2. power on the pico_w.
> 3. sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg \
>      -c "adapter speed 5000" -c "program $1 verify reset exit"

This looks correct, I have nothing to suggest here.

> Openocd seems to finish without error.
> 
> Attempting to connect with firefox never does, just sets there
> spining.

And here I would suggest to connect with GDB to see what it is doing
and why it is stuck where.

> I noticed that cmake says the build type for my project is release, the
> *.elf file has debug symbols. and openocd output has debug and breakpoint.

Debug symbols are used by GDB, OpenOCD doesn't parse any of it from
ELF. And BTW, adding full debug information doesn't increase the
amount of flash used, it's all in special ELF sections which are not
copied to the target at all.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [OpenOCD-user] Openocd does not appear to reset the target properly.

[Thomas D. D. <to...@wa...>]

On 6/21/25 11:21, Paul Fertser wrote:
> Hello Thomas,
> 
> On Sat, Jun 21, 2025 at 09:11:15AM -0700, Thomas D. Dean wrote:
>> CX seems to come from rp2040.cfg line 88
> ...
>> Debug: 42 2 command.c:86 script_debug(): command - rp2040.core0 configure -event reset-init  rp2xxx rom_api_call 0 CX
> 
> Indeed, that number 0 shouldn't be there. Please try to modify this
> config file to have just "rp2xxx rom_api_call 0 CX".
> 
 > git diff
diff --git a/tcl/target/rp2040.cfg b/tcl/target/rp2040.cfg
index da88a3125..80b4b138c 100644
--- a/tcl/target/rp2040.cfg
+++ b/tcl/target/rp2040.cfg
@@ -85,7 +85,7 @@ if { $_USE_CORE != 1 } {

  	# After a rescue reset and fi BOOTSEL is halted connect the flash to 
enable
  	# reads from the XIP cached mapping area
-	$_TARGETNAME_0 configure -event reset-init { rp2xxx rom_api_call 0 CX }
+	$_TARGETNAME_0 configure -event reset-init { rp2xxx rom_api_call CX }
  }

  # core 1


That fixed the CX error.  But, it seems openocd does not cleanly reset 
the pico_w. Thanks.

If I
1. connect the RPi debug probe to USB and pico_w.
2. power on the pico_w.
3. sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg \
      -c "adapter speed 5000" -c "program $1 verify reset exit"

Openocd seems to finish without error.

Attempting to connect with firefox never does, just sets there spining.

4. Cycle power on the pico_w

Now, firefox connects and displays the page properly.

I noticed that cmake says the build type for my project is release, the 
*.elf file has debug symbols. and openocd output has debug and breakpoint.

 > sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg \
      -c "adapter speed 5000" -c "program $1 verify reset exit"
Open On-Chip Debugger 0.12.0+dev-01055-ga9015ba79 (2025-06-21-15:53)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : [rp2040.core0] Hardware thread awareness created
Info : [rp2040.core1] Hardware thread awareness created
adapter speed: 5000 kHz
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, 
serial=E6614103E73C8B25
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 5000 kHz
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001
Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
Info : [rp2040.core0] Examination succeed
Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints
Info : [rp2040.core1] Examination succeed
Info : [rp2040.core0] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
[rp2040.core0] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
[rp2040.core1] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
Info : RP2040 rev 2, QSPI Flash win w25q16jv id = 0x1540ef size = 2048 
KiB in 512 sectors
Info : RP2xxx ROM API function CX @ 2321
** Programming Started **
Info : Padding image section 1 at 0x1004c324 with 220 bytes (bank write 
end alignment)
Warn : Adding extra erase range, 0x1004c400 .. 0x1004cfff
Info :   Erase chunk: 0x00000000 -> 0x0001ffff
Info :   Erase chunk: 0x00020000 -> 0x0003ffff
Info :   Erase chunk: 0x00040000 -> 0x0004cfff
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked

Any ideas?

Tom Dean

Re: [OpenOCD-user] Openocd does not appear to reset the target properly.

[Paul F. <fer...@gm...>]

Hello Thomas,

On Sat, Jun 21, 2025 at 09:11:15AM -0700, Thomas D. Dean wrote:
> CX seems to come from rp2040.cfg line 88
...
> Debug: 42 2 command.c:86 script_debug(): command - rp2040.core0 configure -event reset-init  rp2xxx rom_api_call 0 CX

Indeed, that number 0 shouldn't be there. Please try to modify this
config file to have just "rp2xxx rom_api_call 0 CX".

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [OpenOCD-user] Openocd does not appear to reset the target properly.

[Thomas D. D. <to...@wa...>]

On 6/21/25 00:33, Antonio Borneo wrote:

> the git SHA1 reported in the line above '8b8c9731a' does not match
> anything in OpenOCD upstream.
> Are you using a fork taken somewhere else?

That version was from https://github.com/raspberrypi/openocd.git

I will try from https://git.code.sf.net/p/openocd/code

Same result. No time now, I will try to chase this in a couple hours.

CX seems to come from rp2040.cfg line 88

For now,

 > sudo openocd -d -f interface/cmsis-dap.cfg -f target/rp2040.cfg \
      -c "adapter speed 5000" -c "program $1 verify reset exit" \
      2>&1 | grep CX

Debug: 37 2 command.c:86 script_debug(): command - dap create 
rp2040.dap0 -chain-position rp2040.cpu -dp-id 0x01002927 -instance-id 0
Debug: 38 2 command.c:86 script_debug(): command - target create 
rp2040.core0 cortex_m -dap rp2040.dap0 -coreid 0
Debug: 39 2 command.c:191 register_command(): command 'tpiu' is already 
registered
Debug: 40 2 command.c:191 register_command(): command 'rtt' is already 
registered
Debug: 41 2 command.c:86 script_debug(): command - rp2040.core0 cortex_m 
reset_config sysresetreq
Debug: 42 2 command.c:86 script_debug(): command - rp2040.core0 
configure -event reset-init  rp2xxx rom_api_call 0 CX
Debug: 43 2 command.c:86 script_debug(): command - dap create 
rp2040.dap1 -chain-position rp2040.cpu -dp-id 0x01002927 -instance-id 1
Debug: 44 2 command.c:86 script_debug(): command - target create 
rp2040.core1 cortex_m -dap rp2040.dap1 -coreid 1
Debug: 45 2 command.c:191 register_command(): command 'arm' is already 
registered
Debug: 46 2 command.c:191 register_command(): command 'arm core_state' 
is already registered
Debug: 47 2 command.c:191 register_command(): command 'arm disassemble' 
is already registered
--
Debug: 374 716 command.c:86 script_debug(): command - rp2040.core1 curstate
Debug: 375 716 command.c:86 script_debug(): command - transport select
Debug: 376 716 command.c:86 script_debug(): command - rp2040.core0 
was_examined
Debug: 377 716 command.c:86 script_debug(): command - rp2040.core0 
arp_waitstate halted 5000
Debug: 378 717 command.c:86 script_debug(): command - rp2040.core0 
invoke-event reset-init
Debug: 379 717 target.c:4675 target_handle_event(): target: rp2040.core0 
(cortex_m) event: 15 (reset-init) action:  rp2xxx rom_api_call 0 CX
Debug: 380 717 command.c:86 script_debug(): command - rp2xxx 
rom_api_call 0 CX
Debug: 381 717 target.c:2571 target_read_u32(): address: 0x40000000, 
value: 0x20002927
Debug: 382 718 target.c:2571 target_read_u32(): address: 0x00000010, 
value: 0x0301754d
Debug: 383 718 rp2xxx.c:220 rp2040_lookup_rom_symbol(): Looking up ROM 
symbol 'EX' in RP2040 table
Debug: 384 718 arm_adi_v5.c:400 
mem_ap_setup_transfer_verify_size_packing(): AP#0x0 probed size 2: supported
Debug: 385 718 target.c:2595 target_read_u16(): address: 0x00000014, 
value: 0x007a
--
Debug: 479 735 target.c:2595 target_read_u16(): address: 0x000000b6, 
value: 0x5052
Debug: 480 735 target.c:2595 target_read_u16(): address: 0x000000ba, 
value: 0x4346
Debug: 481 735 target.c:2595 target_read_u16(): address: 0x000000bc, 
value: 0x2351
Debug: 482 735 rp2xxx.c:246 rp2040_lookup_rom_symbol():  -> found: 0x2351
Debug: 483 735 target.c:2571 target_read_u32(): address: 0x00000010, 
value: 0x0301754d
Debug: 484 735 rp2xxx.c:220 rp2040_lookup_rom_symbol(): Looking up ROM 
symbol 'CX' in RP2040 table
Debug: 485 736 target.c:2595 target_read_u16(): address: 0x00000014, 
value: 0x007a
Debug: 486 736 target.c:2595 target_read_u16(): address: 0x0000007a, 
value: 0x3350
Debug: 487 736 target.c:2595 target_read_u16(): address: 0x0000007e, 
value: 0x3352
Debug: 488 736 target.c:2595 target_read_u16(): address: 0x00000082, 
value: 0x334c
Debug: 489 736 target.c:2595 target_read_u16(): address: 0x00000086, 
value: 0x3354
--
Debug: 576 764 target.c:1910 print_wa_layout():    0x20010000-0x2001ffff 
(65536 bytes)
Info : 577 764 rp2xxx.c:1257 rp2xxx_flash_probe(): RP2040 rev 2, QSPI 
Flash win w25q16jv id = 0x1540ef size = 2048 KiB in 512 sectors
Error: 578 764 command.c:1240 parse_ullong(): Invalid command argument
Debug: 579 764 command.c:457 exec_command(): Command 'rp2xxx 
rom_api_call' failed with error code -603
Error: 580 764 target.c:4702 target_handle_event(): [rp2040.core0] 
Execution of event reset-init failed:
embedded:startup.tcl:1427: Error: args[i] option value ('CX') is not valid
in procedure 'program'
in procedure 'ocd_process_reset'
in procedure 'ocd_process_reset_inner' called at file 
"embedded:startup.tcl", line 1427
Debug: 581 764 command.c:86 script_debug(): command - transport select
Debug: 582 764 command.c:86 script_debug(): command - rp2040.core1 
was_examined

Tom Dean

Re: [OpenOCD-user] Openocd does not appear to reset the target properly.

[Antonio B. <bor...@gm...>]

On Sat, Jun 21, 2025 at 3:28 AM Thomas D. Dean <to...@wa...> wrote:
>
> I have a web server on a pico_w. It works correctly. One problem.
>
> When I make a change and reprogram with openocd, the pico_w does not
> restart properly. A browser on a local PC will not load the web page
> until I power-cycle the pico_w.
>
> Code: Select all
>
>  > sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c
> "adapter speed 5000" -c "program mycode.elf verify reset exit"
> Open On-Chip Debugger 0.12.0+dev-g8b8c9731a (2025-06-19-01:48)

Hi Thomas,
the git SHA1 reported in the line above '8b8c9731a' does not match
anything in OpenOCD upstream.
Are you using a fork taken somewhere else?

> Licensed under GNU GPL v2
> ...
> embedded:startup.tcl:1427: Error: args[i] option value ('CX') is not valid
> in procedure 'program'
> in procedure 'ocd_process_reset'
> in procedure 'ocd_process_reset_inner' called at file
> "embedded:startup.tcl", line 1427

This reports that a command was expecting a numeric or boolean
argument and instead got the string 'CX' !!!
I cannot detect which command. In OpenOCD upstream source code
cat src/helper/startup.tcl src/jtag/startup.tcl src/target/startup.tcl
src/server/startup.tcl src/flash/startup.tcl | less -N
reports that line 1427 is the caller to 'ocd_process_reset_inner' ,
that's not useful info.

Try to add '-d' to the command line to get more logs, and try to
detect why a command gets 'CX' as an argument.

Antonio

> ** Programming Started **
> Info : Padding image section 1 at 0x1004c324 with 220 bytes (bank write
> end alignment)
> Warn : Adding extra erase range, 0x1004c400 .. 0x1004cfff
> Info :   Erase chunk: 0x00000000 -> 0x0001ffff
> Info :   Erase chunk: 0x00020000 -> 0x0003ffff
> Info :   Erase chunk: 0x00040000 -> 0x0004cfff
> ** Programming Finished **
> ** Verify Started **
> ** Verified OK **
> ** Resetting Target **
> shutdown command invoked
>
> But, the target is not properly reset. A local browser will not load the
> page.
> If I cycle power, the local browser will always load the page.
>
> As suggested in the RPi forums, I tried:
>
>  > sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg      -c
> "adapter speed 5000" -c "program kiki_picow.elf verify ; reset halt;
> rp2040.core1 arp_reset assert 0 ; rp2040.core0 arp_reset assert 0 ; exit"
>
> No improvement.
>
> What am I doing wrong? Any ideas?
>
> Tom Dean

[OpenOCD-user] Openocd does not appear to reset the target properly.

[Thomas D. D. <to...@wa...>]

I have a web server on a pico_w. It works correctly. One problem.

When I make a change and reprogram with openocd, the pico_w does not 
restart properly. A browser on a local PC will not load the web page 
until I power-cycle the pico_w.

Code: Select all

 > sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c 
"adapter speed 5000" -c "program mycode.elf verify reset exit"
Open On-Chip Debugger 0.12.0+dev-g8b8c9731a (2025-06-19-01:48)
Licensed under GNU GPL v2
...
embedded:startup.tcl:1427: Error: args[i] option value ('CX') is not valid
in procedure 'program'
in procedure 'ocd_process_reset'
in procedure 'ocd_process_reset_inner' called at file 
"embedded:startup.tcl", line 1427
** Programming Started **
Info : Padding image section 1 at 0x1004c324 with 220 bytes (bank write 
end alignment)
Warn : Adding extra erase range, 0x1004c400 .. 0x1004cfff
Info :   Erase chunk: 0x00000000 -> 0x0001ffff
Info :   Erase chunk: 0x00020000 -> 0x0003ffff
Info :   Erase chunk: 0x00040000 -> 0x0004cfff
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked

But, the target is not properly reset. A local browser will not load the 
page.
If I cycle power, the local browser will always load the page.

As suggested in the RPi forums, I tried:

 > sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg      -c 
"adapter speed 5000" -c "program kiki_picow.elf verify ; reset halt; 
rp2040.core1 arp_reset assert 0 ; rp2040.core0 arp_reset assert 0 ; exit"

No improvement.

What am I doing wrong? Any ideas?

Tom Dean

[OpenOCD-user] RTT on the AM243x-Launchpad

[Jonathan P. <jon...@fe...>]

I’m using SEGGER’s RTT Protocol on the AM243x-Launchpad, and I’m seeing some issues. I can connect and load code just fine - I’m using these commands to start an RTT server, and that all works:

monitor rtt setup 0x70000000 0x10000
monitor rtt start
monitor rtt server start 19021 0

I can then connect to port 19021 and read out the RTT data – but only when I’m single stepping the code. If I let the code run, I see

Error: [am243.cpu.main0_r5.0] not halted
Error: [am243.cpu.main0_r5.0] not halted
Error: [am243.cpu.main0_r5.0] not halted
Error: rtt: Failed to read up-channel 0 description

The RTT socket then stops outputting anything. Running “rtt stop” and then “rtt start” fixes it, but again, only whilst single stepping. As soon as I let the CPU run then it breaks.

My OpenOCD was compiled from source, and is running on Apple Silicon macOS. It reports: Open On-Chip Debugger 0.12.0+dev-01931-g6834f022b (2025-04-07-10:40)

I’m running OpenOCD with: ./src/openocd -s tcl -f board/ti_am243_launchpad.cfg

The JTAG probe is naturally the on-board XDS110 – there doesn’t appear to be any way to use a different probe with this board.

Any insight gratefully received.

Jonathan

--
Jonathan Pallant
Senior Embedded Systems Engineer
t. +44 20 4571 3689
m. +49 151 2845 8745
Ferrous Systems UK Limited
201a Victoria St.
LONDON
SW1E 5NE

Re: [OpenOCD-user] OpenOCD and Stellaris LM4F120

[Paul F. <fer...@gm...>]

On Fri, Mar 28, 2025 at 01:07:21PM +0100, Zbigniew wrote:
> > Or just do "openocd -f board/ek-lm4f120xl.cfg" if that's your board.
>
> Thank you so much for your prompt reply -- both ways work.

Sometimes it's even faster to ask on IRC, feel free to next time.

> Just one thing that
> makes me unsure, should I worry: it answers the following:
...
> Error: SRST error

static int icdi_usb_assert_srst(void *handle, int srst)
{
        /* TODO not supported yet */
	return ERROR_COMMAND_NOTFOUND;
}

So it's to be expected, it's not implemented, and I doubt anyone has
any plans to implement it because ICDI is irrelevant these days.		

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [OpenOCD-user] OpenOCD and Stellaris LM4F120

[Zbigniew <zbi...@gm...>]

> Or just do "openocd -f board/ek-lm4f120xl.cfg" if that's your board.

Thank you so much for your prompt reply -- both ways work. Just one thing
that makes me unsure, should I worry: it answers the following:

Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : RCLK (adaptive clock speed)
Info : ICDI Firmware version: 9270
Error: SRST error
Info : [lm4f120h5qr.cpu] Cortex-M4 r0p1 processor detected
Info : [lm4f120h5qr.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for lm4f120h5qr.cpu on 3333
Info : Listening on port 3333 for gdb connections

Should I be worried with that "Error: SRST error"?

Re: [OpenOCD-user] OpenOCD and Stellaris LM4F120

[Paul F. <fer...@gm...>]

On Fri, Mar 28, 2025 at 12:10:26PM +0100, Zbigniew wrote:
> I'm trying to use OpenOCD 0.12.0 with TI Stellaris LM4F120 board (Linux
> Slackware64 15.0) the following way:

Or just do "openocd -f board/ek-lm4f120xl.cfg" if that's your board.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [OpenOCD-user] OpenOCD and Stellaris LM4F120

[Paul F. <fer...@gm...>]

Hello,

On Fri, Mar 28, 2025 at 12:10:26PM +0100, Zbigniew wrote:
> openocd -f /usr/share/openocd/scripts/interface/ti-icdi.cfg -f
> /usr/share/openocd/scripts/target/stellaris.cfg

You can skip the first part of the path, so the command line becomes

opencd -f interface/ti-icdi.cfg -c "transport select hla_jtag" \
    -c "adapter speed 1000" -f target/stellaris.cfg
    
HTH
-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

[OpenOCD-user] OpenOCD and Stellaris LM4F120

[Zbigniew <zbi...@gm...>]

Hello,
I'm trying to use OpenOCD 0.12.0 with TI Stellaris LM4F120 board (Linux
Slackware64 15.0) the following way:

openocd -f /usr/share/openocd/scripts/interface/ti-icdi.cfg -f
/usr/share/openocd/scripts/target/stellaris.cfg

It answers:

Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To
override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : RCLK (adaptive clock speed)
Error: mode (transport) not supported by device

The board (its "debug" connector) is connected to /dev/ttyACM0 and I have
rw rights (I also verified with minicom I can "talk" to "default"
LED-controlling app using that tty).

What do I need to do to make OpenOCD cooperate? I found two or three web
pages containing a few tips, but all they are more than 10 years old and
contain outdated info, partially not applicable to newer versions of
mentioned software, so the tips I was trying to use gave no effect.

How the present version of OpenOCD can be persuaded to talk to Stellaris
board?

[OpenOCD-user] Debug authentication using Arm ADAC certificates

[Pradeepa S. <pra...@gm...>]

Hello Team,

I hope this is the correct mailing list. I wasn't sure whether this should
be directed to OpenOCD or GDB.

We are working on a project that needs debug authentication for STM32H562
MCU. It uses ARM ADAC. (
https://developer.arm.com/documentation/den0101/latest/)

I'm just wondering whether this capability is available in OpenOCD?

Thanks!
Best Regards,
Pradeepa Senanayake.

[OpenOCD-user] xPack OpenOCD v0.12.0-6 released

[Liviu I. <il...@li...>]

https://xpack-dev-tools.github.io/openocd-xpack/blog/2025/02/07/openocd-v0-12-0-6-released/

This maintenance release fixes the trailing spaces after `openocd/angie`.

[OpenOCD-user] xPack OpenOCD v0.12.0-5 released

[Liviu I. <il...@li...>]

https://xpack-dev-tools.github.io/openocd-xpack/blog/2025/02/05/openocd-v0-12-0-5-released/