openocd-user

[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] 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...

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...>]

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...