Hello Richard, I am getting NMI’s (accesses to VMA’s – vacant memory address) with the MSP430 port on the following:  (Note I did an update today and am using the latest 7.4.2 source) signed portBASE_TYPE xTaskRemoveFromEventList( const xList * const pxEventList )
{
tskTCB *pxUnblockedTCB;
portBASE_TYPE xReturn; /* THIS FUNCTION MUST BE CALLED WITH INTERRUPTS DISABLED OR THE
SCHEDULER SUSPENDED.  It can also be called from within an ISR. */ /* The event list is sorted in priority order, so we can remove the
first in the list, remove the TCB from the delayed list, and add
it to the ready list. If an event is for a queue that is locked then this function will never
get called – the lock count on the queue will get modified instead.  This
means we can always expect exclusive access to the event list here. This function assumes that a check has already been made to ensure that
pxEventList is not empty. */
pxUnblockedTCB = ( tskTCB * ) listGET_OWNER_OF_HEAD_ENTRY( pxEventList );
configASSERT( pxUnblockedTCB );
uxListRemove( &( pxUnblockedTCB->xEventListItem ) );  <= NMI is occurring during execution of this line. if( uxSchedulerSuspended == ( unsigned portBASE_TYPE ) pdFALSE )
{
uxListRemove( &( pxUnblockedTCB->xGenericListItem ) );
prvAddTaskToReadyQueue( pxUnblockedTCB );
} ====== I have done the usual checks on stack; have tried putting some code in critical sections – which has helped – but I keep landing back on this.  I am hoping this could be a known or familiar issue to some of you on this forum. During debug of this project today this has come up repetitively.  The code is waiting for a structure to fill from a serial port – it is around 96 bytes – and sometimes it will even complete and the NMI still occurs on the above marked line. Thanks In Advance,
John Westmoreland

Oh – I forgot to add that is of course in tasks.c — Thanks,
John

Which version did you upgrade from? Did you make any other changes before this started happening, or just change the kernel version? Are you using the old base MSP430 port or the MSP43OX version? I presume you are still using IAR. Regards.

Hello Richard, I was using the previous kernel files – 7.4.2 – – and before that 7.4.1 – this issue just started happening today – before I downloaded the latest from SVN. Oh, I have made other source code changes – I have noticed if I bypass the UART RX Q it seems to stop the problem – not 100% sure of that but it is looking like that could be the case.  I have put in some code to write to a manual Q and I haven’t been able to reproduce the NMI since I did that – but I prefer to use the RTOS Q. I am using the latest MSP430X files. Yes – this is for EW430 – version 5.52.1. I have a RX Task blocking on data from the UART RX Q – nothing exotic – but it almost seems random at when the NMI occurs – I have a buffer of around 96 bytes that needs to be transferred – I see it fail at 16 bytes, 4 bytes, 95 bytes, 96 bytes; almost as if there is a timeout occurring.  Another strange observance too – I can break the debugger – all seems OK – as soon as I run again the NMI occurs.  Hmm. Thanks In Advance,
John

Hello Richard, It is looking like we have a task that is causing some problems – when I disable that task – the NMI’s go away – so – looks right now like this is ‘solved’ so to speak. I just wanted to ask when I did since the NMI was consistently happening in tasks.c in the list stuff – glad it isn’t part of the kernel. Best Regards,
John Westmoreland

A little more detail on this – in a timer ISR – xTaskResumeFromISR was being used instead of xSemaphoreGiveFromISR – once that was fixed I am no longer seeing the NMI issue. Regards,
John W.

Richard and All FreeRTOS’ers, Well, one must test-test-test before you know you’ve fixed a bug.  The NMI bug unfortunately still happens – and it is crashing still someplace in the list stuff – but, ah – look what is says in lists.c where it is crashing now: /* *** NOTE ***********************************************************
If you find your application is crashing here then likely causes are:
1) Stack overflow –
   see http://www.freertos.org/Stacks-and-stack-overflow-checking.html
2) Incorrect interrupt priority assignment, especially on Cortex-M3
   parts where numerically high priority values denote low actual
   interrupt priories, which can seem counter intuitive.  See
   configMAX_SYSCALL_INTERRUPT_PRIORITY on http://www.freertos.org/a00110.html
3) Calling an API function from within a critical section or when
   the scheduler is suspended.
4) Using a queue or semaphore before it has been initialised or
   before the scheduler has been started (are interrupts firing
   before vTaskStartScheduler() has been called?).
See http://www.freertos.org/FAQHelp.html for more tips.
**********************************************************************/ So, this is good.  50% of bug fixing is understanding what has caused it to happen. Thanks and Regards,
John W.

Interestingly enough – I changed the task to use this vs. the timer ISR with the semaphore give:    vTaskDelayUntil ( &xLastWakeTime, xPeriod ); and the NMI problem is seemingly gone.