What is this ? Stack Overflow ?

Hello there, My application started to act crazy.  I find the device is working (i.e. interrupt handlers are being called, my status led keeps on blinking) but tasks are stopped. I halt the system via a debugger and find that uxMissedTicks is 4 billion sometehing. The memory layout is something like this; .bss.pxCurrentTCB                 0x20009d58        0x4 ../Source/tasks.o                 0x20009d58                pxCurrentTCB .bss.xDelayedTaskList1                 0x20009d5c       0x14 ../Source/tasks.o .bss.xDelayedTaskList2                 0x20009d70       0x14 ../Source/tasks.o .bss.uxSchedulerSuspended                 0x20009d84        0x4 ../Source/tasks.o .bss.uxMissedTicks                 0x20009d88        0x4 ../Source/tasks.o .bss.pcTraceBufferEnd                 0x20009d8c        0x4 ../Source/tasks.o .bss.xNumOfOverflows                 0x20009d90        0x4 ../Source/tasks.o .bss.xTickCount                 0x20009d94        0x4 ../Source/tasks.o .bss.uxTopUsedPriority                 0x20009d98        0x4 ../Source/tasks.o .bss.xHeap     0x20009d9c     0x2804 ../Source/portable/MemMang/heap_2.o .bss.xStart    0x2000c5a0        0x8 ../Source/portable/MemMang/heap_2.o .bss.xEnd      0x2000c5a8        0x8 ../Source/portable/MemMang/heap_2.o .bss.xHeapHasBeenInitialised.1635 This is ARM Cortex-M3, SRAM starts at 0x20000000 and the SRAM size is 64k. So it looks like growing down xHeap stack could do this kind of damage. But the variables in between looks intact (as indeed the top used priority is 4). uxMissedTicks    4289657151    pcTraceBufferEnd    0x00000000    xNumOfOverflows    0    xTickCount    5339088    uxTopUsedPriority    4    When I set uxMissedTicks to, say, 10 via debugger the system continiues to operate correctly (at least apparently, it answers serial port queries and all)… but soon after uxMissedTicks is again some 4-billion value. Any idea how to hunt this ? Kind regards

What is this ? Stack Overflow ?

What is configKERNEL_INTERRUPT_PRIORITY set to? What is configMAX_SYSCALL_INTERRUPT_PRIORITY set to? What priority are all your other interrupts running at? On Cortex problems like this are normally bad interrupt priority settings, or calling an API function from inside a critical section.

What is this ? Stack Overflow ?

I have the following macros in my config header. #define configMAX_SYSCALL_INTERRUPT_PRIORITY        191 #define configKERNEL_INTERRUPT_PRIORITY 255 But… As far as I remember these #defines introduced in 5.2.0 ? And I have reverted to using 5.0.0. Do these still apply ?

What is this ? Stack Overflow ?

See http://www.freertos.org/History.txt , it was introduced in V5.0.2. Anybody else having to log in twice to be able to post at the moment? Regards.

What is this ? Stack Overflow ?

This case so many undefined behavior, I’m really stuck with this problem for the past 2 weeks :/ In essence this is the story, there are 5 runnings tasks (uIP, MAC, Idle, Modbus, UserTask). uIP and MAC are two tasks which are being used directly from the Richard’s examples. And Modbus task is mine which is very similar to the MAC task… Both are "interrupt handler tasks" woken by real ISRs. In this case Modbus task is woken by UART handler. Now, I’m upgraded to FreeRTOS 5.2.0. 5 tasks still runs… as soon as I plug the serial port cable (so my device is started to be queried like 30 times/sec) it immediately freezes. This time I find FreeRTOS looping in vListInsert()’s         for( pxIterator = ( xListItem * ) &( pxList->xListEnd ); pxIterator->pxNext->xItemValue <= xValueOfInsertion; pxIterator = pxIterator->pxNext ) Any ideas ?

What is this ? Stack Overflow ?

