Does This Mean I'm Out of Device Memory

[Ground_Loop]

I have a project the compiles fine on a machine running MPLABX 5, but on another machine running MPLABX v6 I get the following when trying to compile:

build/default/production/main.o: Link Error: Could not allocate section .text, size = 6400 PC units, attributes = code
build/default/production/main.o: Link Error: Could not allocate section .const, size = 856 PC units, attributes = psv page
build/default/production/mcc_generated_files/I2C_EEPROMDrivers/i2c_eeprom_app.o: Link Error: Could not allocate section .text, size = 626 PC units, attributes = code
build/default/production/LCD_8bit.o: Link Error: Could not allocate section .text, size = 448 PC units, attributes = code
data_init: Link Error: Could not allocate section .dinit, size = 396 PC units, attributes = code keep
build/default/production/mcc_generated_files/i2c1.o: Link Error: Could not allocate section .text, size = 234 PC units, attributes = code
build/default/production/mcc_generated_files/i2c2.o: Link Error: Could not allocate section .text, size = 234 PC units, attributes = code
build/default/production/mcc_generated_files/spi1.o: Link Error: Could not allocate section .text, size = 190 PC units, attributes = code
build/default/production/mcc_generated_files/tmr2.o: Link Error: Could not allocate section .text, size = 110 PC units, attributes = code
build/default/production/mcc_generated_files/uart2.o: Link Error: Could not allocate section .text, size = 90 PC units, attributes = code
build/default/production/mcc_generated_files/tmr1.o: Link Error: Could not allocate section .text, size = 88 PC units, attributes = code
build/default/production/mcc_generated_files/tmr5.o: Link Error: Could not allocate section .text, size = 88 PC units, attributes = code
build/default/production/mcc_generated_files/tmr3.o: Link Error: Could not allocate section .text, size = 86 PC units, attributes = code
build/default/production/mcc_generated_files/interrupt_manager.o: Link Error: Could not allocate section .text, size = 72 PC units, attributes = code
build/default/production/mcc_generated_files/pin_manager.o: Link Error: Could not allocate section .text, size = 64 PC units, attributes = code
build/default/production/mcc_generated_files/clock.o: Link Error: Could not allocate section .text, size = 46 PC units, attributes = code
delay32.Meo: Link Error: Could not allocate section .init.delay32, size = 28 PC units, attributes = code
build/default/production/mcc_generated_files/system.o: Link Error: Could not allocate section .text, size = 24 PC units, attributes = code
build/default/production/mcc_generated_files/traps.o: Link Error: Could not allocate section .text, size = 14 PC units, attributes = code
build/default/production/LCD_8bit.o: Link Error: Could not allocate section .const, size = 12 PC units, attributes = psv page
build/default/production/mcc_generated_files/system.o: Link Error: Could not allocate section .text, size = 24 PC units, attributes = code
build/default/production/mcc_generated_files/traps.o: Link Error: Could not allocate section .text, size = 14 PC units, attributes = code
build/default/production/LCD_8bit.o: Link Error: Could not allocate section .const, size = 12 PC units, attributes = psv page
 Link Error: Could not allocate program memory
make[2]: *** [nbproject/Makefile-default.mk:327: dist/default/production/Water_Monitor_UI_New_Comm.X.production.hex] Error 255
make[1]: *** [nbproject/Makefile-default.mk:91: .build-conf] Error 2
make: *** [nbproject/Makefile-impl.mk:39: .build-impl] Error 2

BUILD FAILED (exit value 2, total time: 852ms)

On the machine that compiles successfully I am using optimization level 1 and the compiled code consumes 92% of available program memory and about half of available data memory.  The device I'm trying to compile to is a PIC24FV32KA302.  I'm using the same project properties on both machines.

[mikeselectricstuff]

This sort of issue should be a function of compiler  version, not the MPLABX version. You can have multiple compilers installed, so you should be able to compile under the previous compiler within MPLABX 6 if you have the older compiler installed.

[Ground_Loop]

This sort of issue should be a function of compiler  version, not the MPLABX version. You can have multiple compilers installed, so you should be able to compile under the previous compiler within MPLABX 6 if you have the older compiler installed.

I was afraid of that.  The older XC16 compilers available in the Microchip archive are indicated as Source Archives and I'm not sure how to get the version I need registered in MPLABX for Mac OS.

The source archives appear to be literally source code for the XC16 compiler.  Not sure how to compile into something useful to MPLABX.

[MikeK]

Are they both using the same C language mode?...C90 vs C99.

[DavidAlfa]

Yep. Open project settings, go to compiler optimizations and enable O2 (free) or Os(Pro).
That's probably the culprit.

[cv007]

The older XC16 compilers available in the Microchip archive are indicated as Source Archives and I'm not sure how to get the version I need

https://www.microchip.com/en-us/tools-resources/archives/mplab-ecosystem

Language Tools Archives, they have every version of XC16 available from v1.00, 5/3/12 and you may have to 'scroll' right 1..15 to find what you want.

[Ground_Loop]

The older XC16 compilers available in the Microchip archive are indicated as Source Archives and I'm not sure how to get the version I need

https://www.microchip.com/en-us/tools-resources/archives/mplab-ecosystem

Language Tools Archives, they have every version of XC16 available from v1.00, 5/3/12 and you may have to 'scroll' right 1..15 to find what you want.

Well, it almost worked.  I downloaded, installed and tried to compile, but it failed on bad CPU type.  My new Mac has M1 CPU.  Thanks for the link though.  It looks like I'll just need to hang on to the old Mac for a while.

