Fix for using LTO in Arduino IDE 2.x to reduce flash usage #215
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ee issue openwch#204) [CH32VM00X] Move handlers from startup_ch32v00X.S to ch32v00X_misc.c to fix LTO (see issue openwch#204) [CH32V00x] Move handlers from startup_ch32v00x.S to ch32v00x_misc.c to fix LTO (see issue openwch#204) [CH32VM00X] Move handlers from startup_ch32v00X.S to ch32v00X_misc.c to fix LTO (see issue openwch#204) [CH32VM00X] Move handlers from startup_ch32v00X.S to ch32v00X_misc.c to fix LTO (see issue openwch#204) Move handlers from startup_ch32v00x.S to ch32v00x_misc.c to fix LTO (see issue openwch#204)
This was referenced Aug 13, 2025
This was referenced Sep 3, 2025
jobitjoseph
added a commit
to jobitjoseph/CH32_Arduino_Corexx
that referenced
this pull request
Oct 28, 2025
Fix #204, #179, #25. First only for CH32V003, CH32VM00X, other may follow... Flash memory fills up quickly, especially on chips like the V003 and V002 that have only 16kB of flash. 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; potentially saving multiple kilobytes of valuable flash memory. 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). Note that LTO can also reduce RAM usage. After lengthy research (see #204) the main cause appeared to be a known issue in the used GCC compiler/linker, related to how weak functions defined in assembly files can take precedence over regular functions that were supposed to redefine their weak counterparts. For the CH32 Arduino core this issue caused important interrupt handlers such as the SysTick handler to be removed when using LTO, leaving the microcontroller hanging in the endless loop of the default handler when such an interrupt occurred. So far the best workaround found to get LTO working again, was to move the assembly implementation of the default handlers from startup_ch32....S to a C implementation in ch32...._misc.c. Note: both assembly and C implementations use just two bytes of flash. For the CH32V003 the code is somewhat smaller than before (even without LTO!). Thanks @dfleck for contributing this solution. This PR gives priority to fixing LTO on 16kB processors (mainly V003/V002). Others may follow later. Although the fix is fairly straightforward, I prefer to only submit tested changes and don't have all member of the CH32 family in my collection. See #204 for more information. Related issues: #179, #25, openwch/arduino_core_ch32#215
jobitjoseph
added a commit
to jobitjoseph/CH32_Arduino_Corexx
that referenced
this pull request
Oct 28, 2025
Fix #204, #179, #25. First only for CH32V003, CH32VM00X, other may follow... Flash memory fills up quickly, especially on chips like the V003 and V002 that have only 16kB of flash. 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; potentially saving multiple kilobytes of valuable flash memory. 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). Note that LTO can also reduce RAM usage. After lengthy research (see #204) the main cause appeared to be a known issue in the used GCC compiler/linker, related to how weak functions defined in assembly files can take precedence over regular functions that were supposed to redefine their weak counterparts. For the CH32 Arduino core this issue caused important interrupt handlers such as the SysTick handler to be removed when using LTO, leaving the microcontroller hanging in the endless loop of the default handler when such an interrupt occurred. So far the best workaround found to get LTO working again, was to move the assembly implementation of the default handlers from startup_ch32....S to a C implementation in ch32...._misc.c. Note: both assembly and C implementations use just two bytes of flash. For the CH32V003 the code is somewhat smaller than before (even without LTO!). Thanks @dfleck for contributing this solution. This PR gives priority to fixing LTO on 16kB processors (mainly V003/V002). Others may follow later. Although the fix is fairly straightforward, I prefer to only submit tested changes and don't have all member of the CH32 family in my collection. See #204 for more information. Related issues: #179, #25, openwch/arduino_core_ch32#215
jobitjoseph
added a commit
to jobitjoseph/CH32_Arduino_Corexx
that referenced
this pull request
Oct 28, 2025
Fix #204, #179, #25. First only for CH32V003, CH32VM00X, other may follow... Flash memory fills up quickly, especially on chips like the V003 and V002 that have only 16kB of flash. 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; potentially saving multiple kilobytes of valuable flash memory. 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). Note that LTO can also reduce RAM usage. After lengthy research (see #204) the main cause appeared to be a known issue in the used GCC compiler/linker, related to how weak functions defined in assembly files can take precedence over regular functions that were supposed to redefine their weak counterparts. For the CH32 Arduino core this issue caused important interrupt handlers such as the SysTick handler to be removed when using LTO, leaving the microcontroller hanging in the endless loop of the default handler when such an interrupt occurred. So far the best workaround found to get LTO working again, was to move the assembly implementation of the default handlers from startup_ch32....S to a C implementation in ch32...._misc.c. Note: both assembly and C implementations use just two bytes of flash. For the CH32V003 the code is somewhat smaller than before (even without LTO!). Thanks @dfleck for contributing this solution. This PR gives priority to fixing LTO on 16kB processors (mainly V003/V002). Others may follow later. Although the fix is fairly straightforward, I prefer to only submit tested changes and don't have all member of the CH32 family in my collection. See #204 for more information. Related issues: #179, #25, openwch/arduino_core_ch32#215
jobitjoseph
added a commit
to jobitjoseph/CH32_Arduino_Corexx
that referenced
this pull request
Oct 28, 2025
Fix #204, #179, #25. First only for CH32V003, CH32VM00X, other may follow... Flash memory fills up quickly, especially on chips like the V003 and V002 that have only 16kB of flash. 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; potentially saving multiple kilobytes of valuable flash memory. 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). Note that LTO can also reduce RAM usage. After lengthy research (see #204) the main cause appeared to be a known issue in the used GCC compiler/linker, related to how weak functions defined in assembly files can take precedence over regular functions that were supposed to redefine their weak counterparts. For the CH32 Arduino core this issue caused important interrupt handlers such as the SysTick handler to be removed when using LTO, leaving the microcontroller hanging in the endless loop of the default handler when such an interrupt occurred. So far the best workaround found to get LTO working again, was to move the assembly implementation of the default handlers from startup_ch32....S to a C implementation in ch32...._misc.c. Note: both assembly and C implementations use just two bytes of flash. For the CH32V003 the code is somewhat smaller than before (even without LTO!). Thanks @dfleck for contributing this solution. This PR gives priority to fixing LTO on 16kB processors (mainly V003/V002). Others may follow later. Although the fix is fairly straightforward, I prefer to only submit tested changes and don't have all member of the CH32 family in my collection. See #204 for more information. Related issues: #179, #25, openwch/arduino_core_ch32#215
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix #204, #179, #25. First only for CH32V003, CH32VM00X, other may follow...
Flash memory fills up quickly, especially on chips like the V003 and V002 that have only 16kB of flash.
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; potentially saving multiple kilobytes of valuable flash memory. 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). Note that LTO can also reduce RAM usage.
After lengthy research (see #204) the main cause appeared to be a known issue in the used GCC compiler/linker, related to how weak functions defined in assembly files can take precedence over regular functions that were supposed to redefine their weak counterparts.
For the CH32 Arduino core this issue caused important interrupt handlers such as the SysTick handler to be removed when using LTO, leaving the microcontroller hanging in the endless loop of the default handler when such an interrupt occurred.
So far the best workaround found to get LTO working again, was to move the assembly implementation of the default handlers from
startup_ch32....Sto a C implementation inch32...._misc.c. Note: both assembly and C implementations use just two bytes of flash. For the CH32V003 the code is somewhat smaller than before (even without LTO!). Thanks @dfleck for contributing this solution.This PR gives priority to fixing LTO on 16kB processors (mainly V003/V002). Others may follow later. Although the fix is fairly straightforward, I prefer to only submit tested changes and don't have all member of the CH32 family in my collection.
See #204 for more information.
Related issues: #179, #25,