FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [June 2013 Threads] NMI Occurring In tasks.c repetitively -MSP430Posted by Westmoreland Engineering on June 18, 2013 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
RE: NMI Occurring In tasks.c repetitively -MSP430Posted by Westmoreland Engineering on June 18, 2013 Oh - I forgot to add that is of course in tasks.c ---
Thanks, John
RE: NMI Occurring In tasks.c repetitively -MSP430Posted by Richard on June 18, 2013 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.
RE: NMI Occurring In tasks.c repetitively -MSP430Posted by Westmoreland Engineering on June 18, 2013 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
RE: NMI Occurring In tasks.c repetitively -MSP430Posted by Westmoreland Engineering on June 19, 2013 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
RE: NMI Occurring In tasks.c repetitively -MSP430Posted by Westmoreland Engineering on June 20, 2013 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.
RE: NMI Occurring In tasks.c repetitively -MSP430Posted by Westmoreland Engineering on June 22, 2013 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.
RE: NMI Occurring In tasks.c repetitively -MSP430Posted by Westmoreland Engineering on June 29, 2013 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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|