MicroPython Forum (Archive)

Hi,

I run MicroPython on my STM32F7Disco board. I manage to build/run it fairly easy.

Now, I would like to run the code in a debugging environment, modify the code, debug, single stepping,...
I'm used to do this in Windows, using J-Link and IAR and tools from the projet GNU ARM Eclipse.

I would like to the the same with the STM32F7Disc board, which doesn't have the JTAG header, but it is equiped with the STLINKv2.

So, I installed the GNU ARM Eclipse tools on my Linux machine, and followed information from http://gnuarmeclipse.github.io/debug/install/ in order to use STLink with OpenOCD (http://gnuarmeclipse.github.io/debug/install/) and the stlink GDB server from texane (https://github.com/texane/stlink).

But they do not work really well...
Using OpenOCD via Eclispse, I sometimes manage to connect to the board (it seems that I need to push the button reset when it is connecting?), then it seems to upload the binary file, and I can debug the application, but it is very slow, I see a lot of timeout errors and it often loose the connection with the debugger.

The STlink tool from Texane recognize the board, upload the binary, but the debugger fails on an error (Failed to execute MI command:
monitor reg).

My question is : does anyone have a working debug environment for micropython? What do you use? on which board?
Is it even possible to debug/single step into the code (mostly into the low level part of the code)?

Thanks!

I haven't hooked up a debugger for MicroPython running on any of the boards yet. I do have gdb running fine on a CC3200 Launchpad board (unfortunately not for MicroPython), but personally I try to avoid environments like Eclipse. When they work they seem to work well, but when things stop working they seem to fail miserably.

I prefer to run gdb from the command line, so I don't have something like Eclipse getting in the way.

For single stepping through the micropython C code, I find that doing on the desktop using the unix version tends to work best.

If you really want to debug MicroPython, I recommend that you get the debugger working well with plain old C first. Once you have that working, then debugging MicroPython should just work.

The F7 is fairly new, so I'm not surprised that there are rough edges. There are alot of pieces of code that need to work together when debugging, so specific versions of each piece are often required, especially when working with newer chips.

Debugging on the x86 works pretty flawlessly, which is why I do what little debugging I've needed to do that way.

Thanks for sharing your experiences

It's a good thing that MicroPython runs on x86! This way, we can debug it without the constraints of an embedded platform.
But... it's the low-level part of the code that I would like to debug (processor initialisation, peripherals configuration,...), and see if I can do anything about this SD card issue.

Perhaps is it time to learn GDB deeper and use it from the command line !

My experience is that there are certain types of problems which are extremely difficult to debug using a debugger.

Race conditions, and cache coherency are 2 of those problems. I generally fall back to old fashioned printf debugging with custom code to try and detect these types of problems. It can get especially nasty when the problems take several hours to reproduce (a particularly nasty one I dealt with (not in MicroPython) took six hours of intensive processing before it would manifest) or when the act of introducing additional code changes the problem.

Where debuggers really shine is when you're trying to understand the logic of the code and see what code paths are taken, or examine the conents of variables or memory.

gdb also includes a character based GUI called TUI. I find that using the "layout split" or "layout reg" commands quite useful. There is also a nice graphical front-end called ddd that you can use with gdb (either on the host or with arm-none-eabi-gdb).

Yeah, of course, the debugger is not the answer to all the possible types of issues.
I'm trying to attach the debugger in order to follow the flow of the code and understand how it works.

BTW, I found a solution for my issue with the debugger... My Linux box is in fact a VirtualBox virtual machine. Once I enabled the support for USB3 (as my laptop has only USB3 ports), things went smoother, it is now stable and usable.