Project sudden not compiling - SOLVED

[ricko_uk]

Hi,
I am using MPLAB with Hamrony V3, Harmony Configurator and freeRTOS (fully supported by harmony).

It was all working and then suddenly I started getting the error below that seems related to the makefile which I don't understand and it stopped compiling.

Any sugestions?

Many thanks

"C:\Program Files (x86)\Microchip\xc32\v2.30\bin\xc32-gcc.exe"   -mprocessor=32MZ1024EFG100  -o dist/default/production/OP60_RTOS.X.production.elf build/default/production/_ext/1360937237/panel_UI_control.o build/default/production/_ext/1360937237/app6.o build/default/production/_ext/1360937237/app7.o build/default/production/_ext/1360937237/app8.o build/default/production/_ext/1360937237/app9.o build/default/production/_ext/1360937237/Board_Setup.o build/default/production/_ext/1360937237/main.o build/default/production/_ext/1171490990/initialization.o build/default/production/_ext/1171490990/interrupts.o build/default/production/_ext/1171490990/interrupts_a.o build/default/production/_ext/1171490990/exceptions.o build/default/production/_ext/163028504/xc32_monitor.o build/default/production/_ext/60165520/plib_clk.o build/default/production/_ext/1865254177/plib_gpio.o build/default/production/_ext/1865200349/plib_evic.o build/default/production/_ext/158385033/drv_i2c.o build/default/production/_ext/1865480137/plib_ocmp3.o build/default/production/_ext/944882569/sys_debug.o build/default/production/_ext/101884895/sys_time.o build/default/production/_ext/513455433/plib_i2c2_master.o build/default/production/_ext/60181895/plib_tmr4.o build/default/production/_ext/1865657120/plib_uart1.o build/default/production/_ext/60181895/plib_tmr2.o build/default/production/_ext/1832805299/sys_console.o build/default/production/_ext/1832805299/sys_console_uart.o build/default/production/_ext/1171490990/freertos_hooks.o build/default/production/_ext/404212886/croutine.o build/default/production/_ext/404212886/list.o build/default/production/_ext/404212886/queue.o build/default/production/_ext/404212886/FreeRTOS_tasks.o build/default/production/_ext/404212886/timers.o build/default/production/_ext/404212886/event_groups.o build/default/production/_ext/404212886/stream_buffer.o build/default/production/_ext/1665200909/heap_1.o build/default/production/_ext/951553246/port.o build/default/production/_ext/951553246/port_asm.o build/default/production/_ext/1881668453/sys_int.o build/default/production/_ext/1529399856/osal_freertos.o build/default/production/_ext/1360937237/app_panel_io_exp.o build/default/production/_ext/1360937237/app_panel_exp_outputs.o build/default/production/_ext/1360937237/app_panel_exp_inputs.o build/default/production/_ext/1360937237/app_panel_exp_adc.o build/default/production/_ext/1360937237/app_printer.o build/default/production/_ext/1360937237/app5.o build/default/production/_ext/1171490990/tasks.o          -DXPRJ_default=default  -no-legacy-libc    -Wl,--defsym=__MPLAB_BUILD=1,--script="..\src\config\default\p32MZ1024EFG100.ld",--defsym=_min_heap_size=512,--gc-sections,--no-code-in-dinit,--no-dinit-in-serial-mem,-Map="dist/default/production/OP60_RTOS.X.production.map",--memorysummary,dist/default/production/memoryfile.xml -mdfp="C:/Program Files (x86)/Microchip/MPLABX/v5.30/packs/Microchip/PIC32MZ-EF_DFP/1.1.45"
nbproject/Makefile-default.mk:672: recipe for target 'dist/default/production/OP60_RTOS.X.production.hex' failed
make[2]: Leaving directory 'D:/Dropbox (TDL)/TDL Design/Rational/Firmware_OP60_RTOS/firmware/OP60_RTOS.X'
nbproject/Makefile-default.mk:91: recipe for target '.build-conf' failed
make[1]: Leaving directory 'D:/Dropbox (TDL)/TDL Design/Rational/Firmware_OP60_RTOS/firmware/OP60_RTOS.X'
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
build/default/production/_ext/1171490990/interrupts_a.o:D:\Dropbox (TDL)\TDL Design\Rational\Firmware_OP60_RTOS\firmware\OP60_RTOS.X/../src/config/default/interrupts_a.S:86: undefined reference to `OUTPUT_COMPARE_3_Handler'
build/default/production/_ext/1171490990/interrupts_a.o:D:\Dropbox (TDL)\TDL Design\Rational\Firmware_OP60_RTOS\firmware\OP60_RTOS.X/../src/config/default/interrupts_a.S:86: undefined reference to `OUTPUT_COMPARE_3_Handler'
collect2.exe: error: ld returned 255 exit status
make[2]: *** [dist/default/production/OP60_RTOS.X.production.hex] Error 255
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2

