Using LTO in Arduino IDE 2.x to reduce flash usage (working!)

[maxint-rd]

TLDR;

Fix linking with LTO in Arduino IDE v2.x using this nice solution by @dfleck : Move weak handlers from startup_ch32v00x.S to ch32v00x_misc.c
Edit: See PR #215 for this fix.

---

Less user friendly method for Windows without code-changes:

• cd %TEMP%/arduino/cores/<latest core folder>
• "%LOCALAPPDATA%\\Arduino15\\packages\\WCH\\tools\\riscv-none-embed-gcc\\8.2.0/bin/riscv-none-embed-ar" mb "HardwareSerial.cpp.o" "core.a" "startup_ch32yyxx.S.o"

---

Background story

One irritating issue I encountered in many CH32V003 projects is that the compiled flash rapidly grows too large. The flash space of the V003 (and the V002) is limited to 16kB, which is filled easily, even if only using a few of the peripherals and a little bit of custom code. Having insufficient room severely limits use of the Arduino environment for these otherwise nice and affordable chips.

As mentioned in this comment, one of the ways to reduce flash usage, is to use Link Time Optimization (LTO). LTO removes code that is never called. This optimization worked great in version 1.8.19 of the Arduino IDE, but didn't work in any v2.x IDE (see also another comment). Since I like using 2.x for the interactive debugger, I also want it to make the smallest optimized hex-file possible, using optimization option "Smallest (-Os) with LTO".

In the past period I've been looking into this issue and recently got a bit further. I'll use this issue to document my progress.

Digging deeper into LTO
When comparing the output with IDE 1.8.19 and the resulting .map files, the mere order of object files seems to make LTO not include critical pieces of code (e.g. interrupt handlers). When testing a simple Blinky with LTO in IDE 2.3.4, it does execute the first digitalWrite(), but then blocks.

The most important missing parts for the Blink sketch seemed to be the SysTick_Handler. The .map file only showed an empty (2 byte) handler. Some other handlers were also empty, such as EXTI7_0_IRQHandler.
Looking for these handlers in the source code revealed a .weak declaration in startup_ch32yyxx.S and the actual implementation in core files such as clock.c and interrupt.cpp.

Finding cause
After months of googling didn't get me any further, I finally seemed to get on the right track. Using keywords ".weak LTO" I found a known GCC linking issue: LTO removes C functions declared as weak in assembler. Sounded just like my issue and it confirmed my earlier observation that object order makes a difference. In short: the startup object should be first, and the actual implementation somewhere later.

Changing order
To further confirm this, I tried to change that order and compare the resulting size and map files. In Windows the Arduino IDE v2.x stores the core archive in the Temp folder under C:\\Users\\<name>\\AppData\\Local. The GCC tools are somewhere down in the Arduino15 subfolder. For easy typing environment variables %TEMP% and %LOCALAPPDATA% can be used.

To change the order of an object in the compiled core.a archive on my Windows 11 PC, I used these commands;

• dir %TEMP%\arduino\cores\
• cd %TEMP%\arduino\cores\<latest core folder>
• "%LOCALAPPDATA%\\Arduino15\\packages\\WCH\\tools\\riscv-none-embed-gcc\\8.2.0/bin/riscv-none-embed-ar" m "core.a" "clock.c.o"

That m option of the ar command moves the clock.c object to the end of the core archive. Another important object could be interrupt.cpp.o, but that depends on the objects actually used by the sketch.

Better order
For a more generic fix it is better to have the startup object be moved to the start of the core archive. This command moves the startup object to before clock.c.o (which in my project came before interrupt.cpp.o):

• "%LOCALAPPDATA%\\Arduino15\\packages\\WCH\\tools\\riscv-none-embed-gcc\\8.2.0/bin/riscv-none-embed-ar" mb "clock.c.o" "core.a" "startup_ch32yyxx.S.o"

In another sketch HardwareSerial.cpp.o came first, so perhaps the best way is to find the first object using this command:

• "%LOCALAPPDATA%\\Arduino15\\packages\\WCH\\tools\\riscv-none-embed-gcc\\8.2.0/bin/riscv-none-embed-ar" tov "core.a"

FYI - If you want to look into the compiled sketch, you can see a disassembly using objdump:

• cd %TEMP%\arduino\sketches\<sketch folder>
• "%LOCALAPPDATA%\\Arduino15\\packages\\WCH\\tools\\riscv-none-embed-gcc\\8.2.0/bin/riscv-none-embed-objdump" -d -S "Blink.ino.elf" > dump.txt

