I have a set of working code for PIC18F2685 that was built with FreeRTOS v5.3.0. [I inherited it from someone who is no longer here. I've successfully made some fixes and modifications from time to time.]

A couple of times in the last year or two, I have attempted to move this project to a newer version of FreeRTOS. The effort generally fails, and to simply get work done, I revert to the old 5.3.0.

I'm only developing for one target [PIC18F development with MPLAB IDE and MPLAB c18 Lite], so I deleted all of the other ports from the 7.0.1 directories. Since there are only a few files, I moved the FreeRTOS source files to my "src" directory in MPLAB project, and I moved the include files to my "src\include" directory in the project. I changed the path in the #include for portmacro.h inside portable.h.

During the compile, I get a few warnings about typing. I crawled through the FreeRTOS source and I think the types are okay.

C:\$Projects\src\tasks.c:502:Warning [2066] type qualifier mismatch in assignment

C:\$Projects\src\serial.c:207:Warning [2074] location PRODH specified in the interrupt save list is redundant
C:\$Projects\src\serial.c:207:Warning [2074] location PRODL specified in the interrupt save list is redundant
C:\$Projects\src\serial.c:207:Warning [2074] location TABLAT specified in the interrupt save list is redundant
C:\$Projects\src\serial.c:207:Warning [2074] location .tmpdata specified in the interrupt save list is redundant
C:\$Projects\src\serial.c:234:Warning [2074] location PRODH specified in the interrupt save list is redundant
C:\$Projects\src\serial.c:234:Warning [2074] location PRODL specified in the interrupt save list is redundant
C:\$Projects\src\serial.c:234:Warning [2074] location TABLAT specified in the interrupt save list is redundant
C:\$Projects\src\serial.c:234:Warning [2074] location .tmpdata specified in the interrupt save list is redundant

C:\$Projects\src\list.c:74:Warning [2066] type qualifier mismatch in assignment
C:\$Projects\src\list.c:82:Warning [2066] type qualifier mismatch in assignment
C:\$Projects\src\list.c:83:Warning [2066] type qualifier mismatch in assignment
C:\$Projects\src\list.c:156:Warning [2066] type qualifier mismatch in assignment

The project compiles, programs, and runs my initializations prior to setting up the FreeRTOS setup [e.g. vPortInitialiseBlocks(...); xTaskCreate(...); and, vTaskStartScheduler()]. But the application does not run.

I've tried commenting out all of the CAN, RS232, and UI code, and left a simple "heartbeat_LED" task, but it does not go.

I would appreciate any hints.

I have done considerable C/C++ coding in my career; but, I am relatively new to Microchip and FreeRTOS.

PIC18 is not a good target for any pre emptive RTOS because of the horrid way it banks memory.

According to http://www.freertos.org/History.txt FreeRTOS V7.x is backward compatible with FreeRTOS V6.x and FreeRTOS V6.x is backward compatible with FreeRTOS V5.x. you have to go back as far as 4.x to find an incompatibility when an ISR safe queue function changed. So sorry, can't help. The theory is, if you are using the same project files, you should just need to copy the latest FreeRTOS code over the top of the old FreeRTOS code.

Have you tried updating the compiler?

The FreeRTOS site cautions that PIC18 is not a good target. So far it's worked okay, but I'm doing fairly simple and non-demanding tasks, and the compiler has been good about handling the memory addressing.

The problem boiled down to my unfamiliarity with setting up a new FreeRTOS project in MPLAB IDE for the C18 toolsuite.

I crawled through the source code with a diff tool and I noticed that an important MPLAB C18 header was include only if "MPLAB_C18_PORT" was defined but it did not seem to be defined in code. I loaded the old project and found it was defined in the compiler option settings. This got me one step nearer.

I laboriouly went through all of the MPLAB IDE project settings and configurations making screenshots of each tool/page/tab in the working project. Then I went through a new project in the same detail to compare to the old settings.

The problem was the output needed to be INHX8M. The default in the new project was INHX32.

I am building and running.

Now if I can just figure out how to set up control registers so I can use ISR to read CAN instead of polling the input buffer.
But that is another topic for another post...

Kind regards.
- -
Mark