Visual debugging tool for microcontrollers

[klonyyy]

Hello everyone,

for the past 3 years I've been working on a visual debugging tool and I thought I'd ask here for some feedback or suggestions. Generally if you've worked with STMStudio / CubeMonito or Freemaster before, this is a quite similar tool - the main idea is to read variables values in real time and display them on a plot at high rate. In my opinion such tool is indispensable when you're working with control systems or power electronics, where you cannot simply place a breakpoint.

Before CubeMonitor was introduced I really liked using STMStudio, but the problem was it got deprecated, had some long-unresolved bugs and after some time became unusable. Cube Monitor on the other hand is just too much overhead, poor plot manipulation and not really a debug tool, rather a dashboard creator. But the problem with all these is that they are vendor-dependent. In my past I've worked with ST, NXP, TI microcontrollers, and I wanted something that will work out of the box for these micros.

I started coding my own tool, and slowly got to support STLink, JLink, serial and probes supporting gdbserver connection. Currently depending on the selected debug probe you can reach up to tens of kilohertz of update rates, use the recorder module for even higher frequency signals (motor control applications, active PFCs, power converters), or visualize the SWO output if you're working with ARM MCUs.

The tool is quite mature now and I'm looking for some ideas and feedback on what direction should I pursue to make it available for even more developers. Have you ever used such tool before? Do you find it useful? What features are the most important to you and what type of projects you've been working on recently? Any feedback is welcome!

The tool is called MCUViewer, and you can find some more info on the website: https://mcuviewer.com and the documentation: https://docs.mcuviewer.com

[Harjit]

I was very excited about this when it was an open source project on GitHub. I get you have to make money but the limitations for the free version make it not as useful as alternatives such as Segger's SystemViewer, or FreeMaster for noon commercial users.

https://mcuoneclipse.com/2024/08/25/how-to-use-systemview-data-plot-feature-for-real-time-data-visualization/

https://mcuoneclipse.com/2013/08/24/tutorial-freemaster-visualization-and-run-time-debugging/

[PlainName]

Have you ever used such tool before? Do you find it useful? What features are the most important to you and what type of projects you've been working on recently?

Yes, I used the EE101 which is sadly deprecated:

https://www.eevblog.com/forum/testgear/ee101-firmware-debugger-replaces-usbee-logic-analyzer-review/



I liked the streamed debug text, which was visually timestamped (that is, it appeared in the graph trace at the point where it was generated) and sorrted into channels (a bit like syslog). Super easy to zoom into the exact moment of interest in a huge anount of info.

The graphing of variables was cool, although I didn't use it that much. But when I did, correlating it to the debug messages was great.

Another good thing about it was it wasn't tied into a particular architecture. Use it on anything at all that can twiddle a pin, basically. If you had a serial port then a single pin was fine, otherwise I2C, SPI or a custom EE101 2-wire protocol could be used equally effectively.

[hans]

Apart from continuous plots, I'd really also like to see other plotting options.

Like burst time/index plots on certain triggers. Or X-Y scatters of a buffer (either bufferX bufferY, or buffer with XYXYXYXY data)

This would be quite useful for low to moderate speed software-defined packet radios.

Still have to try this program though,

[NorthGuy]

Another good thing about it was it wasn't tied into a particular architecture. Use it on anything at all that can twiddle a pin, basically. If you had a serial port then a single pin was fine, otherwise I2C, SPI or a custom EE101 2-wire protocol could be used equally effectively.

As I understamd, the OP's is a debbuger, and therefore doesn't require any signals at all except the SWD connection. Just select a variable and plot it. Similar to Segger's J-Scope -

https://www.segger.com/products/debug-probes/j-link/tools/j-scope/

[PlainName]

Not every MCU has a SWD connection

Most have at least one idle pin. But it's horses for courses - the EE101 required a bit of code called from the debug print function, so is intrusive in that sense (albeit not very).

[klonyyy]

Thanks for the answers everyone,

@Harjit yes, there are alternatives out there - I wanted to create a tool that let's you start with no firmware modification, only debug probe + *.elf file - and only then, when you see this is not enough use the recorder module, or connect the SWO. I think SystemView is a much more advanced tool with many features, making it a little intimidating for new users. To be honest I have not fully used it - only for some simple demos. I've used Freemaster though - it is indeed a well engineered tool, apart from some annoying little things, like error codes instead of human-readable messages, manual trigger manipulation, and much more setup, but this is probably because it's a more mature tool. I'm sorry that you feel limited by the free version. If you're working on some fun projects and you're interested feel free to drop me a message - I'm sure we can work this out

