2019-01-18 06:44 AM
Hi everyone)
I've attached project, that I refer further.
I'm trying to write program on my STM32F103(C8T6).
"From scratch" I've made CubeMX project, set all needed pins in modes I need to, generated it.
I've tried to flash a led on a couple of ports, it's ok.
So, next thing, I've converted project to C++, and this is part, when all the fun begins.
I've added function "my_main" to my_main.cpp file, used it from main.c, it worked, but when I tried to call some function from my_main() (HAL_Delay, or one of my class methods), I keep getting errors like "ld.exe: region `FLASH' overflowed by 17904 bytes", it can be caused by "stm32f103_lcd_board.elf section `.text' will not fit in region `FLASH'" or for example '.ARM' might not fit too (I've seen it on a project, that I used previously).
I can't understand, what's wrong, since earlier I've done projects like this with no trouble at all.
So, if someone have a clue, or can check attached project, I'll be grateful)
Solved! Go to Solution.
2019-01-19 10:17 AM
Sorry, didn't noticed "more posts" button)
So, briefly.
I've found a "fix" for this error. It's seems as TrueStudio bug to me... Let me explain what I did.
First at first, I couldn't get in mind, why there's some big C++ funcs, which I defenetly didn't use at all.
So, I started out with project's properties check... There were level -O0 optimization for both C and C++ parts.
I've changed it to various combinations, but none gave me significant result...
Then I decided to delete all TrueStudio related files (.prj, .ln, .settings and debug folders), and regenerate project with CubeMX, and convert it to C++ proj again. And after that... It compiled and assmbled, just perfectly, with overall size of 19KB.
So, as it turns out, when I generate stock project, it has optimization keys -Os for C and -O0 for C++.
if i change C key to -O0 - this issue shows up. Seems logical...
BUT! Even if I try to revert changes back, and use -Os for C, it takes no signifficant effect (as well, as -Od or other keys).
May be, I miss something important, but I've checked out this behaviour for several times, and it comes down to C optimization key irreversable change. If it's my fault, can somebody explain it to me? Thx)
Also, I've attached console build output screenshots to my post, as well as two 'versions' of project ("freshly-generated", that compiles just fine with 19K, and "spoiled" one, that compiles with unnecessary parts and is ~82K), if someone will want to analyze it.
2019-01-18 07:42 AM
How much FLASH does your CPU have? It looks like only 64K. That is not a lot of space. Depending on how much library code gets pulled in (C++ streams??????) you can quickly exceed that space. Or if you have large arrays that get initialized at compile time.
Look at your MAP file and see how much code the compiler is generating. Or find an F103 part with more FLASH in a pin-compatible package.
2019-01-18 09:11 PM
As about .map file, I don't know, where to look at, I'be not seen there any sizes at all.
I've atteched screenshots also, so hopefully you will understand, what I'm up to...
I know that 64k is not much, but.
I'm adding just a little class, with only two methods, to CubeMX freshly generated project, and it follows with this error.
This shouldn'tbe like that, since it's not first time using C++ on my projects with this board, and it was OK, even with greater classes, cstring, etc combined.
I've not added manually any of C++ std libraries (such as streams, or templates library), or even used any C++ features, besides just classes (no try catch, no templates, containers, nothing at all ).
So it looks pretty strange to me.
I can understand, that something adds to my code, that doubles it's size, but since I don't do anything that may result to this intentionally, I don't know, where to look at, besides my projects configuration...
2019-01-19 04:33 AM
Typically one could tell the linker it has more memory so it can get closure and then review who is eating all the memory. Usually the MAP file will break down code and data contributions at a function level.
2019-01-19 04:34 AM
Use a larger device or decide what you can live without.
2019-01-19 05:55 AM
But there's no code at all. How can I can live without any code at all? :D
Only MX inits (RCC, USB, GPIOB, I2C1), wich worked just fine previosly for this MCU and board, and smallest C++ class, that you can see on attached screenshot (named gpio.cpp)
As for .map I've honestly tried to read it, but it's too unclear to me. It doesn't have any generated code sizes also...
Yet, new .list (and .hex) are not generated by this point, so I couldn't understand, which part is redundant...
2019-01-19 06:19 AM
Edit the linker script to say you have more memory, for the time being, so the linker can get closure and generate map and listings.
C++ brings a lot of baggage with it. Some tools are better at dead code elimination and optimization than others, but library blobs may be harder to reduce if you don't have function level separation of the objects.
2019-01-19 06:33 AM
2019-01-19 06:34 AM
2019-01-19 06:39 AM
The left number is the address, the right is the bytes contributed
.text.USB_DevInit
0x0800a3e0 0x48 Drivers\STM32F1xx_HAL_Driver\Src\stm32f1xx_ll_usb.o
0x0800a3e0 USB_DevInit
.text.USB_ActivateEndpoint
0x0800a428 0x584 Drivers\STM32F1xx_HAL_Driver\Src\stm32f1xx_ll_usb.o
0x0800a428 USB_ActivateEndpoint
.text.USB_DeactivateEndpoint
0x0800a9ac 0x310 Drivers\STM32F1xx_HAL_Driver\Src\stm32f1xx_ll_usb.o
0x0800a9ac USB_DeactivateEndpoint
.text.USB_EPStartXfer
0x0800acbc 0x504 Drivers\STM32F1xx_HAL_Driver\Src\stm32f1xx_ll_usb.o
0x0800acbc USB_EPStartXfer
.text.USB_EPSetStall
0x0800b1c0 0xc0 Drivers\STM32F1xx_HAL_Driver\Src\stm32f1xx_ll_usb.o
0x0800b1c0 USB_EPSetStall
.text.USB_EPClearStall
0x0800b280 0x114 Drivers\STM32F1xx_HAL_Driver\Src\stm32f1xx_ll_usb.o
0x0800b280 USB_EPClearStall
.text.USB_SetDevAddress
0x0800b394 0x26 Drivers\STM32F1xx_HAL_Driver\Src\stm32f1xx_ll_usb.o
0x0800b394 USB_SetDevAddress