Author Topic: getting mplab XC32 to grasp that this is C++ not C  (Read 9971 times)

0 Members and 8 Guests are viewing this topic.

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18889
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #75 on: January 27, 2026, 08:45:12 am »
Quote
I have 2 warnings:
Do you have both flash/ram linker scripts in the project? Your error is from the sram linker script, which you should not be using. Both scripts trying to set the same regions would account for this error.


And if I remove the sram one the build fails.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18889
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #76 on: January 27, 2026, 08:53:11 am »
So the program properties show that I am using 2936 bytes of RAM out of 16kB, but if I increase my stack to 8kB I apparently am over 13kB short of RAM. This is really confusing.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18889
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #77 on: January 27, 2026, 11:15:42 am »
So if in the local *flash.ld file I set the stack to 0x0400 (1kB) the total RAM usage is 2'856 bytes.
if I set it to 0x0800 (2 kB) the total RAM usage is 4904.

So for every 1kB I have in stack, another fantom 1 kB is used?

MPLAB 6.3 has just been released. I guess I should upgrade?
« Last Edit: January 27, 2026, 11:30:29 am by Simon »
 

Offline cv007

  • Super Contributor
  • ***
  • Posts: 1061
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #78 on: January 27, 2026, 08:55:38 pm »
Quote
MPLAB 6.3 has just been released. I guess I should upgrade?
If you want, but its not a way to solve your problem.

Quote
c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/ld.exe:samc21j17a_sram.ld:33: warning:
First, why not download the gcc toolchain from arm where you have a current version of gcc and which you will be able to use c++17/c++20 features if wanted. I have no idea what 6.3.1 means in terms of the atmel gnu toolchain numbering, but I would guess its old. For c++ 17 the inline variable feature is worth having, and there are other newer language features that you can pick and choose if wanted. MPLABX can be told to add the new toolchain to its list of toolchain options.

Next, you should normally have 1 linker script in use, and its name should not be _sram. But you now mention a flash.ld file. There are a lot of moving parts in your posts, so is difficult to keep up.

Also, I would not put a lot of faith in the MPLABX gui size info in the project properties panel- it will work, but it sometimes lags behind so you can be looking at old info for size. A post build step could be added where arm-none-eabi-size is run against the .elf file and the size will show up in the build output. I also had a previous post (43) where I described how you can eliminate the stack from showing up in data (gui) or bss (size) if wanted (which also puts the top of stack at the end of ram, and the stack size define is instead asserted in the linker script, instead of an absolute size of a stack section that leaves unused ram above it).

edit- I would also keep a backup copy (renamed) of the original linker script if making modifications. You then have an original copy you can easily find and look at to see where you started and compare to what you have now, in case there are problems at some point that are a result of the modifications.
« Last Edit: January 27, 2026, 09:03:03 pm by cv007 »
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18889
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #79 on: January 28, 2026, 08:41:07 am »
Quote
MPLAB 6.3 has just been released. I guess I should upgrade?
If you want, but its not a way to solve your problem.

Quote
c:/program files (x86)/atmel/studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/ld.exe:samc21j17a_sram.ld:33: warning:
First, why not download the gcc toolchain from arm where you have a current version of gcc and which you will be able to use c++17/c++20 features if wanted. I have no idea what 6.3.1 means in terms of the atmel gnu toolchain numbering, but I would guess its old. For c++ 17 the inline variable feature is worth having, and there are other newer language features that you can pick and choose if wanted. MPLABX can be told to add the new toolchain to its list of toolchain options.


Good idea, this seems to be the current download page: https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads I see no mention of cortex-M in there, are they for all ARM cores now?

Quote

Next, you should normally have 1 linker script in use, and its name should not be _sram. But you now mention a flash.ld file. There are a lot of moving parts in your posts, so is difficult to keep up.


I am looking at all options, the DFP packs from microchip come with both a *_flash.ld and a *_sram.ld file. I don't know which on is in use. In MPLABX it automatically puts both into a GCC project. I have also been trying to setup a basic environment with VSCode, here I choose one linker file at a time and that's that.

Quote

Also, I would not put a lot of faith in the MPLABX gui size info in the project properties panel- it will work, but it sometimes lags behind so you can be looking at old info for size. A post build step could be added where arm-none-eabi-size is run against the .elf file and the size will show up in the build output. I also had a previous post (43) where I described how you can eliminate the stack from showing up in data (gui) or bss (size) if wanted (which also puts the top of stack at the end of ram, and the stack size define is instead asserted in the linker script, instead of an absolute size of a stack section that leaves unused ram above it).

