STMViewer - visualize your embedded data in real-time

Hey,

This entry is going to be a software one or rather one about a software tool that I've been developing for a few months now - STMViewer:

Currently, I'm working at MAB Robotics, where I work on various stuff around MD80 brushless motor controllers, mostly software-related. The software stack incorporates a couple of control loops, with many tuning parameters and variables that should be observed in real-time to make sure the drive is operating correctly.

I’ve been using STMStudio for that purpose since it offers a high update rate data visualization without intervening in the software execution. All you need is the programmer that usually is connected to the target anyways during the development stage. STMStudio would be totally enough if it would be still supported, however, ST decided to abandon that project and currently, it is declared NRND. It has some annoying bugs; for example, it doesn’t support C++ mangled names directly using the list variables option (typing the names manually works, but sometimes it stops updating the addresses, no idea why). Moreover, it is only available for Windows. The CubeMonitor which should be the STMStudio’s successor turned out to be a disaster even though it seemed to have an interesting idea behind it, and it looks like its abandoned as well. Having no other options I decided to make my own real-time data visualizer, taking inspiration from the great STMStudio project.

STMViewer is almost a copy of the most important STMStudio functionalities that allow for basic debugging using time graphs, bar graphs, and tables. There are some small differences and changes though.

Similarly to STMStudio, it has two main sections – the workspace section on the left and the plotting area on the right. The workflow works as follows:

    1. First you have to select your project’s elf file in the Options -> Acquisition settings

    2. Then you have to add all variables of interest and click the update variable addresses button to try to find the addresses of these variables in the elf file you’ve provided. If this step didn't work, make sure you've got GDB installed and added to the PATH. 

    3. After that you simply drag and drop the variables onto the plotting area and the data acquisition can be started.

You can add multiple plots and changes their names and types. The table view supports writing new data using the “write value” column. This can be especially useful to issue some commands to the target you’re debugging. Read values can be displayed in hex, bin, or decimal formats.

Some more advanced functionalities are still missing:

    - no math operations and statistics

    - no dump to CSV file

    - no “list variables from elf file” option

    - no X-Y plots available

I’m going to work on these soon, however, since they aren’t essential to basic debugging, I'm releasing the first version of the STMViewer right now

If you've got any questions, or suggestions be sure to let me know.

IRQ logger - a simple tool for diagnosing interrupts

[NOTE: this post is deprecated. Please use STMViewer instead]

Hey there!

Today's post will be about a debug tool I've been thinking about for a while now:

I was recently designing a part of embedded software where I had to check the interrupts execution times and if their priorities are set correctly. In short, it meant I had to take my oscilloscope probes connect them with wires to the MCU's GPIOs and toggle them in each interrupt routine.  

nobody likes that...

Meh. I thought to myself, now's the time to finally do something about it. I wanted something that will show me the interrupts as logic signals in time, such as a signal is high when the interrupt is active and low when it's not. Also, the time resolution should be small enough to measure a few-microsecond interrupts. At first, I wanted to go for realtime logging like trice or directly using Segger's RRT communication, but these were too slow and added too much overhead which could cause differences in operation when logging is present vs when it's not. Moreover, I actually didn't need to send any sophisticated debug messages, just a timestamp, an ID, and a state (0 or 1). I thought I could just make a buffer in the RAM memory, collect all the data for some time (until the buffer is full), and then send it using DMA to the PC where a python script would interpret it as a time plot. I liked the idea at first but found connecting UART or any other additional cables (besides the STlink) quite annoying and not applicable to my current projects. And this is when it struck me - I could just use STlink and it's CLI to send and receive data from the target - no other communication buses are needed. It even has the -dump option to dump the binary data to a file - excellent. 

So I began by creating a struct of two timestamp variables (one is expressed in milliseconds, the other in us) - both are 2 bytes each, a 1 byte ID and 1 byte state variables. Six bytes in total. I thought about integrating the state in the ID's MSB, but for now, I decided to keep it super simple. This is the struct, with a union to be able to easily represent it as a byte array. 

