STM32 Compatible Libraries

Post here first, or if you can't find a relevant section!
pwrgreg007
Posts: 13
Joined: Sun Jan 09, 2022 2:56 am
Location: LaGrange, GA

STM32 Compatible Libraries

Post by pwrgreg007 »

I cannot get a simple program to compile with (what I believe are) the latest STM drivers, without getting this error:
Arduino: 1.8.19 (Windows 10), Board: "Generic STM32F1 series, BluePill F103C6 (32K), STM32CubeProgrammer (SWD), Enabled (generic 'Serial'), None, Low/Full Speed, Smallest (-Os default), None, Newlib Nano (default)"
c:/users/pwrgr/appdata/local/arduino15/packages/stmicroelectronics/tools/xpack-arm-none-eabi-gcc/10.2.1-1.1/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\pwrgr\AppData\Local\Temp\arduino_build_682641/show_pulse.ino.elf section `.rodata' will not fit in region `FLASH'

c:/users/pwrgr/appdata/local/arduino15/packages/stmicroelectronics/tools/xpack-arm-none-eabi-gcc/10.2.1-1.1/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld.exe: region `FLASH' overflowed by 7820 bytes

collect2.exe: error: ld returned 1 exit status

exit status 1

Error compiling for board Generic STM32F1 series.
This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
This is using the board manager files from:
https://github.com/stm32duino/BoardMana ... index.json
Which contains "STM32 MCU based boards" with versions 2.0.0, 2.1.0, and 2.2.0. All of these versions product the same results.

The only way I can compile is if I used the deprecated files from:
https://github.com/stm32duino/BoardMana ... index.json
Using the oldest version, 1.3.0, I can compile.
Are the new drivers supposed to work in Arduino?

Additional setup information:
I do not have a bootloader installed. I am using "STM32 ST-LINK Utility" to download hex files after they are compiled.
The chip on my Blue Pill appears to be a genuine STM32F103C8T6. I have programs running & working, when I can get them compiled.
by GonzoG » Mon Jan 17, 2022 11:00 am
pwrgreg007 wrote: Mon Jan 17, 2022 1:31 am I found something interesting. First, the presence of hal_conf_extra.h didn't change anything, whether it compiled or not. The instructions at https://github.com/stm32duino/Arduino_C ... issues/228 may need some clarification.
The hex file size (for the blink example) compiled with the deprecated 1.3.0 STM library is 126KB.
I switched Arduino Board part number from "BluePill F103C6" to "BluePill F103CB (or C8 with 128k)" to see if it would compile if it thought the target has more memory. It did compile, and the hex size is now 40kb, which seems to indicate that some step, post-link, is removing unused libraries.
Don't look at hex files size. Those aren't always final files.

When you look at your first post at the terminal output:
... region `FLASH' overflowed by 7820 bytes ...
This means that the program size was about 40KiB. (37268 + 7820 = 40588 = 39.6 KiB)
Go to full post
GonzoG
Posts: 403
Joined: Wed Jan 15, 2020 11:30 am
Answers: 27
Location: Prudnik, Poland

Re: STM32 Compatible Libraries

Post by GonzoG »

As it's said in error:
...will not fit in region `FLASH'...
and
...region `FLASH' overflowed by 7820 bytes...
Compiled program is too big to fit on your board.

Newer STM32 cores need bit more flash.
pwrgreg007
Posts: 13
Joined: Sun Jan 09, 2022 2:56 am
Location: LaGrange, GA

Re: STM32 Compatible Libraries

Post by pwrgreg007 »

Thanks GonzoG for your reply.
Are you saying that the 2.0.x libraries are so large, that the sample LED Blink program will not compile for a Blue Pill?
Am I stuck using the 1.3.0 library?
Thanks in advance.
GonzoG
Posts: 403
Joined: Wed Jan 15, 2020 11:30 am
Answers: 27
Location: Prudnik, Poland

Re: STM32 Compatible Libraries

Post by GonzoG »

By default all peripherals (USART, USB, ADC, Timers, etc) are enabled and set up. Disable what you don't need and it will reduce program size.
pwrgreg007
Posts: 13
Joined: Sun Jan 09, 2022 2:56 am
Location: LaGrange, GA

Re: STM32 Compatible Libraries

Post by pwrgreg007 »

Thanks GonzoG for your reply.
I turned on verbose compile/link output and see tons of library files being linked in, as you pointed out. I can turn off U(S)ART in the IDE. Excuse my newbie-ness, how does one disable all these unneeded libraries from being included? Are those items installed in Library Manager what gets added in at the link stage?
The only thing in my Arduino\Libraries folder is for TFT_eSPI support.
Under Sketch->Include Library, nothing is checked. Seems like that would be the place to ask for these things.
Thanks
GonzoG
Posts: 403
Joined: Wed Jan 15, 2020 11:30 am
Answers: 27
Location: Prudnik, Poland

