Problem using vTaskDelayUntil and vListRemove

Hi,
I tried to mout FreeRTOS V7.0.1 on a Fujitsu MB96F356RWB. The project is compiled using Softune (F2MC-16 Family SOFTUNE Workbench V30L35). I started from FreeRTOS released for MB96340. I created a new Softune project using start.asm working on my system. I slightly modief it to be as close as possible to the one contained in the release for MB96340. I added all the files needed except croutine.c and I modified FreeRTOSConfig.h to exclude co-routines.
I implemented memory model contained in heap_3.c (should be a wrapper for standard malloc and free). As first try, I created one task in main() with the following code:
#define CHA_VEH_STATE_MACHINE_TSK_TICK      ( (portTickType) (CHA_VEH_STATE_MACHINE_PERIOD_MS / portTICK_RATE_MS) )
void CHA_VEH_StateMachine(void* parParam){
    portTickType xLastWaitTime;

    for(;;){




        /* Wait until next execution */
        vTaskDelayUntil(&xLastWaitTime,CHA_VEH_STATE_MACHINE_TSK_TICK);
    }
}
The project was compiled and downloded into the micro, bur some problems raised. Micro’s Program Counter jumped to position 0x000000 and was impossible to continue execution or to take micro control via EUROScope (debugger). This problem does not happen without the call to vTaskDelayUntil. Moreover, the problem does not raise if I create another task with a low priority which is kept running as a fake background task. With an empirical method of cut code and try I found that the problem is related to the call to vListRemove, in particular to its first lines:
    pxItemToRemove->pxNext->pxPrevious = pxItemToRemove->pxPrevious;
    pxItemToRemove->pxPrevious->pxNext = pxItemToRemove->pxNext
;
Actually, I do not know deeply FreeRTOS implementation, so I can only make a guess of what is happenning, but I am scared to make some pointer to point to something that does not exist (the task is only one, so there is no next!)
In vListRemove I cannot see any check on this possibility. Anyhow, this is only my guess. Because it is not possible to take micro control using the debugger (it does not work) I do not know if my gess is correct or not. So, if someone found similar problem, please tell me how to make a workaround to avoid micro crash. Bye.

Problem using vTaskDelayUntil and vListRemove

For expediency, the linked lists have items at their ends that are always there.  That means you don’t have to check as you are always guaranteed to have one item in the list. Check that your start up code is performing the necessary initialisation of variables, including clearing the bss section to zero. Regards.

Problem using vTaskDelayUntil and vListRemove

Thank you very much for your help, richardbarry. I am sorry, but I was wrong about the descriptioon of the problem in the previous post . I say that because I found a way to get micro control: I have inserted a while(!Dummy) before the execution of any OS-related function.
This makes the micro stop execution until the variable Dummy is 0. When the micro is turned on and before EUROScope takes control, it remains stuck in the while(). I ran the code lots of time, and I understand that my problem raises when exiting the following function:
__nosavereg __interrupt void vPortYield( void )
{
    /* Save the context of the interrupted task. */
    portSAVE_CONTEXT();

    /* Switch to the highest priority task that is ready to run. */
    vTaskSwitchContext();

    /* Restore the context of the new task. */
    portRESTORE_CONTEXT();
}
the macros portSAVE_CONTEXT() and portRESTORE_CONTEXT() are directly written in assembly, whereas the function vPortYield() is compiled and a short header and tail are placed. Header and tail depends on how is defined the function call interface in the project properties. I am currently using “Stack argument passing”, which means that the header is simply the instruction
LINK #$00
whereas the tail is
UNLINK
The problem happens when executing ULINK, the assembly instruction before RETI. This instruction affects Stack Pointer (SP) and Register Word 3 (RW3) in this way: (SP) <- (RW3)
(RW3) <- ((SP))
(SP) <- (SP)+2 In particular, RW3 in the context of the new task in execution contains a value which cannot be used as SP because it points to 0 (i.e.: ((RW3))=0).
This makes me loose the control over the micro and makes the PC be stuck to 0. This problem happens at the first context swich, when the task in execution calls for the very first time the function vTaskDelayUntil. What should I check or do to solve this problem? Thank you very much.
Bye

Problem using vTaskDelayUntil and vListRemove

Header and tail depends on how is defined the function call interface in the project properties. I am currently using “Stack argument passing”,
Is that the same as the project shipped for the MB96340 located in the FreeRTOS/Demo/MB96340_Softune directory?
he macros portSAVE_CONTEXT() and portRESTORE_CONTEXT() are directly written in assembly, whereas the function vPortYield() is compiled and a short header and tail are placed.
The documentation page for this port says that the function you highlight will not work correctly if optimisation is set to 0 – and that if zero optimisation is required the function should be re-implemented in asm code.  Do you have optimisation set to 0? Regards.

Problem using vTaskDelayUntil and vListRemove

Hi,
both the options for argument passing (Stack) and for optimisation level (level 1) are the same in demo project and in mine. I am giong to check all the other options, but I need some time. I let you know. Thank you again for you help. Bye

Problem using vTaskDelayUntil and vListRemove

Hi,
I think I solved the problem using optimisation level 1 (as in demo project). Moreover also the otions you can set in the form which apperars pressing detatiled optimize button form must be equal. 1) The comntrol optimisation for pointer aliasing must be done.
2) The inline expansion must be done for functions below 127 lines.
3) The function vTaskIncrementTick and vTaskswitchcontext must be forced to be inlined. I check the part of code which crated the problem and I saw that now the LINK and UNLINK instructions are no more inserted when compiling the function vPortYeld(). Thanks again. Bye.