What is configKERNEL_INTERRUPT_PRIORITY set to? What is configMAX_SYSCALL_INTERRUPT_PRIORITY set to? What priority are all your other interrupts running at? On Cortex problems like this are normally bad interrupt priority settings, or calling an API function from inside a critical section.

What is this ? Stack Overflow ?

#define configMAX_SYSCALL_INTERRUPT_PRIORITY        191 #define configKERNEL_INTERRUPT_PRIORITY 255 I’m not configuring any priority level for my interrupts, so they should have the default value. Is this a problem ?

What is this ? Stack Overflow ?

I haven’t read the whole thread, but given what you describe and the fact that you’re on a Cortex-M3, I would bet that your interrupt handlers using FreeRTOS API functions (ending in _FromISR) have too low a priority (as configured in the NVIC), meaning that they run even when FreeRTOS tries to prevent those interrupt handlers from running. What priority did you set for those ISR? Once you group the preemption priority and the subpriority into a 8 bits value, each of them must be between configMAX_SYSCALL_INTERRUPT_PRIORITY (exclusive, default 191) and configKERNEL_INTERRUPT_PRIORITY (inclusive, default 255).

What is this ? Stack Overflow ?

> I’m not configuring any priority level for my interrupts, so they should have the default value. Is this a problem ? Absolutely! Default ISR priorities on the Cortex-M3 are *not* suitable for ISR using the FreeRTOS API. Those priorities are much too low (meaning too high a priority in the Cortex-M3 world).

What is this ? Stack Overflow ?

Oh. I checked with the documentation and indeed the default value is 0, the highest. The line that I have missed from Richards example is IntPrioritySet( INT_ETH, configKERNEL_INTERRUPT_PRIORITY ); I’ve added similar line for UART and now it looks like working really well! Now, this means that previously, my UART interrupt could have preempted the kernel. And call API functions. What would be an example scenario that could corrupt the system ? (I’m trying to grasp what is happening here) And why isn’t kernel not with the highest priority then ? Kind regards

What is this ? Stack Overflow ?

FreeRTOS needs to run as the lowest possible priority (in the regular meaning, not the Cortex-M3 meaning) to make sure that the context it saves and restores is the interrupted task context. If it had a high priority, it could by accident manipulate the context of another ISR that would have been preempted. Also, why would the FreeRTOS kernel need to run at a higher priority? The less intrusive the better. If it had a high priority, sure, it could switch tasks while other ISRs are currently running or pending, but anyway those tasks would never execute immediately because of the pending ISR.

What is this ? Stack Overflow ?

>FreeRTOS needs to run as the lowest possible priority (in the regular meaning, not the Cortex-M3 meaning) to make sure that the context it saves and restores is the interrupted task context. If it had a high priority, it could by accident manipulate the context of another ISR that would have been preempted So the idea is to never preempt an interrupt service routine but only the user space tasks ? I don’t see how it would hurt the ISR context though. By the way, Dave and Samuel, I can’t put in words how much I appreciate your help. Thank you very much.

What is this ? Stack Overflow ?

Hi Engin, The problem is you are facing a race condition where the suspended task was trying to add the missed ticks to the system tick count. --uxMissedTicks is getting called by 2 different tasks. One of them drains it, loops until it becomes 0. Then at some point it is swapped out and other task decrements it which overflows the unsigned integer. Obviously this shouldn’t happen. It looks like you are using CortexM3 core and I would guess STM32. I had stumbled on a similar problem with STM32. Even though CortexM3 can have 256 priority levels, STM32 set this to 16. They can be 0x00, 0x10… 0xF0. Basically when you call the disable interrupt function, if it is setting the BASEPRI register to a high value, any interrupt with priority lower than it will not be masked. Probably for your case, when you are about to decrement the missed tick count, a PENDSV interrupt swaps the context and another task claims these missed ticks. I have resolved the problem by setting #define configMAX_SYSCALL_INTERRUPT_PRIORITY 0x10 #define configKERNEL_INTERRUPT_PRIORITY 0xF0. But even with these settings, interrupts with priority 0x00 will not be masked. So, make sure your SYSTICK and PENDSV interrupts have lower priority. Thanks a lot