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.
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
So the project in the \FreeRTOS\Demo\PIC32MZ_MPLAB directory with mainCREATE_SIMPLE_BLINKY_DEMO_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?
So the project in the \FreeRTOS\Demo\PIC32MZ_MPLAB directory with mainCREATE_SIMPLE_BLINKY_DEMO_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.
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.
Ok, I will try to clear the question.
When the interrupt take place (vPortYeldISR in port_asm.S) the execution was in the “J 0x9D003FC0” (portTASK_FUNCTION in tasks.c).
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.
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 _CP0_STATUS (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.
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.
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.
...
/* Save the stack pointer to the task. */
la s7, pxCurrentTCB
lw s7, (s7)
sw s5, (s7)
...