GDB stub for STM32F0x (Cortex M0)

We don't have one to exactly match your requirement. But would you please check CMSIS DAP and PYOCD at

http://mbed.org/handbook/CMSIS-DAP
http://embeddedworldweb.blogspot.co.uk/2013/12/debugging-pyocd-and-gdb-tutorial.html
https://mbed.org/blog/entry/Debugging-from-GDB-using-pyOCD/
https://launchpad.net/gcc-arm-embedded-misc/pyocd-binary

If this is something you want, you can then rise requirement to their community.

Hello Terry,
I will take a look to CMSIS DAP and pyOCD and I will post my request to their comunity.
I have a doubt: they support debugging using on-chip ARM debug capability. I suppose this peripheral is available only when JTAG, SWD and (if I right understand) USB (CMSIS DAP).
My scenario is a little bit different:
- I cannot run a gdb server on my target and so I need a stub.
- I can only use a UART to connect to gdb. I'm quite sure the built-in ARM debug peripheral is active only when a JTAG/SWD
   emulator is connected. Because of this, concerning breakpoints, I need a stub able to manage "software breakpoints"
   instead of "hardware breakpoints.
Is it something that could be done by this community? Or, can you please suggest me how to proceed to do it on my own?
Thank you very much in advance for your reply.

Thanks Terry Guo, that solved my question.

If you mean serial port=RS232(not a USB?), then I think there isn't any stand alone gdb stub for such an application. But the rt-thread community is now developing an on-system gdb debug stub, which can debug the app running on the rtos through serial port, please have a look: https://github.com/RT-Thread/rt-thread.

Also it's not so hard to develop a gdb stub base on serial port(the speed will just be very slow), you can raise your demand at: https://github.com/mbedmicro/pyOCD. If there's really a lot users want this feature, we will consider it.

Sorry, I made a mistake here. You say serial port, if it means something like RS232 not usb, then there need to be hardware debugger supporting such an interface, and as far as my knowledge, there isn't such kind of debugger for m0. If you mean usb interface, then your demand is quite common among all the existing gdb stub.

Hi Tony,
thank you for your suggestions; yeas, I was talking about UART/RS232, not USB.
Let me clarify a little bit the contest where I plan to use this stub: during firmware development, I use a JTAG/SWD emulator to debug my target application.
When the product is delivered and it's on the "real field", JTAG interface is no more easily available: my product has a bluetooth SPP connection and so it has a "wireless UART".
Using a smartphone near to the target device that acts as a gateway between target device and a remote PC, I could remotely debug my application.
Because of this stub is not available, I'm commiting this design activity: if the feasibility will come right, the stub will be released open source.
BR

Hi Giordano,

The gdb stub you mentioned should be really a cool staff, and the rs232 interface also provide a more flexible interface than USB as it can be easily wrapped by other communication interface. I'm not sure what kind of debug standard you're using now? I recommend you take a look at the pyocd: https://github.com/mbedmicro/pyOCD. You can just adding one more interface like uart to it. You can write email to me directly to discuss how to implement this or anything related, because it not actually a toolchain question: )

BR

Hi Giordano,

Some months ago when I worked on a Blooth Low Energy project, I have same idea. So far the preferred way to talk/monitor/debug your target MCU is via cmsis dap and swd. I am not a hardware expert, may I ask whether your onboard 'wireless uart' can support swd? Normally I will add another mcu to my board to handle swd job and communication to my gdb stub running either on phone or a pc.

Hi Tony,
today I'm using CoIDE (http://www.coocox.org/): its debugger is based on GDB. At the moment they don't support GDB remote debugging and so I can start using a simple GDB command line session. When the target is on my desk, I use ST-LINK/V2 on SWD.
I will take for sure a look to pyOCD: I will contact you via email to better understand how this project could fit my needs.
Thank you.
BR.

Hi Terry,
I use a bluetooth module connected to a Cortex M0 microcontroller UART: when a bluetooth connection is established, I can sent data and receive back answers over this UART (this is why I call this "wireless UART").
Unfortunately, from the hardware point of view, I cannot add another MCU to manage SWD: this means I can only manage GDB commands on a stub present on that microcontroller.
BR

