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