Confirmation
After moving objects within the core,a archive, I recompiled and uploaded my Blink sketch, which used the modified core archive. The table below shows the flash size of the Blink.ino example sketch, compiled for the CH32V003 using various optimization options and all peripherals disabled.

Option	Flash usage	RAM usage	result
-Os	2724 (16%)	240 (11%)	blinks fine
-Os LTO (unchanged)	872 (5%)	152 (7%)	not blinking
-Os LTO (moved clock.c.o)	920 (5%)	152 (7%)	it blinks!
-Os LTO (moved startup.S.o)	1076 bytes (6%)	152 (7%)	still blinks

FYI: the same example compiled for V003 using IDE v1.8.19 also resulted in 1076 bytes (6%) flash usage and 152 bytes (7%) RAM usage. Most likely moving the startup object to be first, makes it contains a few more handlers (and possibly some other code) compared to solely moving clock.c.o to the end.

Conclusion
As shown, the size difference is significant. For the standard Blink example, moving the clock object seems sufficient to get it working. After moving the object the resulting flash was slightly larger. The .map file now showed a realistic size for SysTick_Handler.

At the moment I have not (yet) found a way to make this a permanent fix in platform.txt or board.txt files. The LTO .weak issue is supposedly fixed in a newer version of the GCC suite, but I've not looked deep into that,
I mainly tested the V003, new findings with V002/V006 are listed in comments below.

Edit: @dfleck found a better solution that doesn't require board/platform changes: Move weak handlers from startup_ch32v00x.S to ch32v00x_misc.c
(TODO: make PR for this fix).

[maxint-rd]

Successfully tested LTO with Blink.ino on CH32V002: 1212 bytes (7%).

Used this command:
"%LOCALAPPDATA%\\Arduino15\\packages\\WCH\\tools\\riscv-none-embed-gcc\\8.2.0/bin/riscv-none-embed-ar" mb "HardwareSerial.cpp.o" "core.a" "startup_ch32yyxx.S.o"

Manual optimizations done for CH32V002F4L:

• use ifdef in GPIO_IPD_Unused().
• no define of GPIOB_BASE and use ifdefs (V002 and V004 have no port B)
• same for USART2_BASE and USART2 defines (V002 and V004 have no second uart)

More manual optimizations:

• avoiding using __udivdi3 saves more than 1K. It is used for 64-bit divisions, eg. by getCurrentMicros() in clock.c via micros(). Just changing the data types that are used to 32-bits already made the difference. Accuracy or resolution seemed unaffected and saving so much flash will make 16kB chips such as V003 and V002 much more usable. See this comment for further details.
• making msTick and getTick() use 32-bit variables shrinks flash usage of Blink.ino a bit further. (Now compiling V003 -Os with LTO gives 988 bytes flash, 148 bytes RAM). It also solves a compiler warning.
• Wire.cpp needs to check I2C_MODULE_ENABLED. If some other library includes WIre.h, but the project doesn't use it and has I2C disabled, there is no need for the global object declaration: TwoWire Wire = TwoWire( ); Skipping that can save another KB of flash usage.

[dfleck]

I am way out of my depth here but: I commented out SysTick_Handler in my platform .S file (two places) and my blink goes from 4912 to 2296 and it still blinks when compiled with LTO. I don't think there's a need to weak link it since you know there is a better version that's guaranteed to be there that you absolutely must have.

[maxint-rd]

Hello @dfleck , thanks for your reply. One of my first attempts was to manipulate those interrupts, but I didn't try what you did yet. Need to look into it...

One question: can you try to compile the standard Arduino Blink example with -Os and LTO and tell me the size you got? Please make sure to disable all peripherals, especially the UART module. I assume your 2k+ included something more. As you can read in the table at top, my best result so far was 1k (1076 bytes including all handlers).

[dfleck]

Blink using a CH32V003F4 Smallest without LTO is 2720 and with LTO is 908.*

I did however brick my J4 chip. I loaded my final application on and even "Erase using Power Off" won't bring it back to life. My application cycles thru different visual effects on an RGB LED using three PWMs. No other input or output.

And I just realized there are three SysTick_Handler and it was the last two I commented out. Let me see if I understand this correctly. The first part of the .S file is the vector table. The second part is just declaring everything weak. The third part is "dummy" implementations of everything. Since there is always a C implementation of NMI_Handler, HardFault_Handler, and SysTick_Handler they can be commented out of the weak declaration and implementation and the linker will use the proper C one.

* if I comment out all three of these the size is 912, which tells me the linker is still not properly honoring the .weak declaration for one of the others. And sometimes TIM1_CC_IRQHandler has a C implementation and sometimes doesn't as well as some of the other external interrupts.

