XSemaphoreGiveFromISR takes forever sometimes

Kernel
1

cynergizer wrote on Wednesday, November 30, 2011:

I am using xSemaphoreGiveFromISR, which normally takes just a few usecs to execute, but everyone once in a while it takes 54 ms to execute.  I’ve tracked this down to prvAddTaskToReadyQueue in vTaskRemoveFromEventList in xQueueGenericSendFromISR.  I’m using an LPC2378 running at max speed of 72Mhz.  I do allow task preemption, but I do not nest interrupts.  My timing measurements are from wiggling a pin and measuring it on scope, triggering via excessive pulse width.  Searching through the forum, it looks like someone had a similar problem which Richard thought might be caused by a stack overflow? 

2

cynergizer wrote on Wednesday, November 30, 2011:

This problem seems to go away when I turn off MAM.  Bizarre.

3

edwards3 wrote on Thursday, December 01, 2011:

I’ve tracked this down to prvAddTaskToReadyQueue in vTaskRemoveFromEventList

prvAddTaskToReadyQueue() calls vListInsertEnd(), which is a deterministic function (it always takes the same time to execute).

void vListInsertEnd( xList *pxList, xListItem *pxNewListItem )
{
volatile xListItem * pxIndex;
	/* Insert a new list item into pxList, but rather than sort the list,
	makes the new list item the last item to be removed by a call to
	pvListGetOwnerOfNextEntry.  This means it has to be the item pointed to by
	the pxIndex member. */
	pxIndex = pxList->pxIndex;
	pxNewListItem->pxNext = pxIndex->pxNext;
	pxNewListItem->pxPrevious = pxList->pxIndex;
	pxIndex->pxNext->pxPrevious = ( volatile xListItem * ) pxNewListItem;
	pxIndex->pxNext = ( volatile xListItem * ) pxNewListItem;
	pxList->pxIndex = ( volatile xListItem * ) pxNewListItem;
	/* Remember which list the item is in. */
	pxNewListItem->pvContainer = ( void * ) pxList;
	( pxList->uxNumberOfItems )++;
}

This problem seems to go away when I turn off MAM.  Bizarre.

Not really. The original 2368 and 2378 parts have known bugs in the MAM. Check the errata for your revision to see if the bug is still there. I think the FreeRTOS demo for the 2368 always turns the MAM off for that reason.

4

cynergizer wrote on Monday, December 05, 2011:

Hi Edwards,
Thanks for your response.  Yes, I agree there is nothing in vListInsertEnd that explains this delay.  I don’t see any mention of the MAM in the errata for the 2378 (although I did have trouble using MAM in combination with IDLE mode and usb on the LPC2148). 
Best Regards.