PIC32 Port Example

joeygo wrote on Thursday, November 24, 2011:

Has anyone successfully got the PIC32 example port going?

Thanks in advance

rtel wrote on Thursday, November 24, 2011:

Has anyone successfully got the PIC32 example port going?

Of course. 

Your post is very unhelpful.  If you are having a problem, it is better to describe the problem, so people can actually suggest a solution.  Otherwise you are devaluing this resource.

Please read the the FAQ


You can then choose to either post something helpful to yourself and other users, or not post.


joeygo wrote on Tuesday, November 29, 2011:

Thanks for your reply and confidence in the PIC32 port.

I downloaded the PIC32 port and MPLAB  IDE reported the port was written on the older v1.11 c32 PIC32 compiler.

There have been significant changes to the C32 complier as documented here http://ww1.microchip.com/downloads/en/DeviceDoc/MPLABC32_v2_01_README.html

Has the PIC32 port been tested with the “significant” changes in the C32 complier  now currently ver2.01?

Thanks in advance   Joeygo

joeygo wrote on Tuesday, November 29, 2011:

Sorry  and another question… Can / or has the PIC32 Port example been written for complier version independence as much as possible (since the C32 complier is improving in leaps and bounds)


rtel wrote on Tuesday, November 29, 2011:

The latest FreeRTOS version was tested with whatever the latest version of C32 was at the time it was released, which was V2. something.  Please just try it yourself, then come here for support it you have a problem.  There is no pre-sales support, as FreeRTOS is not for sale.

Can / or has the PIC32 Port example been written for complier version independence as much as possible

As much as possible, yes, but there are 14 tool chains supported, and tool chains change all the time.  There is no way of predicting what will happen in the future.  A few things have changed in the C32 compiler, normally I get pre-warning, but not always.  That is why users should report here when there is an issue, so it can be maintained.  If every user asked these questions before actually even trying the code, this forum would have millions of posts, and none of them would be answered because there would be no way of keeping up.


crosland wrote on Wednesday, November 30, 2011:

It works fine in 2.00 which is where the update to the underlying GNU tools was introduced. Changes to 2.01 look minor to me.

What exactly is the problem you see?

Andrew Crosland

marico wrote on Tuesday, January 17, 2012:

It’s never worked for me. I tried before (about one year ago) and I gave up. Now I try to make it work again with version 7.1.0 and I got the same poor results.
My test freertos app always fail with alignment exception. My source is very simple: just 2 tasks doing nothing (infinite while loop). I tried all possible heap_x implementation, same results. Exceptions always occur when calling gvTaskStartScheduler(), exception is  in vPortStartFirstTask  at .line:
  lw      s6,8(s5)
My toolchain: gcc version 3.4.4   Microchip MPLAB C Compiler for PIC32 MCUs v1.11-20100413


edwards3 wrote on Tuesday, January 17, 2012:

What did you use as a base for your project? There are a few PIC32 applications around that work with no problem if you have the same hardware that the application was written for. If you switch hardware you might have to change something, but you can use the same project as a start. Microchip even have an application note with some project files about using FreeRTOS with their free libraries, you could try those too.

marico wrote on Tuesday, January 17, 2012:

I use simple diy pic32 test board with uart1 connected to a PC (I use uart1 for dubbuging messages). My freertos app has two task, one task should write ‘A’ char to uart1 and task2 should write ‘B’ (both tasks do it in a infinite loop).
After initailizing the hardware (SYSTEMConfigPerformance,uart1,etc) I call:
xTaskCreate( prvTestTask1, ( const signed char * const ) “Tst1”,configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY, NULL );
xTaskCreate( prvTestTask2, ( const signed char * const ) “Tst2”, configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY, NULL );

and after one second after calling vTaskStartScheduler(); I got exception:
General Exception  bus error (load/store)  at a00010e4

And, of course, there is no life signs from task1 or task2 (even in that one second after vTaskStartScheduler call and exception occur).

Is there exist a simple pic32 freertos demo with only 2 task and hardware board independend? PIC32 demo included in freertos source is complex, huge and hard to understand (and focused only to a specified hardware and mplab). 
Till now i figured out, that maybe there is a problem with vT1InterruptHandler, which is never called. I rerouted T1 interrupt to tempoerary ISR to test it, and  T1 int.  works only when I remove  portDISABLE_INTERRUPTS(); from my code.
But without portDISABLE_INTERRUPTS(); I got other exception:
General Exception  bus error (load/store)  at 0
(looks liike a null pointer?)
Do I have to always portDISABLE_INTERRUPTS(); after INTEnableSystemMultiVectoredInt()?

