PIC32MZ vApplicationStackOverflowHook

pic32rtos wrote on Tuesday, September 09, 2014:

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.

rtel wrote on Tuesday, September 09, 2014:

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.

pic32rtos wrote on Tuesday, September 09, 2014:

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

davedoors wrote on Tuesday, September 09, 2014:

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.

rtel wrote on Tuesday, September 09, 2014:

I’m trying to run the basic demo project,

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?

Regards.

pic32rtos wrote on Tuesday, September 09, 2014:

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.

pic32rtos wrote on Tuesday, September 09, 2014:

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.

rtel wrote on Tuesday, September 09, 2014:

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.

pic32rtos wrote on Tuesday, September 09, 2014:

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

tlafleur wrote on Tuesday, September 09, 2014:

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?

pic32rtos wrote on Monday, September 15, 2014:

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?

rtel wrote on Monday, September 15, 2014:

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.

pic32rtos wrote on Monday, September 15, 2014:

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).

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.

rtel wrote on Monday, September 15, 2014:

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.

pic32rtos wrote on Monday, September 15, 2014:

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.

Regards

pic32rtos wrote on Tuesday, September 16, 2014:

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

rtel wrote on Tuesday, September 16, 2014:

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.

pic32rtos wrote on Tuesday, September 16, 2014:

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)
...

Any idea about?
Regards.

rtel wrote on Tuesday, September 16, 2014:

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.

pic32rtos wrote on Wednesday, September 17, 2014:

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.