BUILD FAILED (exit value 2, total time: 24s)

[mon2]

Try a CLEAN before MAKE for this project.

[DrG]

It was all working and then suddenly I started getting the error below that seems related to the makefile which I don't understand and it stopped compiling.

You know that NEVER happens You know it is always "It was all working and then I DID SOMETHING and I started getting the errors below"

I'm seeing these as troubling...

nbproject/Makefile-default.mk:672: recipe for target 'dist/default/production/OP60_RTOS.X.production.hex' failed
make[2]: Leaving directory 'D:/Dropbox (TDL)/TDL Design/Rational/Firmware_OP60_RTOS/firmware/OP60_RTOS.X'

nbproject/Makefile-default.mk:91: recipe for target '.build-conf' failed
make[1]: Leaving directory 'D:/Dropbox (TDL)/TDL Design/Rational/Firmware_OP60_RTOS/firmware/OP60_RTOS.X'


These two are undefined references which you should be able to find and fix.

nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
build/default/production/_ext/1171490990/interrupts_a.o:D:\Dropbox (TDL)\TDL Design\Rational\Firmware_OP60_RTOS\firmware\OP60_RTOS.X/../src/config/default/interrupts_a.S:86: undefined reference to `OUTPUT_COMPARE_3_Handler'

build/default/production/_ext/1171490990/interrupts_a.o:D:\Dropbox (TDL)\TDL Design\Rational\Firmware_OP60_RTOS\firmware\OP60_RTOS.X/../src/config/default/interrupts_a.S:86: undefined reference to `OUTPUT_COMPARE_3_Handler'

This one might be fixed by declaring a heap size. Project Properties -> XC32-ld -> Heap Size - try entering 2048 or more or less.

collect2.exe: error: ld returned 255 exit status

By here, you are significantly funckled, but maybe something I have written could help...and might also make it worse.

make[2]: *** [dist/default/production/OP60_RTOS.X.production.hex] Error 255

make[1]: *** [.build-conf] Error 2

make: *** [.build-impl] Error 2

At this point, you have no choice but to have this added to your list of many disappointments - my wife keeps a list for me (j/k)

BUILD FAILED (exit value 2, total time: 24s)

[oliviasmithh900]

It was all working and then suddenly I started getting the error below that seems related to the makefile which I don't understand and it stopped compiling.

Any sugestions?

Always save a seperate copy of your working code to avoid such situations   

[brucehoult]

It was all working and then suddenly I started getting the error below that seems related to the makefile which I don't understand and it stopped compiling.

Any sugestions?

99.99% chance, it stopped working because you changed something. Reverse that change and it will work again.

Maybe you changed more than one thing. Reverse them all, and try one at a time to see which made it stop working. Or try half. If that half works then try half of the rest. If the first half doesn't work then try half of *it*.

If you don't know what changes you made then you just learned why programmers use source code control systems such as git. git lets you save the most recent changes to your project on a regular basis, see what you've changed since last time you saved changes, apply or undo changes individually or in groups, share sets of changes with other people etc etc.

[voltsandjolts]

make[2]: Leaving directory 'D:/Dropbox (TDL)/TDL Design/Rational/Firmware_OP60_RTOS/firmware/OP60_RTOS.X'
nbproject/Makefile-default.mk:91: recipe for target '.build-conf' failed
make[1]: Leaving directory 'D:/Dropbox (TDL)/TDL Design/Rational/Firmware_OP60_RTOS/firmware/OP60_RTOS.X'

Hmmm, are you building in a dropbox directory?
I would try building elsewhere, dropbox daemon maybe doesn't play nice with MPLABX.

[SiliconWizard]

First thing would be to learn how to read compilation errors, otherwise you'll choke at the first error you'll encounter no matter where it comes from.