@PlainName oh this is quite new to me, haven't heard of EE101 before. As I can see it is a software/hardware project with a custom dongle. The problematic thing is that you have to have two probes connected to your target at the same time - since you're debugging, I assume you're constantly re-flashing the target so a regular programmer/debug probe is also required. But I agree, with some MCUs there's no SWD to make it easier.

@hans Oh this is a little specific use-case - currently only X-Y plots are supported, so you'd have to stream the data in a loop on the target, but it might come in the future - most probably as a interpreter plugin for arrays, as there are many different ideas for visualizing arrays

[hans]

An interpreter in something like Python would be incredibly handy.

For example, for digital packet radios, it would be cool if I can plot an I-Q plane of symbols, see how the constellation rotates and removes differential modulations, etc.
If its an interpreter it could even spit out auxiliary values like Error Vector Magnitude, or track bit error rates, etc.
In case of triggering it perhaps needs some handshaking with the target MCU to let them know when the trigger is armed again, so it can move data into those debug buffers for visualization.

Basically if this is a tool that allows you to look "inside" the MCU, a solid framework for listing and plotting variables, but also adding small (basic) custom metrics that are computed offline.. Perhaps a way to shortcut write variable data, so you can have a few buttons to trigger some action.

I think the scope (pun intended) for these debug applications can be quite big.

[PlainName]

see it is a software/hardware project with a custom dongle

Was. But the dongle was actually a Cypress CY8CKIT-059 dev board so you could flash that with the EE101 hex code. Which is probably why they went out of business...

But my point about bringing that up was because you asked what we liked on the stuff we'd used, and the debug output I found really good. Where variables are concerned, that you'd want to see graphed, they're probably inputs or outputs and I'd use a scope for that normally. Of course, not having to have another big test tool on the desk, and doing and seeing everything from the one app and connection, should score highly over old school!

[klonyyy]

@hans so generally speaking it would be a XY-plot data visualizer, with different ways of interpretation of the source data? The vector plot is something I'm also considering, as it can be useful to visualize motor control algorithm properties (d/q frame).

@PlainName sure, thanks for the reference - I was thinking about supporting text output as well and this could be some inspiration - generally string support is yet to be determined.

[Dave]

I've tried to use Var Viewer to plot some control system variables in real time, but the processor seems to be halted while the viewer is connected (Cortex M4, register DHCSR = 0x00030003).
My setup:
J-Link BASE Compact (FW v12.00, SW v9.46) connected through USB, hooked up to S32K148 MCU. Superloop architecture, two interrupts (one hardware, one SWI).

Is it even possible to do this without using the recorder? I was hoping for a way to analyze my control loops without any added software overhead.

[klonyyy]

@Dave, if you're using JLink, most probably you have a too high SWD speed set up - when JLink detects its too high it tries to set lower and lower speeds and in this routine it seems to halt the target (not really sure why). Additionally you can try using the generic Cortex-M4 device instead of selecting the concrete part number - I had a problem once where MCU-specific JLink initialization was also causing a target halt when connecting. Generally it should be possible to view data without any halts on Cortex-M4. Let me know if that helped

[Psi]

I get you have to make money but the limitations for the free version make it not as useful as alternatives such as Segger's SystemViewer, or FreeMaster for noon commercial users.

Yeah, I think it needs a mid-tier plan in between "100% Free" and a "Ongoing subscription".
Something for 1-5 person companies with <$500k revenue/year. 
A one-off price, commercial ok, with maybe unlimited variables, 20 recorder, 6 trace viewer.

Subscription-only pretty much rules out all ultra small 1 person companies.

[klonyyy]

Yeah, this is something I have to consider - I know the subscription based approach is not ideal. Up until recently I only had the offline license option - meaning there was no way of controlling the amount of users, this is why I did not consider a one-off license. With the seat based it is possible and I will definitely think this through - still finding out the best options, so thanks for the input!

[Psi]

Yeah, this is something I have to consider - I know the subscription based approach is not ideal. Up until recently I only had the offline license option - meaning there was no way of controlling the amount of users, this is why I did not consider a one-off license. With the seat based it is possible and I will definitely think this through - still finding out the best options, so thanks for the input!

Just thinking outside the box, and this maybe a terrible idea to implement, but what about prepaying for x hours of time the app is used. Kind of like how you can prepay for AI tokens.

One annoying thing with subscriptions is that you're paying even if you're not using it. That is often fine for a medium or big company who has engineers coding all day every day, but for any 1-2 person company those people are doing so many other jobs that their coding time is much much less. That makes a yearly subscription a much worse deal for them in terms of the actual use they can get out of it compared to a bigger business.

That 99 euro/year subscription fee would suddenly become a much better deal if it was 99 euro for 2000 hours (~8h*5d*52w) of continuous use.

Not suggesting you actually do that, there might be issues implementing it. Just thinking outside the box.