Hi Giordano,

As my colleague think your request may be a common case, so still post
it publicly for other people's reference.
Basically, I think the data flow of a debugging environment can be
described as follows:
(data format/physical interface like usart, ubs or ethernet)
       gdb cmd/any interface cmsis dap data
package/any interface core sight data
package/swd or jtag
gdb ================> gdb server ============================>
hardware debugger =========================> m profile mcu
From the above, you can see, there're several data links can be change
from wired(local) to wireless(remote).

 From your statement above, the biggest problem for you project is
that you don't have a swd or jtag physical interface to your m profile
MCU, which may block your request to such a remote debugger. But still
if the bluetooth module is programmable, you can control its IO to
simulate the swd interface.
The pyocd I mentioned is just an open source gdb server, because you
use uart as communication interface, there's no existing gdb server
use uart, so you just need to add it by your self(or you can raise
your request at pyocd github website).

Another solution would be a wrapper of gdb server on your target
platform. There're some rtos on m profile mcu which has a embedded gdb
stub, it can be control via uart and debugging the app running on this
rtos. But it definitely need a lot of software work to transplant your
project to that rtos based, and its still under internal test, but
will be published soon.

The above is the brief introduction about the solution to your demand,
feel free to ask any question if I've not state clearly.

BR

2014-07-28 20:22 GMT+08:00 Giordano De Maria
<email address hidden>:
> Question #251829 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/251829
>
> Giordano De Maria posted a new comment:
> Hi Tony,
> today I'm using CoIDE (http://www.coocox.org/): its debugger is based on GDB. At the moment they don't support GDB remote debugging and so I can start using a simple GDB command line session. When the target is on my desk, I use ST-LINK/V2 on SWD.
> I will take for sure a look to pyOCD: I will contact you via email to better understand how this project could fit my needs.
> Thank you.
> BR.
>
>
> Hi Terry,
> I use a bluetooth module connected to a Cortex M0 microcontroller UART: when a bluetooth connection is established, I can sent data and receive back answers over this UART (this is why I call this "wireless UART").
> Unfortunately, from the hardware point of view, I cannot add another MCU to manage SWD: this means I can only manage GDB commands on a stub present on that microcontroller.
> BR
>
> --
> You received this question notification because you are a direct
> subscriber of the question.

Hi Tony,
thank you very much for your reply: it's very clear.
The bluetooth I'm using can only be managed using AT commands coming from an external microcontroller: it's not possible to add a GDB server functionality.
As stated yesterday, we will try to implement this GDB stub on the microcontroller: if the result will be fine, we will release it open source.
BR

You're welcome, do you prepare to build it with or without an OS?
https://code.csdn.net/RT-Thread/rt-thread this link is a rtos with gdb
stub support on multiple MCU.

2014-07-29 15:22 GMT+08:00 Giordano De Maria
<email address hidden>:
> Question #251829 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/251829
>
> Giordano De Maria posted a new comment:
> Hi Tony,
> thank you very much for your reply: it's very clear.
> The bluetooth I'm using can only be managed using AT commands coming from an external microcontroller: it's not possible to add a GDB server functionality.
> As stated yesterday, we will try to implement this GDB stub on the microcontroller: if the result will be fine, we will release it open source.
> BR
>
> --
> You received this question notification because you are a direct
> subscriber of the question.

Hi Tony,
we're starting to take a look to the gdb stub examples present on <GDB path>\gdb\stubs: the goal is to design something similar.
I will take a look to RT-Thread.
Many thanks for your support.
BR

You're welcome, I will let you know when the gdb stub in rt-thread is
formally released. As it is not so easy to transplant the gdb stub
under Linux to a bare metal environment or rtos without posix
interface.

2014-07-29 16:32 GMT+08:00 Giordano De Maria
<email address hidden>:
> Question #251829 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/251829
>
> Giordano De Maria posted a new comment:
> Hi Tony,
> we're starting to take a look to the gdb stub examples present on <GDB path>\gdb\stubs: the goal is to design something similar.
> I will take a look to RT-Thread.
> Many thanks for your support.
> BR
>
> --
> You received this question notification because you are a direct
> subscriber of the question.