You can see that the problem is a link issue: "undefined reference to `OUTPUT_COMPARE_3_Handler'", apparently referenced in the RTOS sources (in file: 'interrupts_a.S'). Are you sure you didn't update this RTOS? Obviously something changed.

Start looking for this symbol in the source tree to figure out what could be wrong. I know nothing about this RTOS but the above handler function should ring a bell to anyone using it I guess? Is this maybe a user-defined function that you somehow commented out? Or maybe you enabled OC3 in some way and forgot to define the corresponding handler?

[ozcar]

It was all working and then suddenly I started getting the error below that seems related to the makefile which I don't understand and it stopped compiling.

Any sugestions?

99.99% chance, it stopped working because you changed something. Reverse that change and it will work again.

Maybe you changed more than one thing. Reverse them all, and try one at a time to see which made it stop working. Or try half. If that half works then try half of the rest. If the first half doesn't work then try half of *it*.

If you don't know what changes you made then you just learned why programmers use source code control systems such as git. git lets you save the most recent changes to your project on a regular basis, see what you've changed since last time you saved changes, apply or undo changes individually or in groups, share sets of changes with other people etc etc.

These days there is usually a non-zero probability that some #%! piece of software that you are dependent on has decided to update itself. There is also a non-zero probability that there is no way to turn off the auto-update feature, and an alarmingly high probability that even if the automatic update can be turned off, the setting to do this will be hidden some place that you are least likely to find it.

[brucehoult]

It was all working and then suddenly I started getting the error below that seems related to the makefile which I don't understand and it stopped compiling.

Any sugestions?

99.99% chance, it stopped working because you changed something. Reverse that change and it will work again.

Maybe you changed more than one thing. Reverse them all, and try one at a time to see which made it stop working. Or try half. If that half works then try half of the rest. If the first half doesn't work then try half of *it*.

If you don't know what changes you made then you just learned why programmers use source code control systems such as git. git lets you save the most recent changes to your project on a regular basis, see what you've changed since last time you saved changes, apply or undo changes individually or in groups, share sets of changes with other people etc etc.

These days there is usually a non-zero probability that some #%! piece of software that you are dependent on has decided to update itself. There is also a non-zero probability that there is no way to turn off the auto-update feature, and an alarmingly high probability that even if the automatic update can be turned off, the setting to do this will be hidden some place that you are least likely to find it.

This is why I do almost all my programming on Ubuntu LTS, and allow it to run the software updater only infrequently and when I'm prepared for that.

In projects that ship to other people to use, it's important to be able to exactly reproduce any given version of the software later. Everything that a project depends on -- including gcc and libc -- should have the exact version number recorded and preferably either include it directly in your source code tree or else use a git submodule to reference a specific version. Update dependencies when you are prepared to handle any breakage, and be able to roll back if you find breakage you can't fix.

Of course small personal projects don't go to the same extremes, and Windows and MacOS provide less control than Linux, but even there it's a good idea to install your own versions of toolchains and important libraries rather than using the OS vendor-supplied ones.

[DavidAlfa]

I would search where the OUTPUT_COMPARE_3_Handler is used, and go backwards.
The good thing about eclipse-based IDEs is the code assist functions. You can click on the offending variable / handler / whatever and go to its declaration quickly.
Clearly, either harmony isn't generating the code for it, or you forget something... maybe a missing include, or not declaring something as extern to allow external code accessing it.

I remember the days of the old MLAB IDE, no code assist, no libraries, no wizards.... just man vs registers!
Developing was way harder and slower, but you didn't ran into those unexplainable problems easily, since you had designed every line of code 

[harerod]

Hi ricko_uk, sorry to read about your problems. If possible, would you mind changing the topic to something containing "MPLAB"? There might be some of us, who are not that much into MPLAB at the moment (for the last couple of decades or so, in my case). Much obliged.

[Siwastaja]

I remember the days of the old MLAB IDE, no code assist, no libraries, no wizards.... just man vs registers!
Developing was way harder and slower,

No, not really. It was, and it still is easier and quicker, at least in the long run, especially if quality and reliability is of any value, not to even speak about the ability to do the project successfully at all.

It's complete fallacy that you "need" to follow the modern pipe dreams. Many of us still do it the "old" way not because old is better (of course not; we do use the bleeding edge modern microcontrollers!), but because it works, and the trendy alternatives generally do not work very well, or are very costly in wasted time, human resources, stretched timelines, increased need for support of delivered products, not to even mention product recalls.