I suppose you could move all of the weak declarations and implementations to a C file and the linker would get it right.

But looking at the GCC bug - it looks like this issue was fixed in 2021 with binutils-2.35 (this package seems to include 2.32). I started to look into installing the latest (2.43) but what a PITA!

[maxint-rd]

I did however brick my J4 chip. I loaded my final application on and even "Erase using Power Off" won't bring it back to life.

Oh wow, that's a bummer. For me the power off method always worked. Have you tried first power all off and having nothing connected to the chip before using that erase method? Also make sure to have short direct connections to only 5V/GND/SWIO (no flaky breadboard, no bypass caps on PCB).

Adding a delay at start of setup() during development may increase your chances with your next chip. I assume you're not using an external oscillator are you? You could try the minichlink program with -u option during manual power on (see this video). Issue #194 has some other suggestions. (Somewhere else I read people managed to revive it using some repeated resets but I can't find that anymore).

But looking at the GCC bug - it looks like this issue was fixed in 2021 with binutils-2.35 (this package seems to include 2.32). I started to look into installing the latest (2.43) but what a PITA!

Yes indeed! I kind-of gave up after lots of searching and reading. For now I use a batch-file to move startup_ch32yyxx.S.o in front of HardwareSerial.cpp.o. So far that method worked all the times I tried.

My understanding of the startup.S matches your description. I still want to test your suggestion of commenting out weak declarations. I guess that method requires the others to be conditional depending on enabling of peripheral modules.

As I'm fine with the current size of my LTO Blink, I'm now looking at manual optimizations in the rest of the core. I already found a few specific ones (such as changing micros to only use 32-bit division and adding ifdefs to trim out things). BTW when debugging things the V006 can be handy since it has 62Kb flash.

[dfleck]

I commented out all of the .weak refs and implementations in the .S file (from .option rvc; to TIM2_IRQHandler: 1: j 1b) and added the following to the end of ch32v00x_misc.c

__attribute__ ((weak)) void SW_Handler(void) {while(1);};
__attribute__ ((weak)) void WWDG_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void PVD_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void FLASH_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void RCC_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void EXTI7_0_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void AWU_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void DMA1_Channel1_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void DMA1_Channel2_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void DMA1_Channel3_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void DMA1_Channel4_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void DMA1_Channel5_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void DMA1_Channel6_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void DMA1_Channel7_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void ADC1_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void I2C1_EV_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void I2C1_ER_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void USART1_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void SPI1_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void TIM1_BRK_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void TIM1_UP_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void TIM1_TRG_COM_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void TIM1_CC_IRQHandler(void) {while(1);};
__attribute__ ((weak)) void TIM2_IRQHandler(void) {while(1);};

This doesn't require adding any conditionals for it to work. With all of the interfaces disable and the LTO option my blink is now 1068 bytes.

Thanks for the hints about recovering the J4. I'll add an official WCH-LinkE-RO-1v3 to my Aliexpress cart. For now it's only 8 pins to cut and re-solder and I have 99 chips left.

I see no need for other chips for debugging because the source level debugger is AWESOME. I started using it with some STM32 chips in another project. Being able to set breakpoints and examine variables without adding any diagnostic code that changes timing is sweet!

[dfleck]

I was playing around with the changes to add menu items for the peripherals menu.peripherals=peripherals and was having some trouble with it. While trying to diagnose the problem I've noticed that the file size doesn't change with the defines for ADC_MODULE_ENABLED, SPI_MODULE_ENABLED, or I2C_MODULE_ENABLED. So they can always be defined and there's no need for a menu to disable them as they don't affect file size (the size only increased when I had an analogRead() in the code).

The file size only changes with the defines for UART_MODULE_ENABLED and TIM_MODULE_ENABLED.

[maxint-rd]

Thank you for your detailed description of changes. I'll try it when I have time.

Real time debugging is quite wonderful indeed. Without it I don't think I would have been able to implement improvements such as I2C slave or interrupt driven Serial/I2C.

For me the trouble with changing board.txt/platform.txt was that changes are not picked up without removing the arduino-ide folder from the roaming folder. Just restarting the IDE isn't enough. This is a known and documented issue (although one only knows after finding out).

I did come across one situation where I2C was referenced in a LED display driver library, but not actually used. It would add a few kb of flash space even if I2C was disabled (and the Wire object wasn't referenced in the sketch). By checking I2C_MODULE_ENABLED I could leave out the global Wire object in the Wire library and thereby convince LTO to skip I2C functions and save a bunch of flash. (That LED library should not need CH32 specific changes). I'm not sure if SPI has similar behavior.