Library FLASH usage on STM32

Hi guys!
Very interesting topics out here.
First of all, thanks a lot for this library, I got a lot of fun. Very easy to use ! Congrats !

Those days, I was playing with a STM32G030C8 with STM32duino library and simplefoc in order to make a light device based on Simplefoc.

So the good news is the library works very fine on this device (but you have to add it manually to your board.txt).

It seems to work pretty well except…I cannot use the Commander to easily tune PID parameters because of the huge amount of FLASH it uses (7KB more than my device).
This device use 64KB of Flash.

Without Commander I’m around 54596 octets (83%), compared to the ATmega328P…it’s…wow… a lot.

What I tried:

  • Make a lighter compilation using a hal_conf_extra.h : got few KB free but not much.
  • Use the minimal library : got few B free but not much neather.
  • Tried to use LTO => compile but don’t work on the device.

It seems that Serial library takes way much more Flash usage than on ATMEL devices.

Any ideas about improving that?

Otherwise, I’ll make a lighter communication protocol to change PID parameters.
Thanks a lot!
By the way, yes I saw the post of ELWero about [code size](https://STM32 32KBytes - Decrease overall code size after compiling). It’s just in case somebody would have a nice idea :wink:

Hello @robotsmith

I had the same problem, I had to cut the commander. Also, I tried the G030 but gave up
because Arduino didn’t allow me to reassign the SPI pins which killed my application.
The commander is only for debugging. In production you don’t run it. It slows down the loop.
My solution was to go for SPI interface to pass commands.
Eventually I went for F103 or higher, where I could get more flash.

In your case, may be you could try using SPI for communication?


Hello @Valentine !
Thanks for the answer.
In my application in exclusively use I2C for inboard com and also Serial for long range com.
So I do not need SPI (lucky me :slight_smile: ).
I’ll try to make a simple interface in Serial then.
I’m a bit surprised of the difference of Atmel compilation and STM32 on Arduino.
I’ll digg deeper !

Hi, and welcome @robotsmith !

Are you using just serial or the serial via the USB of the G0? Maybe its the USB support that uses much space?

In any case it would be interesting to know what’s going on and if there is a way to reduce the space used on STM32!

@runger thanks :slight_smile:

No I’m only using the standard USART, no USB. I guess you are right USB would be much worst!

If I find something, I’ll post it here.

Hi there,
I found a way to use the commander.
It seems that the LTO compilation worked and my board works nicely now!
It’s a small win since I use “64308 octets (98%)” of my FLASH, but still a win.

So I used:

  • a custom hal_conf_extra.h to remove the STM32 features I’m not using
  • redownloaded the variant file of my freshly supported STM32G030C8 (I noticed that some files are different in the master branch compare to the 2.0.0 I used)
  • compile with LTO option

Now my device is freshly tuned and works smoothly. Very cool and easy to tune with the simplefocstudio app.


1 Like

Have you considered using RTT? It might require a slight change on the SimpleFOC desktop app to connect (since JLink exposes a telnet port, not a serial port), but I’ve been making extensive use of the RTTStream arduino library, which exposes Segger RTT as a regular Stream object (like Serial).

As a result, you can just hand it to SimpleFOC. I haven’t tried it as a commander input, but it works fine with the Monitor feature so far:

#include <RTTStream.h>
RTTStream rtt;

void setup(){
   rtt.println("Setup done!");

Obviously you need a jlink swd connection, but if you’ve already got one for your micro it means you don’t need to do anything extra. You can interact and log files via the J-Link RTT Viewer app, or open up Jlink itself (the command line tool), and chose connect, and choose the default params aside from selecting “SWD” rather than the default JTAG.

Once that’s connected it exposes a telnet socket (socket://localhost:19021 in my case), which PlatformIO is happy enough to use as a serial terminal. (monitor_port = socket://localhost:19021 in platformio.ini).

The advantage is that at least as far as I can tell the RTT lib is fairly light weight, and supports multiple virtual serial channels over your existing SWD connection. It’s also fairly fast and low impact (allegedly I haven’t confirmed this).

1 Like