Dear all,
I’m developing a system firmware for an engine ECU on SPC58EC microcontroller using FreeRTOS and SPC5Studio.
During the tests I worked on interrupt priority and in particular I tested the correct servicing order of interrupt according to the selected priority.
- I configure a periodic interrupt every 1ms, (vector 227) using the channel 1 of PIT interrupt timer and I assigned a priority of 8.
- I configure a software interrupt vector 0 of priority 63 (highest).
- In the periodic ISR I clear the interrupt flag (PIT_0.CH[1].TFLG.B.TIF=1) and I set the software interrupt flag (INTC_1.SSCIR[0].B.SET=1). After I simply call a very simple test function that just does simple calculations (additions or subtractions). In the software ISR I just clear the interrupt flag.
- What I have is the following: MCU enters in the first interrupt (priority 😎 after this interrupt is interrupted by higher priority software interrupt, after MCU comes back correctly to lower priority interrupt, calls the test function and after executing RFI (return from interrupt) I have an exception.
- Repeating the test without calling the test function the program does not crashes. I already checked the stack size in linker script file.
- In this test program RTOS is configured but is doing nothing.
- Repeating the test calling the test function but deleting freeRTOS component the programs works fine.
- Looking deeply at the structure of the firmware library I realize that the SAVE CONTEXT and the RESTORE CONTEXT of interrupt service routine is implemented in assembler buy function IVOR4 and is taken from Ivor.s if we don’t use FreeRTOS or from “portasm.s�? if we use FreeRTOS. Obviously the context switch is different if we have the operating system running (“portSAVE_CONTEXT�? and “portRESTORE_CONTEXT�? of “portasm.s�?). I suspect a bug in this file in IVOR4 function of “portasm.s�?.
- From the test seems that the stack pointer at the end of lower priority interrupt is corrupted and so the MCU cannot come back to the main program.
- The version of FreeRTOS component is 1.6.7.20210617094647
Someone has had the similar problem? Please help me.
Alessandro P.
