Hi to all, I’m trying to run FreeRTOS on PIC32MZ2048ECM144 microcontroller without success. With only idle task the system run, but when I insert a task (simple task) I get an application stack overflow. Do you have any idea about? Michele M.

Unfortunately you have not provided enough information to even start to answer your question. Please start here: http://www.freertos.org/FAQ-how-to-use-the-FreeRTOS-support-forum.html Regards.

I will give you more information. I’m using MPLAB X IDE, with XC32 v1.33 compiler. The FreeRTOS version is V8.1.2. I’m trying to run the basic demo project, but I get general exception handle (DBE error). The code run on PIC32MZ2048ECM144. Thank you

Did you already try increasing the size of the stack you allocate to the task? It is one of the parameters to the xTaskCreate() function.

I’m trying to run the basic demo project,

So the project in the FreeRTOSDemoPIC32MZMPLAB directory with mainCREATESIMPLEBLINKYDEMO_ONLY set to 0?

but I get general exception handle (DBE error).

Did you make any edits to the code, or run it exactly as distributed?

The code run on PIC32MZ2048ECM144.

I just looked at the project and it looks like it is already configured to run on that chip so no modifications should be required. Are you running it on a Microchip starter kit, or on different hardware? Regards.

So the project in the FreeRTOSDemoPIC32MZMPLAB directory with mainCREATESIMPLEBLINKYDEMO_ONLY set to 0? Yes, it’s set to 0. Did you make any edits to the code, or run it exactly as distributed? No modifications were reported. I just looked at the project and it looks like it is already configured to run on that chip so no modifications should be required. Are you running it on a Microchip starter kit, or on different hardware? I’m using software simulator with FreeRTOS plug-in.

Did you already try increasing the size of the stack you allocate to the task? It is one of the parameters to the xTaskCreate() function. *Increasing the size of the stack doesn’t change anything.

I’m using software simulator with FreeRTOS plug-in.

That is your problem then. I just tried a clean V8.1.2 project on the real hardware and it runs with no problems. Unfortunately as a general rule we are unable to provide support for running FreeRTOS on simulators. Regards.

Maybe there are problem on MPLAB X IDE/Harmony Simulator. Thank you. Regards, Michele

I run ver 8.0.1, withe the demo code just fine on the pic32mz. Have tested with A3, A4 and A5 version of chip. Compiler 1.31 and 1.33. So, did you make ANY changes to the demo code? Are you running with Microchip demo board?

By looking at port_asm.S execution, I have noted eret instruction during jump execution in tasks.c [prvCheckTasksWaitingTermination();]. MIPS instruction manual report this: Description: ERET clears execution and instruction hazards, conditionally restores SRSCtlCSS from SRSCtlPSS in a Release 2 implementation, and returns to the interrupted instruction at the completion of interrupt, exception, or error processing. ERET does not execute the next instruction (i.e., it has no delay slot). Restrictions: The operation of the processor is UNDEFINED if an ERET is executed in the delay slot of a branch or jump instruction. An ERET placed between an LL and SC instruction will always cause the SC to fail. ERET implements a software barrier that resolves all execution and instruction hazards created by Coprocessor 0 state changes (for Release 2 implementations, refer to the SYNCI instruction for additional information on resolving instruction hazards created by writing the instruction stream). The effects of this barrier are seen starting with the instruction fetch and decode of the instruction at the PC to which the ERET returns. In a Release 2 implementation, ERET does not restore SRSCtlCSS from SRSCtlPSS if StatusBEV = 1, or if StatusERL =1 because any exception that sets StatusERL to 1 (Reset, Soft Reset, NMI, or cache error) does not save SRSCtlCSS in SRSCtlPSS. If software sets StatusERL to 1, it must be aware of the operation of an ERET that may be subsequently executed. Maybe is this the cause of the exception generation?

Thank you for your post – but I’m afraid I do not understand the point you are making. Can you please clearly state which eret you are referring to and which restrictions in the section of the manual you quote you think is being broken. I can only find one eret in that assembly file, and its use appears correct to me. Regards.

Ok, I will try to clear the question. When the interrupt take place (vPortYeldISR in portasm.S) the execution was in the “J 0x9D003FC0” (portTASKFUNCTION in tasks.c). JAL prvCheckTasksWaitingTermination NOP J 0x9D003FC0 NOP MIPS manual says “The operation of the processor is UNDEFINED if an ERET is executed in the delay slot of a branch or jump instruction.” How do you interpret this sentence? Thank you. Regards.

The branch delay slots are where the NOPs are in your previous post. So I would interpret the sentence to mean the behaviour was undefined if you replaced one of the NOPs with an ERET. Regards.

Maybe I found the error in the MPLAB X simulator. As you can see from the attached figure, the value in the 0x80000470 should be the CP0STATUS (i.e. k1=0x01000003), but the value stored in the simulator is 0x9D002098. This value, when it will be restored later, generate a general exception. Regards

Is it possible to have a stack allocation with negative value? Regards, Michele M.

Either something has corrupted (written over) the task control block for the idle task or the viewer you are using is not showing the values correctly. Regards.

I can’t understand what’s going on “vPortYieldISR” because when the program enter in this routine the stack point value is stored in “s5” register. Then this value overwrite the pxCurrentTCB->pxTopOfStack with a value different than the one created at the beginning of the task allocation. This appens for both user task and idle task. [code] … /* Save the stack pointer to the task. */ la s7, pxCurrentTCB lw s7, (s7) sw s5, (s7) … [/code] Any idea about? Regards.

As already mentioned, I’m afraid we cannot provide support for use with simulators – only on real hardware (where the code is known to run). Regards.

Thank you for your support, but my firmware must run on a custom board and it doesn’t run. YOu can close this thread. Regards.