FreeRTOS hang-up

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Charles on Tue Jan 25 02:42:35 MST 2011
Hi,

I have a problem where FreeRTOS hangs up in a simple application. I have a serial interrupt collecting data and posting a pointer to the data via xQueueSendFromISR(). The receiving task waits on the receive queue and when there is data it processes it.
My problem seems to occur when the processing of the data takes too long and the Queue fills up, at present it's 8 deep. If I look in the Queue I can see there are 8 items but the receiving task never wakes up, i.e. xQueueReceive() never returns. While I am processing the data I use taskENTER_CRITICAL() and taskEXIT_CRITICAL() to give the processing as much of the CPU time as possible.
The timing is something like this:
Processing time 8ms to 12ms depending on the data.
System tick 1ms.
Data sending from the ISR xQueueSendFromISR() every 10ms.

I am using LPCXpresso 3.4.6 as 3.6 has a problem compiling the code.
FreeRTOS V6.1.0.
CMSISv1p30_LPC13xx.
And the CPU is a LCP1313.

Thanks,
Charles

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Wed Apr 20 23:16:36 MST 2011

Quote: rmteo
This concept of never returning from a task does take getting used to. It is the most common mistake made by newcomers to the wonderful world of RTOS's and multi-tasking. Glad you sorted it out.

Nope, this was just a mistake made by an oldie ... I've been using uCOS II for about 10 years by I changed jobs and wanted to try something new.
I just made some stuff without RTOS and quickly hacked that into the SimpleDemo without thinking ...

Quote: jharwood
Small clarification: the stack depth is specified in (architecture-dependent) [U]words[/U], not bytes.

And while there is a #define configMINIMAL_STACK_SIZE 80, it's not really a default.

This all depends on the port. For the lpc words are 32 bits wide.
Looking in more detail at the FreeRTOS code I discovered that the heap is measured in bytes ...

It does make sense to set configUSE_MALLOC_FAILED_HOOK to 1 and create the vApplicationMallocFailedHook() function. At least then I the application hangs at a defined point and I can trace back my stack to the point where I discover where my application went wrong (or just cose my eyes and increase the heap :eek:)

But this is becoming too FreeRTOS specific - I think -
I had a FreeRTOS problem that was easily fixed after I had my debugging properly working again (and that was a genuine LPCXpresso/linker problem)

Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by jharwood on Wed Apr 20 11:44:28 MST 2011

Quote: CodeRedSupport
I suggest you look at the stack size you are giving each task on the xTaskCreate() calls. I think the default is 80 bytes, which can be used very quickly for non-trivial tasks. Once the stack overflows, all bets are off...

Small clarification: the stack depth is specified in (architecture-dependent) [U]words[/U], not bytes.

And while there is a #define configMINIMAL_STACK_SIZE 80, it's not really a default.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by rmteo on Wed Apr 20 10:34:14 MST 2011

Quote: Rob65
.....My task did not contain a while loop so the function (task) returned to where ??? After adding a while loop it's all running smoothly now

This concept of never returning from a task does take getting used to. It is the most common mistake made by newcomers to the wonderful world of RTOS's and multi-tasking. Glad you sorted it out.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Wed Apr 20 10:24:37 MST 2011

Quote: Rob65

To show my gratitude I should upgrade to the NXP edition and[B] buy[/B] a RedProbe+ - at least a RedProbe, i think that one will speed up download and debugging a lot...

Boys and their toys.:D

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Wed Apr 20 04:45:56 MST 2011
Thanks, magic happened!
Now I suddenly see what is going on while stepping through my code :)
Obviously my code is still not working correctly but at least debugging makes sense with the --gc-sections linker option removed.:D

To show my gratitude I should upgrade to the NXP edition and buy a RedProbe+ - at least a RedProbe, i think that one will speed up download and debugging a lot...

Found it! User error: hit any user to continue ..
My task did not contain a while loop so the function (task) returned to where ??? After adding a while loop it's all running smoothly now

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Wed Apr 20 04:27:07 MST 2011
Try removing the "--gc-sections" option from the linker. This option removes unused code, but is known to occasionally cause debug table issues. [This issue will be much improved in the next version of LPCXpresso]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Wed Apr 20 03:25:25 MST 2011
Charles, thanks. Optimization for the FreeRTOS_Library is set to -O1 in the example from NXP. The SimpleDemo project was set to -O0.

There seems to be a different problem though ...
While debugging I just noticed that the disassembly window shows correctly that I am in the right function but the window with the C-source shows a completely different line of code.

Very strange. My C-code tells me it's calling ANT_Reset and in the assembly I see "bl 0x124" but when I arrive in that function the C-windows shows a complete different function.

Have a look at the following pictures, these show single instruction stepping through the routine. It shows single stepping through the ANT_ResetSystem function but the source code shows two different functions (have a look at the line numbers, the correct function runs from line 30-41) the assembly however looks correct for the given C-code.

And yes, I checked stack sizes but I had to make the heap bigger, apparently I was running out of heap space but since the application is not check anything ...

[IMG]http://bikealive.nl/img-for-others/LPCXpresso-forum/20110420-4.png[/IMG]
[IMG]http://bikealive.nl/img-for-others/LPCXpresso-forum/20110420-5.png[/IMG]
[IMG]http://bikealive.nl/img-for-others/LPCXpresso-forum/20110420-6.png[/IMG]
[IMG]http://bikealive.nl/img-for-others/LPCXpresso-forum/20110420-7.png[/IMG]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Tue Apr 19 23:25:39 MST 2011
I suggest you look at the stack size you are giving each task on the xTaskCreate() calls. I think the default is 80 bytes, which can be used very quickly for non-trivial tasks. Once the stack overflows, all bets are off...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Charles on Tue Apr 19 23:07:47 MST 2011
Hi Rob,