edit- I would also keep a backup copy (renamed) of the original linker script if making modifications. You then have an original copy you can easily find and look at to see where you started and compare to what you have now, in case there are problems at some point that are a result of the modifications.

I do in fact have to compile the project twice to get the RAM usage statistic to change.

This is all very confusing. Are there any courses one can enroll on to learn about all this sort of stuff. Not just programming but this setting up and how the nuts and bolts of the toolchain work?
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3910
  • Country: it
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #80 on: January 28, 2026, 09:05:24 am »
I don't know which on is in use.
after every succesful compilation (since a few versions of the XC compilers):
Code: [Select]
Info: Loading file: [...].gld
Quote
In MPLABX it automatically puts both into a GCC project.
no? never happened here
Quote
I have also been trying to setup a basic environment with VSCode, here I choose one linker file at a time and that's that.
neither does that
Also, if you want to use the MPLAB extensions:
- create a new, empty profile
- add the MPLAB extensions, and only those
- Ctrl+Shift+P -> Create project
you get an empty main file, no linker scripts, not anything else (the default script is taken from the DFP. If you add it to the project tree it will be used instead, and if you have multiple files... i don't know, haven't tried, have no reason to)
Can't really be simpler than that

Quote
I do in fact have to compile the project twice to get the RAM usage statistic to change.
This also never happened here, on multiple machines over the years, and i used MPLABX since almost the very first release

EDIT: Maybe all the above doesn't apply, if you're using vanilla GCC instead of XC32. In which case, nevermind
« Last Edit: January 28, 2026, 09:34:04 am by JPortici »
 

Online voltsandjolts

  • Supporter
  • ****
  • Posts: 3756
  • Country: gb
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #81 on: January 28, 2026, 09:28:58 am »
This is all very confusing. Are there any courses one can enroll on to learn about all this sort of stuff. Not just programming but this setting up and how the nuts and bolts of the toolchain work?

Probably there is. But this is well worth reading first of all;
https://github.com/cpq/bare-metal-programming-guide

Also maybe this (recommended by a knowledgeable member here);
https://www.eevblog.com/forum/microcontrollers/changing-mcs-after-10-years-from-pic-to-stmicro/msg5780703/#msg5780703
« Last Edit: January 28, 2026, 09:32:17 am by voltsandjolts »
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18889
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #82 on: January 28, 2026, 11:10:41 am »
This is the output of a clean build using the latest ARM GCC compiler. clean project setup. The two liker files (sram and flah) are put into the main project folder at project creation.

CLEAN SUCCESSFUL (total time: 26ms)
make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-conf
make  -f nbproject/Makefile-default.mk dist/default/debug/canopen_compact_arm_gcc.X.debug.elf