[JPortici]

XC16 2.0 doesn't work as well as previous versions, internal changes added unnecessary bloat (the compiler forgot that it can do indirect addressing with an offset, and instead calculates the actual address every time. all pointers, including arrays, are affected)
Confirmed bug, still waiting for 2.10 to be released but they already skipped two release cycles this year.

I don't remember if 1.70 can work on Apple M1, i fear not, in which case tough luck.

[Ground_Loop]

I've tried O2 optimization to no avail.  I get the same results.  Anyway this is just a hobby for me and my older laptop still works, so for this particular project I'll just use the old one.  And I'm not moving up to a paid license.  uCs with more memory are not available in the series either.   Thanks all for the responses.

[woofy]

It was a hard lesson to learn, but I now include MPLABX and XC versions in the projects documentation.

[cv007]

And I'm not moving up to a paid license

This still works-
https://github.com/cv007/XC3216/blob/master/xc32xc16-info.txt

[JPortici]

I've tried O2 optimization to no avail.  I get the same results.  Anyway this is just a hobby for me and my older laptop still works, so for this particular project I'll just use the old one.  And I'm not moving up to a paid license.  uCs with more memory are not available in the series either.   Thanks all for the responses.

The problem in 2.00 is NOT in optimization, but in code generation.

[Ground_Loop]

I've tried O2 optimization to no avail.  I get the same results.  Anyway this is just a hobby for me and my older laptop still works, so for this particular project I'll just use the old one.  And I'm not moving up to a paid license.  uCs with more memory are not available in the series either.   Thanks all for the responses.

The problem in 2.00 is NOT in optimization, but in code generation.

Understood, but an earlier post suggestion was to try O2.

[DavidAlfa]

That's strange. If you used the same code in different compilers, the difference should be negligible.
If you used a different library, that's a completely different thing, stay with the same library version you were using ealier!
You can download any pack version under Tools/Packs...
Then open the project settings and choose which pack to use.
Better stay with v5.50, I tried v6.00 and had several issues.
Also try this.
If it's DIY, I can try to help if you send me the project.

About the O2 optimization. What you were using in MPLABX 5? Perhabs you werte running Os (Optimize for size).
In any case, the IDE won't change a thing in the code, that's entirely up to the compiler.

I'll tell you something you've heard a million times: If not broken, don't fix it!
Was wokring in v5? Then stay with v5 and enjoy

[JPortici]

Again, V2.00 has a problem in CODE GENERATION, not optimization.
the microchip 16bit architecture can deference a pointer with offset in a single instruction.
Pointer with offset can be a member of a pointer to struct, or when you pass an array to a function, because you pass the address of the first element and the compiler can't use the literal address.

Instead of using a single instruction the compiler uses two or three. see my thread over at the microchip forum where i posted code and generated assembly comparing all optimization levels.
https://www.microchip.com/forums/m1198055.aspx

FWIW, there could be other issues such as the new libc because the compiler is finally (hah) fully C99 compliant and there could be a bigger library. Also you may need to change the code and memory models, but usually they get carried over when you change compiler versions.. and with 32k flash you can't use large code model anyway. but the code generation problem was the bigger one for me, in the project i tested it it increase code size to about 15%. That's a lot, and i can't find a reason the compiler team didn't catch it, especially because (and i have to repeat it again because too many already blabbered about optimization levels) IT AFFECTS EVERY OPTIMIZATION LEVEL

[Ground_Loop]

That's strange. If you used the same code in different compilers, the difference should be negligible.
If you used a different library, that's a completely different thing, stay with the same library version you were using ealier!
You can download any pack version under Tools/Packs...
Then open the project settings and choose which pack to use.
Better stay with v5.50, I tried v6.00 and had several issues.
Also try this.
If it's DIY, I can try to help if you send me the project.

About the O2 optimization. What you were using in MPLABX 5? Perhabs you werte running Os (Optimize for size).
In any case, the IDE won't change a thing in the code, that's entirely up to the compiler.

I'll tell you something you've heard a million times: If not broken, don't fix it!
Was wokring in v5? Then stay with v5 and enjoy

Same library, same toolpak.  I've been through all the permutations.  I'm going with Portici's explanation.  Anyway, this M1 chip is a real headache, and for more than just uC stuff.

[DavidAlfa]

It worked nice before, you broke it when updating the compiler to v2.00... so simply use v1.70?
Otherwise what's the logic on using v2.00 just because it's newer (But breaks everything)?
Seems like a simple fix to me!

[Ground_Loop]

I didn't break anything. I have a new laptop that is not compatible with the older versions and apparently some newer versions. Other than this one case it works just fine. The 12 year old laptop is still functional, so if required I'll use that one.  Not sure how that point was not clear up until now.

[Ground_Loop]

Solved it...sort of.

I found another micro with nearly identical peripheral set, pinout, and four times the memory in the same package.  Odd though that one of the IO bits--PORTAbits.RA4--had no definition in the header file.  I sorted that out and added it myself, so all good.  The down side is that the new device is 3.3V instead of 5V, but that can be worked with.  Otherwise, the original code compiles fine with all the latest soft/firmware revs.

[mikerj]

Have you tried running the older tools through Wine?  It has supported running x86 executables on Arm based MACs for a while.

[Ground_Loop]

Have you tried running the older tools through Wine?  It has supported running x86 executables on Arm based MACs for a while.

I'm trying to stay away from Windows tools on this machine.  So far, everything I need is working.  If I really need to use Windows for something I have several other machines.