marico wrote on Saturday, January 21, 2012:

OK, I figured out where the problem was, in the port.c file there is a variable with initial value:
volatile unsigned portBASE_TYPE uxInterruptNesting = 0x01;

for uknown reason my pic32mx-gcc won’t initialize variables declared out of functions scope, so  in  vPortStartFirstTask() call uxInterruptNesting was -1 (instead of 1). 

edwards3 wrote on Saturday, January 21, 2012:

Sounds like you are using a bum start up file. I would recommend fixing that so it sets up the C run time environment properly before getting too deep into your project because you don’t know how many variables have the wrong values.

erupter wrote on Friday, February 03, 2012:


Check this out, I used his example to run on my PIC32 ESK.

kn3chip wrote on Friday, February 10, 2012:

freeRTOS v.7.1.0 along with  c32 PIC32  v2.02 with MPLAB IDE v8.83 works fine on my PIC32 Starter kit . The three LEDs re blinking using the LED task. I have used the PIC32MX_MPLAB port and changed the LED port to PORTD since that port is used by starter kit for LEDs

kn3chip wrote on Monday, February 20, 2012:

One more update, when I tried to run the vAltStartComTestTasks() on  PIC32MX795F512(chiKITMAX32board ) , the board was hanging(no blink of port D LED. I have modified the UART2 ISR to send a blank char ‘E’, in the QUE empty condition as below.
With this change, the blink happens and the UART2 is sending characters. I have disabled the check tasks.
There is  a  statement in microchip that interrupt would get generated "immediately’ when the UART is enabled. The output from UAR2  is as given below the code snippet.

while( !( U2STAbits.UTXBF ) )
if( xQueueReceiveFromISR( xCharsForTx, &cChar, &xHigherPriorityTaskWoken ) == pdTRUE )
// Send the next character queued for Tx.
U2TXREG = cChar;
// U2TXREG = ‘A’; // test code
// Queue empty, nothing to send.
xTxHasEnded = pdTRUE;
U2TXREG = ‘E’;  //test code


rtel wrote on Monday, February 20, 2012:

Note that, if you are using the UART driver from the Explorer16 demo, it is written for a PIC32MX360F512 and will not work correctly on the 795 part (because the UART and/or interrupt controller implementation is different).  I can’t remember exactly what the changes needed are, but it has something to do with when the interrupt is cleared.  Try clearing the interrupt as the first action in the ISR.


rwwall wrote on Friday, September 21, 2012:

I recently upgraded to MPLAB 8.86 and I also downloaded the August 2012 source code.  The I now get the following warning:

Executing: “C:\Program Files\Microchip\MPLAB C32 Suite\bin\pic32-gcc.exe” -mprocessor=32MX795F512L -c -MMD -MF"./output\port_asm.d" -I"." -I"." -I"…\common\include" -I"…\…\source\portable\mplab\pic32mx" -I"…\…\source\include" -D__DEBUG -D__MPLAB_DEBUGGER_PK3=1 “…\…\Source\portable\MPLAB\PIC32MX\port_asm.S” -o"./output\port_asm.o" -I"…\…\Source\portable\MPLAB\PIC32MX" -I"." -Wa,-defsym=__DEBUG=1,-defsym=__MPLAB_DEBUGGER_PK3=1,-keep-locals,-gdwarf-2
…\…\Source\portable\MPLAB\PIC32MX\port_asm.S: Assembler messages:
…\…\Source\portable\MPLAB\PIC32MX\port_asm.S:72: Warning: Quoted section flags are deprecated, use attributes instead

I don’t get this warning when using MPLAB 8.76.  There  is no information on the internet that I can find that describes how to use attributes to eliminate this warning concerning depreciated code

The line of code marked is: .section .FreeRTOS, “ax”, @progbits

rtel wrote on Friday, September 21, 2012:

downloaded the August 2012 source code

I presume you mean the FreeRTOS source code.

The warnings are a result of changes made to the compiler.  FreeRTOS was updated to work with the latest compiler.  If you are using the latest FreeRTOS source code, and the latest XC32 compiler, then you should not get these warnings.