make[2]: Entering directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
"C:\Program Files (x86)\Arm\GNU Toolchain mingw-w64-i686-arm-none-eabi\bin\arm-none-eabi-g++.exe"  -mcpu=cortex-m0plus -g -D__DEBUG  -gdwarf-2  -x c++ -c -D__SAMC21J17A__  -mthumb -I "C:/Program Files/Microchip/MPLABX/v6.30/packs/Microchip/SAMC21_DFP/3.9.248/samc21/include"  -I "C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"  -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions -mlong-calls -I "../library_cpp" -I "settings" -Wall -MMD -MF "build/default/debug/main.o.d" -o build/default/debug/main.o main.cpp  -DXPRJ_default=default   
make[2]: Leaving directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
make[2]: Entering directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
"C:\Program Files (x86)\Arm\GNU Toolchain mingw-w64-i686-arm-none-eabi\bin\arm-none-eabi-g++.exe"  -mcpu=cortex-m0plus -g -D__DEBUG  -gdwarf-2  -x c++ -c -D__SAMC21J17A__  -mthumb -I "C:/Program Files/Microchip/MPLABX/v6.30/packs/Microchip/SAMC21_DFP/3.9.248/samc21/include"  -I "C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"  -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions -mlong-calls -I "../library_cpp" -I "settings" -Wall -MMD -MF "build/default/debug/_ext/1229929904/nvmc_samc.o.d" -o build/default/debug/_ext/1229929904/nvmc_samc.o ../library_cpp/nvmc_samc.cpp  -DXPRJ_default=default   
make[2]: Leaving directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
make[2]: Entering directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
"C:\Program Files (x86)\Arm\GNU Toolchain mingw-w64-i686-arm-none-eabi\bin\arm-none-eabi-g++.exe"  -mcpu=cortex-m0plus -g -D__DEBUG  -gdwarf-2  -x c++ -c -D__SAMC21J17A__  -mthumb -I "C:/Program Files/Microchip/MPLABX/v6.30/packs/Microchip/SAMC21_DFP/3.9.248/samc21/include"  -I "C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"  -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions -mlong-calls -I "../library_cpp" -I "settings" -Wall -MMD -MF "build/default/debug/canopen.o.d" -o build/default/debug/canopen.o canopen.cpp  -DXPRJ_default=default   
make[2]: Leaving directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
make[2]: Entering directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
"C:\Program Files (x86)\Arm\GNU Toolchain mingw-w64-i686-arm-none-eabi\bin\arm-none-eabi-g++.exe"  -mcpu=cortex-m0plus -g -D__DEBUG  -gdwarf-2  -x c++ -c -D__SAMC21J17A__  -mthumb -I "C:/Program Files/Microchip/MPLABX/v6.30/packs/Microchip/SAMC21_DFP/3.9.248/samc21/include"  -I "C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"  -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions -mlong-calls -I "../library_cpp" -I "settings" -Wall -MMD -MF "build/default/debug/_ext/1229929904/port_control.o.d" -o build/default/debug/_ext/1229929904/port_control.o ../library_cpp/port_control.cpp  -DXPRJ_default=default   
make[2]: Leaving directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
make[2]: Entering directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
"C:\Program Files (x86)\Arm\GNU Toolchain mingw-w64-i686-arm-none-eabi\bin\arm-none-eabi-g++.exe"   -mcpu=cortex-m0plus -g -D__DEBUG  -gdwarf-2  -x c -c -D__SAMC21J17A__  -mthumb -I "C:/Program Files/Microchip/MPLABX/v6.30/packs/Microchip/SAMC21_DFP/3.9.248/samc21/include"  -I "C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"  -Os -ffunction-sections -mlong-calls -Wall -MMD -MF "build/default/debug/system_samc21j17a.o.d" -o build/default/debug/system_samc21j17a.o system_samc21j17a.c  -DXPRJ_default=default   
make[2]: Leaving directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
make[2]: Entering directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
"C:\Program Files (x86)\Arm\GNU Toolchain mingw-w64-i686-arm-none-eabi\bin\arm-none-eabi-g++.exe"   -mcpu=cortex-m0plus -g -D__DEBUG  -gdwarf-2  -x c -c -D__SAMC21J17A__  -mthumb -I "C:/Program Files/Microchip/MPLABX/v6.30/packs/Microchip/SAMC21_DFP/3.9.248/samc21/include"  -I "C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"  -Os -ffunction-sections -mlong-calls -Wall -MMD -MF "build/default/debug/startup_samc21j17a.o.d" -o build/default/debug/startup_samc21j17a.o startup_samc21j17a.c  -DXPRJ_default=default   
make[2]: Leaving directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
make[2]: Entering directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
"C:\Program Files (x86)\Arm\GNU Toolchain mingw-w64-i686-arm-none-eabi\bin\arm-none-eabi-g++.exe"  -mcpu=cortex-m0plus -g -D__DEBUG  -gdwarf-2  -x c++ -c -D__SAMC21J17A__  -mthumb -I "C:/Program Files/Microchip/MPLABX/v6.30/packs/Microchip/SAMC21_DFP/3.9.248/samc21/include"  -I "C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"  -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions -mlong-calls -I "../library_cpp" -I "settings" -Wall -MMD -MF "build/default/debug/_ext/1229929904/rtc.o.d" -o build/default/debug/_ext/1229929904/rtc.o ../library_cpp/rtc.cpp  -DXPRJ_default=default   
make[2]: Leaving directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
make[2]: Entering directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
"C:\Program Files (x86)\Arm\GNU Toolchain mingw-w64-i686-arm-none-eabi\bin\arm-none-eabi-g++.exe"  -mcpu=cortex-m0plus -g -D__DEBUG  -gdwarf-2  -x c++ -c -D__SAMC21J17A__  -mthumb -I "C:/Program Files/Microchip/MPLABX/v6.30/packs/Microchip/SAMC21_DFP/3.9.248/samc21/include"  -I "C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"  -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions -mlong-calls -I "../library_cpp" -I "settings" -Wall -MMD -MF "build/default/debug/_ext/1229929904/clock_samc.o.d" -o build/default/debug/_ext/1229929904/clock_samc.o ../library_cpp/clock_samc.cpp  -DXPRJ_default=default   
make[2]: Leaving directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/bin/ld.exe:samc21j17a_sram.ld:33: warning: redeclaration of memory region `rom'
C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/bin/ld.exe:samc21j17a_sram.ld:34: warning: redeclaration of memory region `ram'
C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/bin/ld.exe: C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp\libg_nano.a(libc_a-closer.o): in function `_close_r':
closer.c:(.text._close_r+0xc): warning: _close is not implemented and will always fail
make[2]: Entering directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
"C:\Program Files (x86)\Arm\GNU Toolchain mingw-w64-i686-arm-none-eabi\bin\arm-none-eabi-g++.exe"  -mcpu=cortex-m0plus   -gdwarf-2  -D__SAMC21J17A__   -T"samc21j17a_flash.ld" -T"samc21j17a_sram.ld"  -mthumb --specs=nano.specs --specs=nosys.specs -Wl,-Map="dist/default/debug\canopen_compact_arm_gcc.X.debug.map"  -o dist/default/debug/canopen_compact_arm_gcc.X.debug.elf build/default/debug/startup_samc21j17a.o build/default/debug/system_samc21j17a.o build/default/debug/canopen.o build/default/debug/main.o build/default/debug/_ext/1229929904/nvmc_samc.o build/default/debug/_ext/1229929904/port_control.o build/default/debug/_ext/1229929904/rtc.o build/default/debug/_ext/1229929904/clock_samc.o      -DXPRJ_default=default    -Wl,--defsym=__MPLAB_BUILD=1,--defsym=__ICD2RAM=1,--defsym=__MPLAB_DEBUG=1,--defsym=__DEBUG=1 -Wl,--gc-sections 
C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/bin/ld.exe: C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp\libg_nano.a(libc_a-closer.o): note: the message above does not take linker garbage collection into account
C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/bin/ld.exe: C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp\libg_nano.a(libc_a-lseekr.o): note: the message above does not take linker garbage collection into account
C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/bin/ld.exe: C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp\libg_nano.a(libc_a-readr.o): note: the message above does not take linker garbage collection into account
C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/bin/ld.exe: C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp\libg_nano.a(libc_a-writer.o): note: the message above does not take linker garbage collection into account
make[2]: Leaving directory 'C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X'
C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/bin/ld.exe: C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp\libg_nano.a(libc_a-lseekr.o): in function `_lseek_r':
lseekr.c:(.text._lseek_r+0x10): warning: _lseek is not implemented and will always fail
C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/bin/ld.exe: C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp\libg_nano.a(libc_a-readr.o): in function `_read_r':
readr.c:(.text._read_r+0x10): warning: _read is not implemented and will always fail
C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/bin/ld.exe: C:/Program Files (x86)/Arm/GNU Toolchain mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/15.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp\libg_nano.a(libc_a-writer.o): in function `_write_r':
writer.c:(.text._write_r+0x10): warning: _write is not implemented and will always fail

