Data abort exception problem in uxListRemove() function.

Kernel
1

mongma wrote on Monday, February 19, 2018:

Hello.

I have a problem about exception.
I am trying to debug but it’s difficult to me.
I searched about this problem. And I found similar question.
https://www.freertos.org/FreeRTOS_Support_Forum_Archive/August_2014/freertos_uxListRemove_results_in_address_exception_20cf7379j.html
But I couldn’t get information i want.

I’m using FreeRTOS v9.0.0 on CortexA7.
RAM address starts at 0xF1000000
There are 7 tasks and i use interrupt.
configMAX_API_CALL_INTERRUPT_PRIORITY is 10.

I use xEventGroupSetBits(), xEventGroupSetBitsFromISR(), xEventGroupWaitBits() repeatedly.
It’s working fine. But at any moment data abort exception occurs in uxListRemove().

In uxListRemove(), pxList is set to NULL because pxItemToRemove->pvContainer is NULL.
Please refer to the below function.

UBaseTypet uxListRemove( ListItemt const pxItemToRemove )
{
/ The list item knows which list it is in. Obtain the list from the list
item. /
Listt const pxList = ( Listt ) pxItemToRemove->pvContainer;

It is dereferenced in below statements.

*/ Make sure the index is left pointing to a valid item. /
if( pxList->pxIndex == pxItemToRemove )
{
pxList->pxIndex = pxItemToRemove->pxPrevious;

The value of ListItem_t pxItemToRemove immediately before the exception is:

xItemValue == 364074
pxNext == 0xF10093DC (a valid RAM address)
pxPrevious ==0xF1007DAC
pvOwner == 0xF1009440
pvContainer == 0

This is callstack when pxItemToRemove->pvContainer is NULL.
xEventGroupWaitBits() -> vTaskPlaceOnUnorderedEventList() -> prvAddCurrentTaskToDelayedList() -> uxListRemove()

I don’t know why pxItemToRemove->pvContainer is NULL in uxListRemove()?
Could you advice to me about this problem?

Thank you very much.

2

mongma wrote on Tuesday, February 20, 2018:

I use also configASSERT().
I think this is not invalid interrupt priority problem. Because vPortValidateInterruptPriority() is passed successfully.

3

rtel wrote on Tuesday, February 20, 2018:

What should the value of the offending variable be? Could it be that it has simply been overwritten (I.e. accidentally corrupted).

4

mongma wrote on Wednesday, February 21, 2018:

Hello, Richard
Thank you very much for your reply.

I think (pxItemToRemove->pvContainer) value should be address of a List.(0xF100```)

I think I solved this problem now temporary.
There was a problem about entering critical section.

I use vPortEnterCritical() function for enterting critical section.
vPortEnterCritical() calls the ulPortSetInterruptMask().

ulPortSetInterruptMask() disables interrupt and sets portICCPMR_PRIORITY_MASK_REGISTER.
And then it enables interrupt.

I think critical section is not protected becasue interrupt is enabled.
I blocked enabling interrupt in ulPortSetInterruptMask().
And I confirmed the problem is solved.

uint32_t ulPortSetInterruptMask( void )
{
uint32_t ulReturn;

/* Interrupt in the CPU must be turned off while the ICCPMR is being
updated. */
portCPU_IRQ_DISABLE();
if( portICCPMR_PRIORITY_MASK_REGISTER == ( uint32_t ) ( configMAX_API_CALL_INTERRUPT_PRIORITY << portPRIORITY_SHIFT ) )
{
	/* Interrupts were already masked. */
	ulReturn = pdTRUE;
}
else
{
	ulReturn = pdFALSE;
	portICCPMR_PRIORITY_MASK_REGISTER = ( uint32_t ) ( configMAX_API_CALL_INTERRUPT_PRIORITY << portPRIORITY_SHIFT );
	__asm volatile (	"dsb		\n"
						"isb		\n" );
}

//portCPU_IRQ_ENABLE(); <------ block this line

return ulReturn;

}

I’m not sure whether this modification is correct or not.

Thank you.

5

mongma wrote on Wednesday, February 21, 2018:

I know that ulPortSetInterruptMask() masks interrupt.
I will check interrupt priirity and mask.

Thank you for your support.

6

mongma wrote on Wednesday, February 21, 2018:

I know that ulPortSetInterruptMask() masks interrupt.
I will check interrupt priirity and mask.

Thank you for your support.