I can suggest that you disable all optimization and then try debugging again, the optimization can cause weird issues in debug. If you don't have the code space to turn off optimization on the whole project you can select each file you wish to debug and disable the optimization for each in the properties.

Charles

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Tue Apr 19 12:33:19 MST 2011
I also see some strange problems with the FreeRTOS example from the NXP site.
I started adding my own stuff but I am a bit stuck at a point where stuff suddenly stops working. The debugger shows me either a hard fault (debugger halts in HardFault_Handler) or it is staying at the line with vTaskStartScheduler().

Some problems are (of course) due to stupid user errors like calling vTaskDelay not in a task but during initialization or stuff like waiting for a certain condition where the condition already changes before my tasks becomes the current task etc...
But some things look like memory problems where data/heap/stack are overwriting each others data.

On one occasion I tried to debug through the xTaskCreate but arriving in xTaskGenericCreate something strange happens; variables change values without an assignment going on and here:

        #if( portSTACK_GROWTH < 0 )
        {
            pxTopOfStack = pxNewTCB->pxStack + ( usStackDepth - 1 );
            pxTopOfStack = ( portSTACK_TYPE * ) ( ( ( unsigned long ) pxTopOfStack ) & ( ( unsigned long ) ~portBYTE_ALIGNMENT_MASK  ) );
        }

The first line with pxTopOfStack = is just skipped when single stepping and the value of that var. is 0x0 even when the line is executed and suddenly while debugging I arrive in a function that is not called at all (not being used by any function/task yet).

Looks like one of those "User error: hit any user to continue" (Yes yes, please, let me have 'm :cool:) errors but after a full day of trial on error and shooting darts blindfolded I'm kind of empty with ideas.
I am sure other uses have gone the same way ...

I am using:

LPCXpresso 3.6.2
FreeRTOS V6.1.0.
CMSISv1p30_LPC13xx.
And the CPU is a LCP1343.

Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Wed Jan 26 06:45:12 MST 2011
Can you also confirm if you are using LPCXpresso 3.6 or 3.6.1? If 3.6, then please try upgrading and see if you see the same issue?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Wed Jan 26 06:42:58 MST 2011
Can you post the build log (copy and paste out of the console into a text file), the .map file that gets created by the linker, and if possible, the .axf file, from the project build where the code fails to run correctly?

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Charles on Wed Jan 26 06:38:37 MST 2011
CodeRedSupport:

If I try using the 3.6 version of LPCXpresso when I start debugging the code hangs-up. I have traced it down to "void SystemInit (void)" and found that the code in SystemInit is corrupt. The compiler/linker gives no errors.

FreeRTOS V6.1.0.
CMSISv1p30_LPC13xx.
And the CPU is a LCP1313.

Regards,
Charles

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Charles on Wed Jan 26 06:31:00 MST 2011
Hi Richard,

Thanks for the info.

The taskENTER_CRITICAL() and taskEXIT_CRITICAL() are used in the task to stop the RTOS checking every 1ms if the task needs to yield. I see that it would be better to use vTaskSuspendAll() & xTaskResumeAll().
I guess I was fortunate in that the serial interrupts still ran after taskENTER_CRITICAL() was called.

Changing the ISR to use the portEND_SWITCHING_ISR( bool ) seems to have solved the problem.

Can you point me in the direction to "create a critical section" as I would like to know for another project?

PS. I inherited the code so I am trying to get it working. As is said it ran and hang-up once in a while.

Regards,
Charles

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Wed Jan 26 06:30:36 MST 2011

Quote: Charles

I am using LPCXpresso 3.4.6 as 3.6 has a problem compiling the code.

What is the actual problem that you see using 3.6? If you can provide details of the error messages you see, we might be able to help.

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by on Tue Jan 25 03:29:42 MST 2011
Hi,

Have you taken account of point 3 in http://www.freertos.org/FAQHelp.html?

When are you using taskENTER_CRITICAL() and taskEXIT_CRITICAL()? It is not clear from your post if this is in the interrupt that is sending the data to the queue, or in the task that is receiving the data.

If its in the interrupt, then basically [B]DON'T[/B]. First it would make no sense to do that because the interrupt priorities should be used to ensure things get processed in the right order. If you really must create a critical section then there is an interrupt safe way of doing it, and I can point you in the right direction for that.

If its in the task, then, presumably its after the call to xQueueReceive() has returned? API functions such as xQueueReceive() must not be called in a critical section (I think the above linked page will say that somewhere too.
Especially the bit about not calling API functions that don't end in FromISR from an ISR. This is essential particularly for taskENTER_CRITICAL() and taskEXIT_CRITICAL() which should [B]never[/B] be called from an ISR.

Likewise, if your processing is taking 12ms then this must not be done in a critical section either. If a critical section is really needed (which again, I would imagine task priorities would be a better way of ensuring processing occurrs in the right order) then the scheduler locking method will permit interrupts to be received while you are in the critical section. Using taskENTER_CRITICAL() does not.

Are you performing a context switch in the ISR when the post to the queue unblocks a task? That is done using portEND_SWITCHING_ISR( bool ).

I co-incidentally tested the LPCXpresso LPC1768 book examples with the very latest LPCXpresso IDE just yesterday, and that was working fine. I have not checked with the LPC13xx, but the set up will be basically the same so there should not be any configuration problems.

Regards,
Richard (http://www.FreeRTOS.org)