BUILD SUCCESSFUL (total time: 2s)
Loading symbols from C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X/dist/default/debug/canopen_compact_arm_gcc.X.debug.elf...
Loading code from C:/Users/simon/OneDrive/Project_Firmware/canopen_compact_arm_gcc.X/dist/default/debug/canopen_compact_arm_gcc.X.debug.elf...
Program loaded with pack,SAMC21_DFP,3.9.248,Microchip
Loading completed


 

 

Online eutectique

  • Frequent Contributor
  • **
  • Posts: 632
  • Country: be
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #83 on: January 28, 2026, 11:25:06 am »
The two liker files (sram and flah) are put into the main project folder at project creation.

Put there by whom or by what ?
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18889
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #84 on: January 28, 2026, 11:43:09 am »
The two liker files (sram and flah) are put into the main project folder at project creation.

Put there by whom or by what ?

The MPLAB.X project wizard, If you create a blank project it starts with 2 linker files, start_up.c and system.c I think in the past I removed the C files but now I don't know if that is such a good idea.
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 5762
  • Country: dk
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #85 on: January 28, 2026, 12:11:20 pm »
The two liker files (sram and flah) are put into the main project folder at project creation.

Put there by whom or by what ?

The MPLAB.X project wizard, If you create a blank project it starts with 2 linker files, start_up.c and system.c I think in the past I removed the C files but now I don't know if that is such a good idea.

startup is usually initializing the data section, zeroing the bss section, and the vector table.  System sets up clocks, fpu, memory, and such

thing that need to be done somewhere before calling main
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18889
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #86 on: January 28, 2026, 12:12:40 pm »
Need to be done, so who calls these functions?
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 5762
  • Country: dk
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #87 on: January 28, 2026, 12:33:03 pm »
Need to be done, so who calls these functions?