Re: STM32 Compatible Libraries

Post by GonzoG »

In IDE you can disable USB (10+KiB) and USART(2-3kiB).
Some peripherals can be disabled in hal_conf_extra.h in sketch directory:
https://github.com/stm32duino/wiki/wiki ... figuration

Most of these linked files you see are needed for your program to work.
STMs are different than AVRs used on Arduino boards and need a lot more code to set up them similar to AVRs.

Only libraries included in your sketch are compiled, so no matter how many there are in your Arduino folder, if they aren't included, they won't be added to your program.

But you will have problems with those F103C6 MCUs and Arduino IDE. Even F103C8 with 64kiB of flash is often not enough.
pwrgreg007
Posts: 13
Joined: Sun Jan 09, 2022 2:56 am
Location: LaGrange, GA

Re: STM32 Compatible Libraries

Post by pwrgreg007 »

Thanks for your reply GonzoG, much appreciated

I must be interpreting the documentation on that site incorrectly.
I have this content in hal_conf_extra.h in the sketch folder.

Code: Select all

// turn off STM32 HAL library elements that are not needed
#define HAL_ADC_MODULE_DISABLED
#define HAL_I2C_MODULE_DISABLED
#define HAL_RTC_MODULE_DISABLED
//#define HAL_SPI_MODULE_DISABLED
//#define HAL_TIM_MODULE_DISABLED
#define HAL_DAC_MODULE_DISABLED
#define HAL_EXTI_MODULE_DISABLED	; interrupt API does not used HAL EXTI module anyway API is cleaned with this
#define HAL_ETH_MODULE_DISABLED
#define HAL_SD_MODULE_DISABLED
#define HAL_QSPI_MODULE_DISABLED
HAL_SPI... and HAL_TIM... are apparently needed by the eSPI_TFT stuff, which, while not used now, will be used for additions to the sketch.
I still see the ADC, I2C and other modules included in the linker command that should be disabled. What am I doing wrong here?
Kind of a related question, asking your opinion: Would I be better off going with a "Black Pill" that has more memory?
mrburnette
Posts: 633
Joined: Thu Dec 19, 2019 1:23 am
Answers: 7

Re: STM32 Compatible Libraries

Post by mrburnette »

pwrgreg007 wrote: Sat Jan 15, 2022 11:12 pm ...
ould I be better off going with a "Black Pill" that has more memory?
Yep: According to my Freshman year Prof 50 years ago, "... You can never have too much memory." (And he was talking about the Fortran system at the Uni.)

Ray
ag123
Posts: 1655
Joined: Thu Dec 19, 2019 5:30 am
Answers: 24

Re: STM32 Compatible Libraries

Post by ag123 »

i've a 'strange' feeling that we'd perhaps move to use more of 'cmake' or 'platform io' types of setups.
But that would break a lot of compatibility with 'Arduinoish' way of doing things.
the notion is that dependencies would have to be stated up front, which board, which mcu and which pheriperials/modules.
Cube MX / Cube IDE is one of them that used such concepts well ahead.
the main challenge is that to make a core that works across many boards, the dependencies needs to be linked in 'includes', and inevitability various codes would be linked. it is also extremely complex as it would often be necessary to create codes that is 'cross platform' accounting for the differences across mcus. the trouble with the explicit dependencies approach is that newbies will fumble all over it, it is no longer as simple as
setup();
loop();
i.e. it is no longer 1 code across many mcus, boards, pheriperials, every mcu, board, pheriperial is deemed *different* and build for that, no more 'cross compatibility'. for that matter, Rpi pico uses cmake, rather than an 'arduinoish' core. I'd guess that dependencies is a reason. i.e. to prevent linking 'unrelated' stuff into the core. such approaches, cmake, platform io etc, however, tend to break compatibility even on a same chip and board, the codes become *binded* to the hardware for that particular build. i.e. brittle, breaks for every other configuration that don't strictly follow the dependencies.

note that gcc optimizations is pretty aggressive in reducing the size currently, it figures out the dependencies correctly most of the time.
always select -Os smallest for the build to get a size optimised core. they do not necessarily run slower as mcus has very little or if most of time no cache after all.
User avatar
fpiSTM
Posts: 1738
Joined: Wed Dec 11, 2019 7:11 pm
Answers: 91
Location: Le Mans
Contact:

Re: STM32 Compatible Libraries

Post by fpiSTM »

Right gcc remove unused code. About CMake we will start an activity in Q2 for this. ;)
Post Reply

Return to “General discussion”