This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LS1224: Bug report: Nested MPU call in the TI FreeRTOS port will raise an exception

Part Number: TMS570LS1224
Other Parts Discussed in Thread: HALCOGEN

Hi,

I think I found a bug in the HALcoGEN generated FreeRTOS code.

The problem comes from the implementation of the xPortRaisePrivilege function.
While the FreeRTOS kernel expects this function to return either 0 or 1, the TI implementation will return 0 or 15.

This small difference in API is affecting the boolean logic of the MPU stack.
For example, the vPortResetPrivilege won't work properly causing a critical memory access exception. 

void vPortResetPrivilege( BaseType_t xRunningPrivileged )
{
	if( xRunningPrivileged != pdTRUE )
	{
	    portSWITCH_TO_USER_MODE();
	}
}

If you want more information about how I found this issue and how it's impacting the safety, I have talked more about it with the FreeRTOS kernel developer here.


More detail on the problematic function 

This function is declared in the portmacro.h file.

#pragma SWI_ALIAS(xPortRaisePrivilege, 1);
extern BaseType_t xPortRaisePrivilege( void );


Has you can see below, the implementation of xPortRaisePrivilege return value will either be 0 or 15 by masking the SPSR ARM register.

;-------------------------------------------------------------------------------
; swiRaisePrivilege

; Must return zero in R0 if caller was in user mode
        .asmfunc
swiRaisePrivilege
        mrs     r12, spsr
        ands    r0, r12, #0x0F      ; return value
        orreq   r12, r12, #0x1F
        msreq   spsr_c, r12
        bx      r14
        .endasmfunc

Regards,
Gabriel