generally, reset in the vectortable (place at the right place by the linker using the ld file) jumps to the initialization of data/bss, calls system setup and then calls main
 

Online eutectique

  • Frequent Contributor
  • **
  • Posts: 632
  • Country: be
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18889
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #89 on: January 28, 2026, 01:13:56 pm »
Plenty for me to read when I get home. Meanwhile this program is claiming to compile fine so I best see if I can make it work.
 

Offline cv007

  • Super Contributor
  • ***
  • Posts: 1061
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #90 on: January 28, 2026, 11:24:00 pm »
Quote
If you create a blank project it starts with 2 linker files, start_up.c and system.c
This is an initial creation of files to get you started. If you get two linker scripts generated, delete the sram one as already mentioned earlier in this thread. The startup file is readable, and can be seen to init data/bss and also sets up the vector table entries. The system file you can use or discard as needed as it typically is used for just keeping track of cpu speed at runtime. Maybe depending on which mcu is in use (ram > N) the ide gives the option of using an sram linker script so provides both flash/ram, who knows/who cares just delete it. The startup file can be modified or replaced as you wish, but there is probably little reason not to use it until you have specific needs.

You can also get rid of the not implemented warnings for sys functions (_close_r, l_seek_r, etc.) in project settings- arm-ld, General, Additional specs, set to none. You will then also not have _sbrk available which means you will always get a compile time error anytime malloc gets hauled in for any reason. For those that do not want malloc in use, this is a good solution to keeping it from showing up without your knowledge (you will most likely find out eventually, but nicer to know at the point when it is added).

So a simple sequence will get you started in mplabx- new project wizard, choosing the arm gcc compiler, delete the sram linker if it shows up in the project linker script folder, in project properties set arm-ld additional specs to none, check gcc and g++ optimizations (will most likely start at -Os, so no need to change at least for me), enable the lss output so you can view the generated asm. Create a new c++ source file, create int main(){}, and you have a starting point (and at that point should be able to compile with no errors).

At that point, if you want to eliminate the stack from showing up in ram size usage and/or want to put the stack at the top of ram you can modify the linker script as previously discussed. Early in the linker script there is a heap define symbol check that uses a default value (not 0) if no defined (passed in), and I would simply change that default value to 0 which will require you to either manually change the value in the linker script if the heap is wanted later or by passing in a define value. This will also eliminate any allocated heap section from showing up in ram usage,  which is not wanted when the heap is not used.

For c++, I would also add in g++ additional options- -std=c++17 (or -std=c++20 but will then also want to add -Wno-volatile).
« Last Edit: January 28, 2026, 11:41:58 pm by cv007 »
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18889
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #91 on: January 29, 2026, 06:30:01 am »
The make file in a starter project contains little but seems to refer to two other make files. So are you saying that I should delete the reference in the make file(s) to the sram.ld file, if I can find them? If I just delete the sram linker the compile fails as it wants it. The project is also calling on sram and flash linker scripts in the DFP as it flags up a redefinition of terms in the linker files.

In the land of trying to do this in VSCode my program won't boot probably because I have not got the start up stuff working.
 

Offline cv007

  • Super Contributor
  • ***
  • Posts: 1061
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #92 on: January 29, 2026, 10:14:25 am »
Quote
So are you saying that I should delete the reference in the make file(s) to the sram.ld file, if I can find them?
I wouldn't touch the makefiles in an ide (if the ide created them). I guess delete may have been the wrong word- right click the sram linker script (in the linker script folder listed in the project) and you will have an option to remove it from project. The ide should then handle all the details of removing any references to it. That's the theory anyway.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18889
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #93 on: January 29, 2026, 10:26:11 am »
Yes, but as it then goes and finds the same file in the DFP it will still load it anyway, I assume that is why the output from compiling is warning me that is found sram and rom redefined in linker files in the DFP after reading the ones in the project.

This is what is irking me, I am trying to understand the setup but some much is buried and hidden and I don't know if that is causing me issues.
 

Offline cv007

  • Super Contributor
  • ***
  • Posts: 1061
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #94 on: January 29, 2026, 11:27:12 pm »
I can create a new project for a SAMC21J17A, ends up with a single flash linker script and the normal two system/startup source files. I do what I described in the third paragraph of my previous post, and compiles without errors.

You should be able to do the same, and if you can't then something is wrong and there is no need to troubleshoot the current project until this basic step can be done.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18889
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #95 on: January 30, 2026, 06:48:58 am »
Well on my personal computer it works, I'll try the computer at work. I take it you mean that you remove the sram linker script from the project. This is what I get with verbose output and pedantic warnings turned on. Thyere are notes about duplicate and non existent locations:

