Hi, I tried to use the demo application of FreeRTOS for PIC24 and I couldn’t get it worked. I am using the Explorer 16 board with the PIC24FJ128GA010 PIM. I think this is the scenario used in the demo application. The difference is that I am using the MPLAB version 8.10 & the compiler C30 version 3.10. I can compile the whole project without errors, programming the board, starting the application and then nothing happens (no leds activity, no LCD messages and no UART activity). Debugging the application with ICD2 I see that the application is arriving at the following point (program stack): main.c vTaskStartScheduler() Line 181 tasks.c xPortStartScheduler() Line 1051 port.c asm volatile ( "return" ) Line 296 inside xPortStartScheduler function After this, it seems target continues working (I can do some "step into" instructions and program counters changes) but after some of these steps, the program restarts. Any idea of what can happen? Jaume
I have just downloaded the same compiler version and can confirm that I get the same problem. I can get simple tasks to execute ok, but the entire demo will not run. I will need to investigate further to determine the cause. Regards.
I will also investigate about that. If I could get any advance, I will post it. regards
The first thing I found is that the -fomit-frame-pointer option no longer appears to omit the frame pointer. I’m not sure exactly why that would matter, but moved the vPortYield() function to asm code from the existing C code implementation. This seemed to fix most things other than the serial port interrupt. The serial port interrupt is crashing because the frame pointer saved to the stack by the LNK instruction is overwritten by a local variable that is allocated the same position on the stack. This in turn means the frame pointer that is restored at the end of the ISR is incorrect, and the interrupted function then crashes when it attempts to run its epilogue code. I’m still looking at this to see if it is something in the kernel code or compiler that is causing this. Although it would thus far seem to be in the compiler I would like to make triple sure before I place the blame any where else! Regards.
I was successful at using C30 3.10 and FreeRTOS 5.0.0 with -O3 optimization and ONLY module port.c having -fomit-frame-pointer. So, this worked as far as i can tell. Specifically I used: C30 gcc settings Project: Use Alternate: -O3 -g -Wall -Wwrite-strings -fverbose-asm -dp -save-temps -mconst-in-code -mlarge-data -merrata=exch port.c: Use Alternate: -O3 -g -Wall -Wwrite-strings -fverbose-asm -dp -save-temps -mconst-in-code -mlarge-data -fomit-frame-pointer -merrata=exch Today I loaded FreeRTOS 5.0.2 and did the same thing with C30 3.10. This doesn’t run correctly in that it does a reset as others have reported. I have not tracked back to see what is wrong. So, this same problem exists on C30 3.10 as is being reported on C30 3.10b BOTH with FreeRTOS 5.0.2 rich
I think the complier is mis-optimizing some pieces of the code. I found I needed to use low levels of optimization to get things to work. The generated object code looked wrong, but I haven’t had time to dig into it in more detail.
There is definitely a code generation problem with the 3.10b compiler – I have had this confirmed and a solution should not be far away. In the mean time I have a workaround whereby I have moved the portYIELD() function to an assembly file (from its current C implementation). This makes the code work provided no optimisation is used. I think I will actually keep the code in this form for the next release as it has two other benefits: 1) The -fomit-frame-pointer options is no longer required as the prologue and epilogue code is now fixed in the asm file. 2) It uses less stack space. If you want a copy of the new .asm file then send me an email to r _dot_ barry *at* freertos.org. Regards.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.