My scope still has lots of time available on all of the serial decode trial periods because I don't use them much.
I'm really happy they implemented it as a time-in-use trial and not a general time after first power on trial.
It's not that I'm happy because I get to use them when I need, I could just hack the scope and get them, it just makes me happy that they implementing it in a really nice way for the user.

[Fire Doger]

Can this work in parallel with debug?
For example, I would like to be able to change code, flash and debug from the IDE of my choice (let's say eclipse and stm32), step code, run, and have this in parallel recording and plotting? In simple words attaching to an active debug session.

Or do I have to flash the mcu, each time reimport the fresh elf in mcuviewer, remember to disconnect from my ide, click connect in mcuviewer, etc... ?

[__george__]

Any plans to release an AppImage so that you don't only support Debian based distros?

[klonyyy]

@Psi, this could be one solution, but I feel then someone could feel the pressure of closing the program after use so that it "lasts longer" and in the end it could be annoying. I also don't want to make the licensing too complicated for a new user so this is not an easy task, but thanks for the ideas!

@Fire Doger It cannot work in parallel to step debugging - and I will always say that in my opinion you will never need the two simultaneously. The workflow usually looks like so:
1. You build you project
2. MCUViewer detects *.elf change, automatically updates symbols addresses, highlights "flash" button which you can configure to do whatever you like, I just configure it to run the debug probe download firmware CLI. You flash the firmware.
3. You click the run button and debug.
4. Whenever you need to run/attach debugger you simply disconnect/stop (there's an option to keep connection after stop, or drop it) and you're free to use the debug probe in Ozone, Vscode, CubeIDE or any other IDE with step debugging.

@__george__ that's a really good insight - I will dig into that as I'd like to support other distros, especially if it's only a matter of packaging.

[Dave]

@Dave, if you're using JLink, most probably you have a too high SWD speed set up - when JLink detects its too high it tries to set lower and lower speeds and in this routine it seems to halt the target (not really sure why). Additionally you can try using the generic Cortex-M4 device instead of selecting the concrete part number - I had a problem once where MCU-specific JLink initialization was also causing a target halt when connecting. Generally it should be possible to view data without any halts on Cortex-M4. Let me know if that helped

Reducing the SWD speed had no effect, but setting the device to generic Cortex-M4 did get it working. 

Consider adding a crude triggering system to var viewer. It would make things far easier for observing control system responses.
I also found a bug: When importing variables from an ELF file, the program only shows the first elements of arrays. Adding each subsequent element to the viewer has to be done manually.

[klonyyy]

@Dave glad the device change helped Yes, triggers in Variable Viewer are on the way - it should be a really useful feature. Regarding the array issue - this is on purpose, so that listing all elements does not take forever. Simply import the array variable, copy it and the index will auto-increment, you can also modify it by hand. Will add info to the documentation about it - thanks!

[Dave]

Copying the members of an array does auto-increment the index in the name, but not the corresponding addresses. I also checked the data and you're reading the same data on all of the copied variables.

[Harjit]

@klonyyy - very kind of you: I'll reach out when I'm ready - need to finish the PCB.

One scenario that's *not* addressed, as far as i can tell, is logging. It would be very useful to either stream the data, or to store it, transport it to the host(1), and view it there. Then, one can spend time looking at it. To make it more useful, it would be very useful to be able to tag events, and make notes, search for them, and then share that as a report to embed in a bug report.

I didn't see the ability to print text. Imagine a textbox where you see lines of text. Add you move through the graphical display, the text that was output at that time is highlighted. The textbox being searchable would be good. Oh, if you want to make this next level, you could replace the text with an index, then, only the index is stored. Then just before the transport, it is expanded. Alternatively, after the info is transported, it can be expanded. Similar to this: https://interrupt.memfault.com/blog/trice. I believe Segger or someone else has a similar solution.

(1) I say transport because i want to use BLE instead of USB, or serial. I'm going to log the data to a serial flash, and then transport it over BLE to the host.

FWIW, my application is several PMSM running at the same time on a Cortex M4.

[klonyyy]

@Dave, yes, this is because auto-refresh is not called on copy - will be fixed in 1.2.9, find it annoying too you can click refresh addresses manually for now.

@Harjit so you're proposing storing logs on the target and sending them back only when finished instead of continuous streaming? Should be possible, it's just a matter of how well I could make it fit to the current application. I rather thought about events being placed as text on the plots since MCUViewer is primarily a plotting tool. For sure a way to save session and then restore it instead of just taking screenshots is on my list.

I'm also thinking of point-to-point streaming of SWD data for ARM (wireless debug probe) but optimized for plotting with flashing function - should be really useful for robotics demos/wireless devices.