All,

I have an explorer16 with the PIC32MX360F512L PIM and the 7.0.2 and 7.1.0 FreeRTOS demos hang after Pass 6 is displayed. Actually, it would seem that task switching has stopped and the last task, GenQ or tsk2 is left running. I believe that the code in the exception handler is also executing.

PIC24 FreeRTOS demos work fine on the board. My objective is to get Microchip TCPIP demo on FreeRTOS (update of AN1264). I have backed down to verifying that the demos work and to my surprise, I am not able to get past 10 seconds running.

Microchip TCPIP demo app with no RTOS runs fine.

Other detail:
MPLAB 8.83
C30 or C32 compilers (recent versions 3.30 or 2.02 respectively)
ICD3

Thanks,
Duncan

I'm not aware of any issues with that demo. I tried it myself fairly recently when the code was updated for V2 of the compiler.

You make reference to an exception handler - do you mean the tick handler? If so, are you able to put a break point in the tick handler to see which task it is selecting, and what happens when it returns?

Regards.

I completed some work on the PIC24 port and that is fine. I am coming back to this port now.

After several seconds (6-10), either the Tst1 or Tst2 tasks are running and do not yield. The system report looks appropriate with the correct ID of the current TCB as Tst1 or Tst2, scheduler is running with the top priority ready 4 (the check task). There is no switching but the tick timer continues and it does look like the Tst1 or 2 is progressing as it stops in different places.

All tasks are ready except:
ComRx = Blocked
Suspended =
MuMED
MuHigh
PeekH1
PeekH2
PeekM
LCD

Thanks,
Duncan

Update:
Commenting out vStartInterruptQueueTasks(); in main unblocks the rest of the demo. This is complicated stress testing and since you had it working, I am not sure where my problem lies for out of the box installation.. For clear reasons, I get Blck time and Int queue errors reported.

I am using MPLAB X v1.1 now but this was the same result back in Feb on MPLAB 8.xx

It looks like the scheduler stops but I can not troubleshoot any deeper. I have tried to change stack and heap allocations but I can not budge much and have anything run. The stop can happen after 5k - 15k ticks so this is not a base configuration.

Could this be related to the CPU's use of shadow registers. The newer PIC32 CPU's require an extra #pragma

#pragma config FSRSSEL = PRIORITY_7

This says interrupt priority 7 should use the shadow registers - in which case you should just avoid using interrupt priority 7. The older CPU's don't use the shadow registers, and therefore don't need this pragma.

Regards.

Richard,

I should have mentioned that I tried. That PIC32 does not have FSRSSEL defined and causes a compiler error. I'll look at shadow registers in another form.

I am coming up on 40k pass reports at 2 second intervals without the interrupt task running. I get 6-8 cycles of pass with that task loaded.

I have reviewed the interrupt section and the CPU sections but I can not find out what could be changing after thousands of appropriate switches. Shadow registers seem to be implemented by default but I don't think that is suddenly getting in the way.

Also, this is the OOTB demo in the Explorer 16 with the PIC32MX360F512L. I am really stuck here since you clearly had it working at release time. The compiler release is C32 v2.02 and I know you may have tried an earlier version.

Other data:
Timer T2,T3,T4, and T5 (used as tick timer) are all getting serviced after switching stops. I notice that the ComTX task stops and that lets the ComRX task stay blocked.

Thanks

I will set the code running here and leave it for a day or two to see if I can replicate the issue.

Regards.

I will be trying a port to the new wireless comm demo board http://ww1.microchip.com/downloads/en/DeviceDoc/52060A.pdf
It uses a later model chip PIC32MX695F512H. The product will not arrive until next week.

I am having *precisely* the same issue. On the PIC32MX795F512L part, results are a little different, but an issue (possibly the same) still exists when running the demo out of the box on the (on 2 different boards). I've also tried 2 different PIMs of the 360 part on the Exp16. I have also tried the legacy libc, (I've had other issues with the new one in the past), but exactly the same thing C32 v2.02a. For the record I am using MPLAB 8.84 on Win7 Pro 64bit and C32 v2.02a.

I am able to run the 7.1.0 demo just fine on C32 v1.10B, which is the only other version I seem to have around. Richard: can you try running the stock demo on v2.02a? Especially with MPLAB X replacing MPLAB 8, and only newer C32 versions supporting MPLAB X, it would seem important to the future of FreeRTOS on PIC32 that issues with new C32 versions be addressed. Unfortunately, Microchip seems to have broken some things with their newer versions of C32 (more than just the new libc, which breaks several other projects I'm working on).

This appears to be related to the compiler upgrade, and is being looked at now. In fact, it is delaying the next FreeRTOS release, which is otherwise ready. The most likely outcome of this is an upgrade to provide an MPLAB X project in place of the MPLAB 8 one, and an XC32 configuration in place of the C32 V2 one.

Regards.

If anybody is still reading this thread....

After three days of debugging, this problem seems related to the different way the lines of C code that clear timer interrupts in the interrupt nesting test are converted into asm code between the compiler versions. Both lines are in file FreeRTOS/Demo/PIC32MX_MPLAB/IntQueueTimer.c:

Line 113: IFS0bits.T3IF = 0;

Line 120: IFS0bits.T4IF = 0;

The lines can be replaced with:

Line 113: IFS0CLR = _IFS0_T3IF_MASK;

and

Line 120: IFS0CLR = _IFS0_T4IF_MASK;


Let me know if this fixes it for you.

Regards.

Hi Richard,
I also had this issue with an explorer16 and a PIC32MX360F512L PIM.
Works now very well with your modification. Thank you very much.

Thank-you very much Richard!

Confirmed working on MPLAB X v1.1 as well. Thank you for solving this problem.

FreeRTOS V7.1.1 contains an updated demo, with more and different functionality. It also corrects the problem with the library calls. See the documentation page here (yes, I know there is a spelling mistake in the URL!):

http://www.freertos.org/port_PIC32_MIPS_MK4.html

Regards