The packed attribute is to avoid padding. After that, I had to set up a timestamp timer and implement a simple function that adds logs to the buffer. The embedded side of the project is really straightforward, as it was intended. 

This is how you add a log to the buffer

Next, I got to the part where I needed to read the buffer from the MCU's memory and present it as waveforms so that the data is actually useful and readable. My initial plan was to check the variable addresses in the *.elf file, insert them into the python script and use ST-Link CLI (pystlink) to read their values. This however seemed really impractical, especially when the addresses changed during the firmware development process. This is why I decided to use pyelftools for elf file parsing and variable address extraction. You just have to know the variable names and not change them during development. The script will automatically find the address of the "enable" variable (which turns logging on), and the buffer with its size. It will trigger the logging process and then download the buffer to a binary file, which can be viewed in case the target is no longer present. 

The rest is just unpacking the binary data to a list using "struct", and taking care of signal states in time so that they are displayed correctly. I also added two cursors (they still need improvements) to be able to quickly check the time period of a particular signal state. A simple example log is presented below: 

Of course, I wanted to check the performance so I conducted some tests with my scope. First I checked how long it takes to toggle a GPIO (directly using BSRR and BRR registers). The MCU's core clock was set to 170 Mhz during the tests and the optimization was turned off  (-O0) for the user files and set to -O3 for the logger source file (with #pragma GCC push_options directive).

GPIO test:

This way all the future measurements should be reduced by the 36 ns period. 

Since adding a log is the thing that happens very often and takes place in interrupts I started by measuring the time it takes to add a single log. There are two options - the delay it introduces when logging is off (only entering the add_log() function and checking the first condition), and the delay it introduces when logging is turned on (when besides calling the function we are actually writing values to the buffer). 

The first option when logging is off, takes about 200ns:

whereas the case when logging is turned on, takes twice as long with about 420 ns:

I think it's pretty decent, even considering the shortest interrupt routines. I also plan to test the add_log() function implementation as a #define, so that there's no overhead due to function call. I've heard it's not really the best practice and today's compilers are pretty aggressive with inlining functions, but we shall see ;) 

The source code can be found on my github account, together with a short step-by-step guide on how to use it. There's also a docs/photo directory with some scope and logger screenshot comparisons, and a STM32f474CCU6 example code. Please bear in mind I'm not really a Python guy so the code may not be the best quality. 

Hope you'll find it useful! 

[OLD PROJECTS] DIY Smartwatches

 Hey!

Recently there was not much going on with Wolfie due to my work and vacation (chip shortage played its role too), so I decided to do a second "old projects" series writeup, this time about smartwatches I used to build. 

The whole thing started when I was attending history classes at my junior high/high school. It was a huge pain for me as I had to memorize a lot of dates and events, which is not what I was (and still am) good at. I thought I could use my engineering skills to build a device that would help me a bit during the tests and at the same time improve my PCB design/ programming skills. 

I decided to build an electronic watch with an LCD display that could not only show the time and date, but also display some small size text. I wanted to use a microSD card for storage, an AVR microcontroller, and an old Nokia display (back then it was hard to find any low-cost displays online). The hardware was pretty basic, but what about the main functionality? Basically, you'd just put some plain text file on the SD card and the watch would display and scroll the text file, when the cheatsheet function was activated. The best thing was that the cheatsheet could not be triggered unintentionally, without a special pen I was using to write tests. The pen would have a small magnet build in, and only it could activate the hidden option. This was a nice safety feature in case the teacher saw the watch displaying a wall of text and wanted to take a closer look (which actually didn't happen even once). Ok, so turning the cheatsheet on was pretty simple, but what about turning it off without much interaction with the device? I decided to implement a mechanism that would enable me to go back to the clock screen, by just using the smartwatch hand/wrist. In the first prototype, there was a flat push button on the strap, normally located under the wrist. The only thing you had to do when the teacher was approaching was to just slightly push the strap against the desk to activate the button. In the next iterations, I just added an accelerometer so that all you had to do was slightly move the hand or put it in a certain predefined position, and the text disappeared. 