Code: [Select]
CLEAN SUCCESSFUL (total time: 6ms)
make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-conf
make  -f nbproject/Makefile-default.mk dist/default/debug/test_linkers.X.debug.elf
Using built-in specs.
make[2]: Entering directory 'C:/Users/simon/MPLABXProjects/test_linkers.X'
"C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10\bin\arm-none-eabi-g++.exe"  -mcpu=cortex-m0plus -g -D__DEBUG  -gdwarf-2  -x c++ -c -D__SAMC21J17A__  -mthumb -I "C:/Users/simon/.mchp_packs/Microchip/SAMC21_DFP/3.9.248/samc21/include"  -I "C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"  -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions -mlong-calls -Wall -Wextra -pedantic -v -MP -MMD -MF "build/default/debug/main.o.d" -o build/default/debug/main.o main.cpp  -DXPRJ_default=default   
COLLECT_GCC=C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10\bin\arm-none-eabi-g++.exe
Target: arm-none-eabi
make[2]: Leaving directory 'C:/Users/simon/MPLABXProjects/test_linkers.X'
make[2]: Entering directory 'C:/Users/simon/MPLABXProjects/test_linkers.X'
"C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10\bin\arm-none-eabi-g++.exe"   -mcpu=cortex-m0plus -g -D__DEBUG  -gdwarf-2  -x c -c -D__SAMC21J17A__  -mthumb -I "C:/Users/simon/.mchp_packs/Microchip/SAMC21_DFP/3.9.248/samc21/include"  -I "C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"  -Os -ffunction-sections -mlong-calls -Wall -MP -MMD -MF "build/default/debug/startup_samc21j17a.o.d" -o build/default/debug/startup_samc21j17a.o startup_samc21j17a.c  -DXPRJ_default=default   
make[2]: Leaving directory 'C:/Users/simon/MPLABXProjects/test_linkers.X'
make[2]: Entering directory 'C:/Users/simon/MPLABXProjects/test_linkers.X'
"C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10\bin\arm-none-eabi-g++.exe"   -mcpu=cortex-m0plus -g -D__DEBUG  -gdwarf-2  -x c -c -D__SAMC21J17A__  -mthumb -I "C:/Users/simon/.mchp_packs/Microchip/SAMC21_DFP/3.9.248/samc21/include"  -I "C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include"  -Os -ffunction-sections -mlong-calls -Wall -MP -MMD -MF "build/default/debug/system_samc21j17a.o.d" -o build/default/debug/system_samc21j17a.o system_samc21j17a.c  -DXPRJ_default=default   
make[2]: Leaving directory 'C:/Users/simon/MPLABXProjects/test_linkers.X'
make[2]: Entering directory 'C:/Users/simon/MPLABXProjects/test_linkers.X'
"C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10\bin\arm-none-eabi-g++.exe"  -mcpu=cortex-m0plus   -gdwarf-2  -D__SAMC21J17A__   -T"samc21j17a_flash.ld"  -mthumb --specs=nosys.specs -Wl,-Map="dist/default/debug\test_linkers.X.debug.map"  -o dist/default/debug/test_linkers.X.debug.elf build/default/debug/startup_samc21j17a.o build/default/debug/system_samc21j17a.o build/default/debug/main.o      -DXPRJ_default=default    -Wl,--defsym=__MPLAB_BUILD=1,--defsym=__ICD2RAM=1,--defsym=__MPLAB_DEBUG=1,--defsym=__DEBUG=1 -Wl,--gc-sections 
make[2]: Leaving directory 'C:/Users/simon/MPLABXProjects/test_linkers.X'
Configured with: /mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/src/gcc/configure --build=x86_64-linux-gnu --host=i686-w64-mingw32 --target=arm-none-eabi --prefix=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-mingw --libexecdir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-mingw/lib --infodir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-mingw/share/doc/gcc-arm-none-eabi/info --mandir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-mingw/share/doc/gcc-arm-none-eabi/man --htmldir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-mingw/share/doc/gcc-arm-none-eabi/html --pdfdir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-mingw/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-mingw-wildcard --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-headers=yes --with-newlib --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-mingw/arm-none-eabi --with-libiconv-prefix=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/build-mingw/host-libs/usr --with-gmp=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/build-mingw/host-libs/usr --with-mpfr=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/build-mingw/host-libs/usr --with-mpc=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/build-mingw/host-libs/usr --with-isl=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/build-mingw/host-libs/usr --with-libelf=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/build-mingw/host-libs/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='GNU Arm Embedded Toolchain 10.3-2021.10' --with-multilib-list=rmprofile,aprofile
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.3.1 20210824 (release) (GNU Arm Embedded Toolchain 10.3-2021.10)
COLLECT_GCC_OPTIONS='-mcpu=cortex-m0plus' '-g' '-D' '__DEBUG' '-gdwarf-2' '-c' '-D' '__SAMC21J17A__' '-mthumb' '-I' 'C:/Users/simon/.mchp_packs/Microchip/SAMC21_DFP/3.9.248/samc21/include' '-I' 'C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include' '-ffunction-sections' '-fdata-sections' '-fno-rtti' '-fno-exceptions' '-mlong-calls' '-Wall' '-Wextra' '-Wpedantic' '-v' '-MP' '-MMD' '-MF' 'build/default/debug/main.o.d' '-o' 'build/default/debug/main.o' '-D' 'XPRJ_default=default' '-mfloat-abi=soft' '-mlibarch=armv6s-m' '-march=armv6s-m'
 c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/bin/../lib/gcc/arm-none-eabi/10.3.1/cc1plus.exe -quiet -v -I C:/Users/simon/.mchp_packs/Microchip/SAMC21_DFP/3.9.248/samc21/include -I C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include -imultilib thumb/v6-m/nofp -iprefix c:\program files (x86)\gnu arm embedded toolchain\10 2021.10\bin\../lib/gcc/arm-none-eabi/10.3.1/ -isysroot c:\program files (x86)\gnu arm embedded toolchain\10 2021.10\bin\../arm-none-eabi -MMD build/default/debug/main.d -MF build/default/debug/main.o.d -MP -MQ build/default/debug/main.o -D__USES_INITFINI__ -D __DEBUG -D __SAMC21J17A__ -D XPRJ_default=default main.cpp -quiet -dumpbase main.cpp -mcpu=cortex-m0plus -mthumb -mlong-calls -mfloat-abi=soft -mlibarch=armv6s-m -march=armv6s-m -auxbase-strip build/default/debug/main.o -g -gdwarf-2 -Wall -Wextra -Wpedantic -version -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions -o C:\Users\simon\AppData\Local\Temp\cckGtczr.s
