I have written a debug stub which allows gdb to attach and debug code running on the mbed 1768 device. I am calling this project MRI, Monitor for Remote Inspection.

It already supports the basics:

• 6 hardware breakpoints
• stack back trace
• reading/writing of program variables
• single step
• breaking into running program
• runs over USB based serial port
• works with free Code Sourcery GCC based tool chain
• no size limitations

Some of the additional things that will be added for the alpha version:

• 2 data watchpoints
• stdout/stderr/stdin will be redirected to/from the gdb console
• run over any of the available UARTs on the mbed device (selected at compile time)
• source will be made available on github

I would love to get the community's feedback on this project. Especially in these areas:

• Is the community interested in having an offline debugger solution for the mbed?
• Are there members of this community which are experienced with using command line mode gdb and would be willing to help me out with the alpha testing in a month or so?
• For the beta testing phase, what GUI frontend would the community like to see supported?
• This will probably only work for gcc4mbed built projects where it is easy to control how the debug stub gets linked into the final binaries, what tools are used for compiling/debugging, and the symbols that are generated for the resulting binary. Does this make the mri debug stub useless to the community?
• Anything else?

Thanks for your time. I appreciate it!

-Adam

MRI helped me a lot with debugging tricky issues in smoothie. I usually debug using printfs, but in my case that can interfere with the normal workings of the program and cause the bug not to occur. For things like bugs occurring inside interrupts, or heap corruptions, I was able to locate precisely the problem in the code instantly, where using the traditional printf/turn leds on/off, it would have taken ages ( one bug took hours before occuring, and without MRI I was completely unable to locate it ). I have not gotten yet to play with the breakpoints, and step-by-step execution, but can't wait for the alpha release to play more seriously with it.

Awesome work from Adam, as usual :)

Hi Adam,

That's some excellent progress already!

I certainly do want debug support for mbed (either online or offline, ideally both!) so yours will be the first (or one of the first) to offer something.

Sadly I'm no longer au fait with the CLI mode - I last used it about 10 years ago :-(

Would you be able to provide a debug library-style interface to include in the projects - this would possibly make it easier to include/exclude any debugging?

Cheers

Jez

Hi Adam,

Awesome! We should be able to give you the appropriate hooks in the mbed libraries, so then it should work with the mbed libraries and on any of the supported toolchains including the online compiler; just tell emilio what hooks you need.

Simon

Arthur: Thanks for being my first guinea pig...ahh...I mean tester. Your feedback and questions will be going into the notes that I provide with the alpha version.

Thanks.

So currently mri is implemented as a library that you pull into your program at link time and gets initialized in the gcc4mbed startup code through a call to MriInit(). This can be done later at the beginning of a program's main() function. What kind of interface were you thinking of? As I mentioned, my interface is currently pretty simple: an init function. The only parameter that is currently planned for this single function is an enumeration which indicates the UART to be used for communication back to gdb on the host machine.

Simon,

That would be very cool! I will ping Emilio later this week.

Thanks,

Adam

Hi,

is there any chance of getting some access to this for testing/ helping with bugs purposes?

I am about to start a fairly hefty instrumentation control project which I was going to lay down an LPC chip with support electronics on a custom PCB. But it would save me much design time and hassle to pop an mbed on there. The downside - I really will need some kind of "proper" debug.

I don't want to have to make a PCB/buy an eval board just to get JTAG on the chip and then use an mbed in the final version!

cheers

Dan

Hi Adam,

Is the source still available somewhere? I would like to see how it's implemented.

Oskar

Hello Oskar,

I haven't made MRI publicly available in binary or source form yet. I am still working on the code to get it ready for such a release. I am the only one currently testing the alpha releases. I add a few features and then I switch to work on other mbed based projects so that I can dogfood the latest features rather than just concentrating on the debug monitor itself. This tends to slow things down a bit :(

I have been working on it though and the additional features added since I started this thread include:

