The PIC18F port in FreeRTOS has long had two bugs that make it unfit for reliable production use. One is a linker script which permits sections containing C variables to cross bank boundaries. The other is the built-in assumption that the .tmpdata and MATH_DATA sections won't change size, which they do often both as a project evolves and between compiler versions.

This patch, made against FreeRTOSV7.1.0, contains both of my fixes.

http://malsyned.net/files/patches/freertos-v7-mplab-pic18-heap-tmpdata-fix.patch

A complete write-up of the issues involved and how my patch fixes them can be read here:

http://malsyned.net/files/freertos-pic-port-notes-wrapped.txt

This patch also contains a small fix for the PIC18F demo projects because they do not compile cleanly since V7.0.0.

Since V7, FreeRTOS and C18 both define a header named "timers.h". The PIC18F ports.c includes "timers.h" from the Microchip libraries for the OpenTimer1 function and associated definitions. Because of this, the FreeRTOS PIC18F demos don't compile in FreeRTOS V7 as the Microchip "timers.h" is shadowed by the FreeRTOS header.

In order to make sure the demos compile, I have changed the order of the include paths in their Project Build Options to prioritize Microchip's headers above FreeRTOS's. This is sufficient to compile the demos, but in order to compile projects that use the FreeRTOS timers module a more complete solution will have to be devised.

Thank you for your input. I will take a look at your files.

[The PIC18 port has long been noted as, and de-emphasised because, it has these issues. I think the issues have been documented, but not changed in the main line code. This will change soon because of other developments that use this port, and the desire to add in a PIC18 extended mode demo. Generally though, the PIC18 is not a good architecture for a pre-emptive kernel]

Regards.

Thanks for taking a look at my code. I hope it proves useful.

PIC18 wasn't the ideal platform for implementing a FreeRTOS project, and I wouldn't have used it if we didn't already have an existing FreeRTOS project that needed to be ported to PIC18. That being said, for our application it wound up working well and reliably once these fixes were in place.

I have a small patch that makes the interrupt vector easier to extend without modifying port.c. If it has a shot at inclusion I'd be happy to upload that as well.

Yes I would be interested in that too. I would be grateful if you could post both pieces of code to the FreeRTOS Interactive site. There is a Microchip page here:
http://interactive.freertos.org/forums/104359-microchip

Regards.

http://malsyned.net/files/freertos-mplab-pic18-flexible-interrupts.patch

This patch adds a configuration define, configPORT_USER_ISR_VECTOR, that can be set to the name of a function that handles vectoring to non-OS interrupts.

This function (interrupts.c:vUserInterruptVector in the Demo projects) is limited in what instructions it can execute, since it cannot alter the values of any registers. As long as the pattern established in the Demo example is followed, this is an easy requirement to satisfy.

This patch is independent of my other, but doesn't quite apply cleanly on top of it. So I've also made a single patch file that combines both:

http://malsyned.net/files/freertos-v7-mplab-pic18-heap-tmpdata-fix-flexible-interrupts.patch

I'll post the combined patch to Interactive as well.

Posted to FreeRTOS Interactive: http://interactive.freertos.org/entries/21224772-pic18f-heap-and-context-fixes-modular-interrupt-handling