GNU C++14 (GNU Arm Embedded Toolchain 10.3-2021.10) version 10.3.1 20210824 (release) (arm-none-eabi)
compiled by GNU C version 7.3-win32 20180312, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/lib/gcc/../../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/include/c++/10.3.1"
ignoring duplicate directory "c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/lib/gcc/../../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/include/c++/10.3.1/arm-none-eabi/thumb/v6-m/nofp"
ignoring duplicate directory "c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/lib/gcc/../../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/include/c++/10.3.1/backward"
ignoring duplicate directory "c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/lib/gcc/../../lib/gcc/arm-none-eabi/10.3.1/include"
ignoring nonexistent directory "c:\program files (x86)\gnu arm embedded toolchain\10 2021.10\bin\../arm-none-eabi/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-mingw/lib/gcc/arm-none-eabi/10.3.1/../../../../include"
ignoring duplicate directory "c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/lib/gcc/../../lib/gcc/arm-none-eabi/10.3.1/include-fixed"
ignoring duplicate directory "c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/lib/gcc/../../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/include"
ignoring nonexistent directory "c:\program files (x86)\gnu arm embedded toolchain\10 2021.10\bin\../arm-none-eabi/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 C:/Users/simon/.mchp_packs/Microchip/SAMC21_DFP/3.9.248/samc21/include
 C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include
 c:\program files (x86)\gnu arm embedded toolchain\10 2021.10\bin\../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/include/c++/10.3.1
 c:\program files (x86)\gnu arm embedded toolchain\10 2021.10\bin\../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/include/c++/10.3.1/arm-none-eabi/thumb/v6-m/nofp
 c:\program files (x86)\gnu arm embedded toolchain\10 2021.10\bin\../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/include/c++/10.3.1/backward
 c:\program files (x86)\gnu arm embedded toolchain\10 2021.10\bin\../lib/gcc/arm-none-eabi/10.3.1/include
 c:\program files (x86)\gnu arm embedded toolchain\10 2021.10\bin\../lib/gcc/arm-none-eabi/10.3.1/include-fixed
 c:\program files (x86)\gnu arm embedded toolchain\10 2021.10\bin\../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/include