• 4 data watchpoints
• stdout/stderr/stdin are redirected to/from the gdb console
• runs over any of the 4 available UARTs on the mbed device (selected at compile time)
• baud rate is determined on the PC when the gdb connection is initially made and the auto baud detect functionality is used on the LPC1768 to configure the mbed UART speed at runtime.
• minimal LocalFileSystem semi-host support. fopen, fwrite, fread, fseek, and fclose calls made to the LocalFileSystem are redirected to use the current directory of gdb on the PC so that all LocalFileSystem functionality isn't lost when disabling the JTAG interface.

I will post a message to this thread once MRI is ready for beta testing within the Code::Blocks IDE.

-Adam

Oskar, the initial alpha versions of the source code are available here: https://github.com/adamgreen/mri

I am currently in the process of integrating this alpha version of the MRI library into my gcc4mbed project to provide an example of how to link it in to a project and configure it. Eclipse IDE integration will probably be next on the list and be the biggest feature for the beta version of MRI.

Thanks,

Adam

Looks like awesome work. Any update on the gcc4mbed integration? This would be quite useful for a project I'm working on..

A new version of GCC4MBED has been pushed up to github at https://github.com/adamgreen/gcc4mbed#quick-start In addition to upgrading the GNU tool chain and mbed SDK libraries to more recent versions, it also includes the initial support for the use of MRI to enable the GNU Debugger, GDB, to debug code on your mbed 1768 device.

This release upgrades the MRI code base to version 0.3 Special thanks go to the Smoothie team for testing out the previous alpha releases, 0.1 and 0.2, which made this release possible.

Please let me know if you have any questions or hit issues.

-Adam

Hi Adam,

Thank you for all your good work. I have spent the best part of last week getting your solution working for me. I tried on Linux but gdb hanged when I tried to connect to the target. I haven't worked out why yet. I moved to windows and things worked well almost instantaneously! Truly great work form your end. I intended to get eclipse/gdb to work with it but again I've had some issues; Mainly getting it to connect to the target. I used a .gdbinit file to abstract all the command line options. Having said that, I have not worked out how to connect to COMX from the eclipse IDE. I am used to connecting to Qemu in a similar ways but this time no luck. I was not sure how to specify the baud option in eclipse either. Finally, I got cgdb to work. I much prefer it to plain gdb. All I did was to install cygwin then the cgdb for windows, update my PATH and away I was. Thanks again for your brilliant work. I am looking forwards to see how far you get with an IDE integration.

Cheers,

David.

Hello David,

That Linux experience really sucks! It doesn't surprise me though. I have had problems with connecting gdb to the mbed virtual serial port on both OS X and Ubuntu but it always works a charm on Windows when I have tested it there (I do most of my work on OS X.) I will PM you to see if we can work out the cause of your Linux issues. I have some ideas as to what might be causing the problems. I am happy to hear that you were able to get it working on Windows though.

Due to general lack of interest in MRI, I hadn't really bothered to pursue the IDE integration. I prefer command line debuggers so I had no interest in getting an IDE to work for my own purposes.

I am not really sure how cgdb works? If it isn't just a front-end for the arm-none-eabi-gdb that my install scripts install, then I don't expect you will get an ideal debugging experience for gcc4mbed built projects. The installed version of gdb is matched with the compiler that creates the binaries and it has some additional fixes that I have made.

Thanks,

Adam

Thanks to help from David Cabanis, I was able to write a cookbook page on how to use Eclipse to not only build projects for mbed using Eclipse but also to use Eclipse's GUI debugger with the mbed device running MRI as well.

You can find the cookbook page here.

Hello Adam, I was wondering if you know of any issues of mri with gdb in windows8, Im trying to debug one app that uses the official rtos from mbed but my gdb doesnt seem to connect with the target. I tested with the TCPSocket_HelloWorld sample without success, the app seems to break after the mriInit but when gdb fires it shows only

warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...

I still have to test your other code samples without the mbed-rtos sources.

As soon as I get it to work with gdb I'll be working on a howto for the visualstudio 2012 integration by means of wingdb, we develop realtime apps for a lot of different platforms and I frankly prefer VS ide for all my gcc stuff. Salu2

Maybe your PC isn't communicating with your mbed over the serial port correctly? I take it that you have reconfigured the TCPSocket_HelloWorld sample to build with the debug monitor enabled by setting GCC4MBED_TYPE=Debug? If you perform a non-debug build, does the TCP_Socket_HelloWorld sample work where you can see the printf() output in your terminal emulator on the same PC. If that does work, can you show me the command line you used to launch GDB for the debug build? You can also try connecting your terminal emulator to the mbed instead of GDB with the debug build and try sending an empty GDB packet to see if it will give you any response.

+$#00

-Adam

After upgrading the firmware of my mbed chip everything worked like a charm. Next steps: - mri extension so after a break you get a list of active threads and ability to switch call stacks acordingly - gdb -baud option for values > 115200 - standalone 'mri.bin' able to accept an image uploaded via "load" command

Excellent work Adam, thanks for your support.

Excellent. Glad that helped!

I look forward to seeing your updates. They sound pretty cool.

Does this work with the Visual Studio Express Edition? If so, are there steps on the Internet on how to set it up with GDB like you have done here? While I don't work in IDEs much these days, Visual Studio is definitely my favourite.

Thanks,

Adam

Hi Adam

Thanks for all your great work. I'm wondering if MRI would work on something like the LPCmini. This is custom LPC1768 design where USB is done with a FT232 type chip - (a USB 'phy' to UART interface). Has anyone had success using MRI on something like LPCmini?

Dave

Hello Dave,

MRI just requires a UART on the LPC17xx to be connected to a PC running GDB. Using something like a FTDI chip to bridge that gap is acceptable. I have personally done that on custom LPC17xx boards myself. You just need to be able to dedicate a serial port to debugging and that doesn't even need to be UART0 since MRI can be configured to use others.

I hope that helps,

Adam

Adam

Yes that helps.

You have been able to flash program AND debug using a generic (no mbed chip) USB to UART interface on your custom LPC17xx boards?

Dave

Yes, I have used a FTDI cable like this one which contains a similar FTDI chip to the one you mentioned earlier.

For programming via the serial port, I have used the open source lpc21isp utility. I then used MRI for debugging. The mbed programming speed is much faster than the lpc21isp method so I prefer to do my development on mbed devices when possible.

You could also look into USB based JTAG dongles which would allow you to program and debug the device. I don't have enough personal experience with JTAG devices though to make a recommendation for you.

I hope that helps,

Adam

Hi Adam,

thanks for sharing your tools with the community!

I am new to the LPC world but I already figured that working in a window free environment does not help much. I managed to get a toolchain working so I can compile and flash the LPC1343. I now arrived at a point where I can not proceed without the means to remotely debug. I want to use the gdb debugger on Linux / serial protocol to a USB connected board.

I understand that the LPC17xx boards are not too different from the LPC1343 boards so I hope I can use your tool. Do you have any thoughts on that plan?

Do I need to add/link something to the binary that is flashed to the LPC board in order that mri works?

Is this the latest version? https://github.com/adamgreen/mri

Cheers, Mark

Hello Mark,

MRI is a library which must be statically linked into the program you want to debug. The GCC4MBED project contains makefiles which show an example of how to link it into your program. The GCC4MBED build process also takes care of calling __mriInit() from the startup code as well.

MRI only supports the LPC1768 at this point in time. I did organize the code so that it should be possible to support other Cortex-M3/M4 parts in the future. The one issue I see with the LPC1343 part is that it is kind of limited on memory. I just took a look at a current GCC4MBED build of a basic sample (no mbed and not standard C library usage) and MRI used an additional 13K of FLASH and 944 bytes of RAM. I consider this usage to be more than acceptable for the LPC1768 with its 512K of FLASH and 32K of main RAM. I think that is kind of high for your LPC1343 part though.

What board are you using for the LPC1343? Can you use a hardware debug solution such as JTAG with it?

Yes, that is the latest version.

I hope that helps!

-Adam