A typical bare-metal configuration of most single peripherals on a modern complex Cortex-M7 device is still like 5 lines of code. Through library or autogeneration, that tends to bloat into 50 lines of untraceable and unmodifiable boilerplate which rarely offers actual hardware abstraction, real portability, or any other claimed benefit.

[DavidAlfa]

Was it? Maybe with a simple pic16 device.
But setting up a pic32, huh, it took a lot more.
I also prefer total control, but a HAL makes the development much faster.
Just try doing a SPI DMA... You will need a while. There's a lot that needs setup.
The HAL , although adds some bloat, makes it a breeze.
These days where you counted the assembly instructions to ensure it was fast enough are pretty much gone

[Siwastaja]

You clearly haven't tried, just assuming. I don't blame you; you are repeating something everybody repeats, it's the easiest way to "be right" in a popularity contest.

On STM32, including the flagship models, setting up SPI with DMA is 10 lines-of-code total. I'm sure it's equally easy on PIC32 although can't be sure because haven't used one.

Enable clock to SPI and DMA.
Set up SPI config registers, exactly as in PIC or AVR.
Set SPI data register address to DMA. Set memory address to DMA. Set number of data register. Choose the SPI peripheral as a source for the DMA and enable the DMA channel.

Have done this gazillion of times and do it all the time. First time ever took maybe two hours. Not more than first-timing any peripheral on AVR.

Incomparable to simple 8-bit PIC or AVR because they have no DMA, but in any case, shorter than SPI init + inthandler doing the same as the DMA.

Sure, STM32 SPI has a bunch of traps which sometimes kill your workflow but HAL does not solve them, so you need to understand the low level anyway to be able to cope in such situations.

Also you never counted assembly instructions on peripheral init.

And I currently do have a project on STM32H7 where I do count assembly instructions.

[DavidAlfa]

Nah, you only count them in tight applications, like interrupts, critical IO timing...
Anyways, the flash is slower than the stm32 cpu speed, it's hard to know when it will miss the cache and fetch new flash data.
Not like the older MCUs where all worked at core clock.

I totally understand your point, but, I don't have the same patience lately 

[SiliconWizard]

You clearly haven't tried, just assuming. I don't blame you; you are repeating something everybody repeats, it's the easiest way to "be right" in a popularity contest.

On STM32, including the flagship models, setting up SPI with DMA is 10 lines-of-code total. I'm sure it's equally easy on PIC32 although can't be sure because haven't used one.

Well, back when I was using PIC32 MCUs, I never used the peripheral library/Harmony. And yes, setting up DMA transfers was pretty easy AFAIR. I even liked the PIC32 DMA controller, it was simple and flexible. And yes only required a few lines of code to set up. The only thing you had to be aware of is address translation, as, IIRC, addresses for the DMA source and destination required address translation, which was just a matter of using the right macro, which was provided in the support header files. Another pitfall when you were just starting with the PIC32 (MX in my case) is that it would have very poor performance until you enabled caches, and you had to figure out how to do that when you were going bare metal.

Actually, Microchip MCUs, including the PIC32, were much easier to work with directly bare metal than many ARM-based MCUs, with often more complex peripherals and poor documentation.
But that's still also doable. STM32 come with a HAL that many don't like, but it comes with full source code, so you can always browse the source code to complement the documentation when in doubt.

[DavidAlfa]

I agree. Microchip ecosystem is way more defined.
Back then there weren't cheap LCD modules, I remember using Nokia N82 LCD (MC2PA8201) with a PIC32MX.
Another problem was sourcing the 0.5mm pitch Hirose connector for the LCD!
It was impossible to use PMP and DMA because of... I don't remember. I think was a control signal issue...

Althought it also had some funny silicon erratas, no longer funny after 2 days of random crashes, tearing your hair apart!

[ricko_uk]

Thank you all for the feedback!!

A warning coming from Microchip tech support "off the record"...: DO NOT USE MPLAB GIT INTERFACE because it is known to not work correctly. Apparently because it is based on Netbeans 8.2 which is quite old and not supported anymore.

The issue was a Harmony update. I was using an old version of Harmony (not using the newer .yml files) and when updated it gave the confirmation of successful update but it turned out that in the update some of the MHC files disappeared.

Then there were issues with git from MPLAB which for some reason did not see some files (on the local machine) but started working when used other git clients.

Thank you again as always for all feedback and help.