velososcooby wrote on Sunday, August 26, 2007:
Hello,
I’m getting an undefined handler on vPortStartFirstTask(). It happens when “SUBS PC, LR, #4” executes… I’ve checked and MCU is in supervisor mode. I’m using STR711FR0.
Can anyone help me?
Tks,
velososcooby
davedoors wrote on Monday, August 27, 2007:
Can you be more specific? You are going into a default interrupt handler, or you are going into the undefined processor mode?
In the former case you will have to determine the source of the interrupt. Which interrupts do you configure prior to starting the first task.
I have no experience of the latter case other than to know the undefined processor mode is something to do with interfacing coprocessors so if you go into this state something very bad has happened.
velososcooby wrote on Monday, August 27, 2007:
I’m going into the undefined processor mode.
I’m using FreeRTOS example and I didn’t configure other interrupt source than wdg, configured by freertos.
The tasks are created correctly but when restoring context of first task the MCU going into undefined mode.
SUBS PC, LR, #4 must jump for the first task and copy SPSR to CPSR, ok?
If I substitute that by SUB PC, LR, #4 it jumps for the task but stay in supervisor mode, don’t enable interrupts and executes the first task forever.
Should I try recover task CPSR without enable interrupts? It doesn’t resolve the problem but can show us if the it is wdg interrupt.
Tks
velososcooby wrote on Saturday, September 01, 2007:
The CPSR created for my task was setting THUMB bit and causing the undefined processor mode.
So, I change it by setting thumb bit to 0.
Tks
sotd wrote on Saturday, September 01, 2007:
That something was probably having "-D THUMB_INTERWORK" defined in your makefile.