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