I couldn't find any photos of the first prototype based on a Nokia 3310 display as it was a long time ago. I hope I find them eventually, but for now you have to believe me it actually existed :P. Since 3D printers were not as popular at the time, I remember making the case from hand-cut laminate pieces and the whole device looked a bit crappy. Even though, it worked fine and helped me (and some of my friends) to pass some of the most tedious classes. 

The next prototype was no longer only about cheating. I was inspired by my friend's Polar smartwatch that had a built-in GPS receiver and could serve also as a bike computer. I decided to upgrade my watch with a color LCD, a GPS receiver, a vibration motor, and some more features. Here's how it looked like: 

early prototype with the GPS module mounted on the strap (yeah the cables didn't last long)

Still a crappy-looking design, but not long after taking this photo I got a Prusa i2 printer and made it look a bit better: 

I created two designs, one a bit thicker with a GPS receiver and another one without the GPS option which was thinner, as I could fit the battery in a PCB cutout region. 

GPS variant - back side

GPS variant - front side

regular variant

As you can see the PCBs were made at home and looked really bad with all the fixes and Kapton tape (but hey, it worked back then!) 

I remember there was a simple menu with icons - you could even decode some *.bmp images from the CD card and check GPS coordinates, ground speed etc. It turned out the watch is a rather poor bike computer as it kept loosing GPS signal in the woods (yeah the receiver was under the PCB and the LCD...).

Even this watch wasn't enough - I wanted to make a touch-screen version. Unfortunately the only types of touchscreens available back then were the resistive ones that, as we all know, are rather annoying. After some search I've found out that Nokia had a nice touch panel on the C3 model, which did not require as much pressure to activate. I decided to go for it and at the same time I had to get a larger display (yes, also from Nokia phone): 

the actual Nokia touch screen is under the chineese one on the right 

 Nokia screen displaying some rectangles 

and an image (this was super exciting!)

some reverse engineering to discover which data frame I was missing

The PCB was rather crazy and till this day I'm still wondering how I got it to work without any major issues (especially since it has an external SRAM memory, the SD card is connected using SDIO bus and the LCD is controlled by a parallel 8080 bus). It was made at home using photoresist dry film and all the developing and etching processes. The thing that annoyed me the most was hand-soldering all the vias.. 

developed photoresist

etched laminate

ready PCB

other side of the PCB

The PCB contained a lot of modules like a MP3 hardware decoder with headphone amplifier, Bluetooth low energy module, wifi module, external SRAM memory (yeah on this poor 2-layer layout...), RTC, touchscreen controller and a micro SD card. Actually, it was a huge overkill especially when it comes to energy saving. 

and old graph of all the peripherals

Going for a more powerful STM32 microcontroller enabled me to make some more advanced stuff such as decoding *.JPEG photos or even playing a low frame-rate motion JPEG video (link). The cheatsheet option was still available, but this time not only using text but also photos. 

the watch with a 3D printed case 

"dark mode"

MP3 player 

The nice icons, lists and other wigets com from the STemWin library, which made he whole process of designing the menu and window much easier. 

diy calculator demo 

I remember wearing this watch everyday (and all the previous ones) and getting a lot of questions as it was quite enormous for a wristwatch. Even though, it was a nice conversation starter, especially during any "robotic" events and contests. One thing I had to remember was to take it off before taking a shower :P 

I hope you liked this piece of my projects history. I had so much fun designing those I thought it was definitely worth a blog post. Sorry for the bad quality photos, but these are the only ones I had. It seems I wasn't taking as many photos of my projects back then. In the end I must warn you - (if you havent figured it out yet) - the PCB and software design of each of these smartwatches is really poor and I would not recommend you building one. In case you were really desperate, there are some nice alternatives like this one: https://open-smartwatch.github.io/