End of search list.
GNU C++14 (GNU Arm Embedded Toolchain 10.3-2021.10) version 10.3.1 20210824 (release) (arm-none-eabi)
compiled by GNU C version 7.3-win32 20180312, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f8787892a7c5aa84cea58dce52be7118
COLLECT_GCC_OPTIONS='-mcpu=cortex-m0plus' '-g' '-D' '__DEBUG' '-gdwarf-2' '-c' '-D' '__SAMC21J17A__' '-mthumb' '-I' 'C:/Users/simon/.mchp_packs/Microchip/SAMC21_DFP/3.9.248/samc21/include' '-I' 'C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include' '-ffunction-sections' '-fdata-sections' '-fno-rtti' '-fno-exceptions' '-mlong-calls' '-Wall' '-Wextra' '-Wpedantic' '-v' '-MP' '-MMD' '-MF' 'build/default/debug/main.o.d' '-o' 'build/default/debug/main.o' '-D' 'XPRJ_default=default' '-mfloat-abi=soft' '-mlibarch=armv6s-m' '-march=armv6s-m'
 c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/as.exe -v -I C:/Users/simon/.mchp_packs/Microchip/SAMC21_DFP/3.9.248/samc21/include -I C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include -march=armv6s-m -mfloat-abi=soft -meabi=5 -o build/default/debug/main.o C:\Users\simon\AppData\Local\Temp\cckGtczr.s
GNU assembler version 2.36.1 (arm-none-eabi) using BFD version (GNU Arm Embedded Toolchain 10.3-2021.10) 2.36.1.20210621
MAKEFLAGS=r -j24 -Otarget  --sync-mutex=0xd8 -- COMPARE_BUILD=false TYPE_IMAGE=DEBUG_RUN CONF=default SUBPROJECTS=
COMPILER_PATH=c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/bin/../lib/gcc/arm-none-eabi/10.3.1/;c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/bin/../lib/gcc/;c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/
LIBRARY_PATH=c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/bin/../lib/gcc/arm-none-eabi/10.3.1/thumb/v6-m/nofp/;c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp/;c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/bin/../arm-none-eabi/lib/thumb/v6-m/nofp/;c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/bin/../lib/gcc/arm-none-eabi/10.3.1/;c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/bin/../lib/gcc/;c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/lib/;c:/program files (x86)/gnu arm embedded toolchain/10 2021.10/bin/../arm-none-eabi/lib/
COLLECT_GCC_OPTIONS='-mcpu=cortex-m0plus' '-g' '-D' '__DEBUG' '-gdwarf-2' '-c' '-D' '__SAMC21J17A__' '-mthumb' '-I' 'C:/Users/simon/.mchp_packs/Microchip/SAMC21_DFP/3.9.248/samc21/include' '-I' 'C:/Users/simon/.mchp_packs/ARM/CMSIS/6.2.0/CMSIS/Core/Include' '-ffunction-sections' '-fdata-sections' '-fno-rtti' '-fno-exceptions' '-mlong-calls' '-Wall' '-Wextra' '-Wpedantic' '-v' '-MP' '-MMD' '-MF' 'build/default/debug/main.o.d' '-o' 'build/default/debug/main.o' '-D' 'XPRJ_default=default' '-mfloat-abi=soft' '-mlibarch=armv6s-m' '-march=armv6s-m'

BUILD SUCCESSFUL (total time: 688ms)
Loading symbols from C:/Users/simon/MPLABXProjects/test_linkers.X/dist/default/debug/test_linkers.X.debug.elf...
Loading code from C:/Users/simon/MPLABXProjects/test_linkers.X/dist/default/debug/test_linkers.X.debug.elf...
Program loaded with pack,SAMC21_DFP,3.9.248,Microchip
Loading completed
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18889
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #96 on: January 30, 2026, 09:00:17 am »
Same on the work computer. Now that the sram linker is removed the predicted RAM usage does not change by twice the change in stack allocation. So the stack was being counted twice.

My problem is that this is stock MPLABX. why is this happening?
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18889
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #97 on: January 30, 2026, 09:59:08 am »
I've got the original program back up and compiling and it compiles using 7kB of RAM with 2kB of stack. Previously it was overrunning the 16kB RAM allowance.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18889
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #98 on: January 30, 2026, 12:11:41 pm »
Well the program crashes to the dummy handler with IPSR at 31 which should correspond to interrupt 15 for CAN0
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18889
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: getting mplab XC32 to grasp that this is C++ not C
« Reply #99 on: January 30, 2026, 12:18:21 pm »
In the call stack right before the crash handler the last entry is <Signal Handler Called>: 0xFFFFFFF9

I am assuming nothing is there?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf