Could you suggest development/debugging tools

[Dejan Deletic]

Hi there,

Congratulations on a great product!

We are looking to integrate mDot into a commercial product. For this we need to be able to develop and more importantly debug software running on these mDots.

Online compiler is great for getting started, but only provides printf() for debugging which is totally inadequate. for serious development we need to be able to set breakpoints, pause execution, inspect variables, etc… In other words, JTAG.

What would be your suggested development/debugging cycle and required tools to make all this possible?

We do have a development board; we do have an ST-LINK, and are capable of making cabling if needed. One option would be connecting an ST-LINK directly to the target (bypassing the development board), but then, what IDE do we need? How can we preserve the bootloader?

[Andrew Lindsay]

If you need to use an off-line toolchain then have a look at https://developer.mbed.org/cookbook/Homepage#software-development for available options.

thanks

Andrew

[Mike Fiore]

Hi Dejan,

The mbed debug page (https://developer.mbed.org/handbook/Debugging) suggests using Keil MDK for debugging. However, we don’t currently support exporting to that IDE for the mDot.

I suggest using pyOCD. Here’s a page describing how it works and how you can use it: https://developer.mbed.org/blog/entry/Debugging-from-GDB-using-pyOCD/

Cheers,
Mike

• This reply was modified 8 years, 3 months ago by Mike Fiore.

[Dejan Deletic]

Thanks,

I’ll investigate both options.

Dejan

[Dejan Deletic]

I just wanted to report back that I have managed to get EmBitz (formerly known as EmBlocks) to build, and debug via ST-Link.

Building part is straight forward – export your project from the online compiler for EmBlocks, open in EmBitz and build. This will create an ELF file which is fine for debugging, but not for copy onto MULTITECH virtual disk (if using EVB). To create a binary, similar to one provided by the online compiler, use ‘arm-none-eabi-objcopy -O binary <target.elf> <target.bin>’ post build step.

Debugging is a bit more involved. First, you need to let go of EVB and connect ST-Link directly to mDot using SWD pins.
– In EmBitz, go to ‘Debug :: Plugins :: SVD Repository’ and get device information file for ‘STMicro :: ST32F411xx’ device so that the system knows how to interact with the microcontroller.
– Then configure ‘Debug :: Interfaces’:
* use this SVD file you just imported from the repository
* On GDB Server tab, select ST-Link from STMicroelectronics for the interface.

My system would not load the program before starting a debug session, but other users report it EmBitz does work with their ST32F411RE devices. I had to go to disable automatic program loading (in ‘Debug :: Interfaces :: GDB Server :: Settings’, de-select ‘Load Program’ check-box), and before every debug session, load the program manually using either STLink utility (from STM; a huge beast) or qstlink2 tool (open source, 3MB single file).

Now I have full debugging capability. I hope this helps someone…

[Mike Fiore]

Dejan,

Glad you had success!

Since my last post on this thread, I have verified that OpenOCD is a viable option for debugging as well. Here are the steps…

mbed devices can be debugged using OpenOCD

A pretty good tutorial can be found [http://mcuoneclipse.com/2015/03/22/openocdcmsis-dap-debugging-with-eclipse-and-without-an-ide/ here]

* download OpenOCD from https://sourceforge.net/projects/openocd/files/openocd/0.9.0/
* extract tarball
    tar -xzvf openocd-0.9.0.tar.gz
* make and install OpenOCD
    configure; make; sudo make install
* add self to plugdev group (linux)
    sudo usermod -a -G plugdev <username>
* copy udev rules for debug interfaces (linux)
    cp /usr/local/share/openocd/contrib/99-openocd.rules to /etc/udev/rules.d/
* connect UDK2/MDK/etc
* start openocd
    openocd -f /usr/local/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/local/share/openocd/scripts/board/st_nucleo_f4.cfg
* start gdb in another terminal
    arm-none-eabi-gdb
* connect your gdb instance to the gdbserver OpenOCD is running
    (gdb) target remote localhost:3333
* load the symbol file into gdb - this is the .elf file in the same directory your binary was in
    (gdb) symbol-file <path to .elf>
* halt and reset the target
    (gdb) monitor reset init
* now you're ready to debug!

Make sure your application (and the mbed libraries) were built with debug symbols! The simplest way is to use the "-o debug-info" with the build and make scripts.

Cheers,

Mike

[Author]

Posts