topic Re: Kinetis and FreeRTOS in Kinetis Design Studio

Kinetis and FreeRTOS

BillTheBiker — Thu, 25 Jun 2015 03:40:02 GMT

Well despite all my best efforts, I am now convinced that the port of FreeRTOS with ProcessorExpert is not correct. I could go into the gruesome details of what I am seeing, but I would rather just poll the community and ask if anyone has had better success with using FreeRTOS with KDS? I have tons of experience with FreeRTOS and I know the kernel is fine, it is widely deployed. I also *think* I know what I am doing with implementing a FreeRTOS-base program. But when a task variable is getting corrupted by merely the action of passing it via a queue, and I have the task stack depth to 2K with hardly any deep calls, something ain't right. The tasks I have do not do anything, but receive this message and pass it along. I am actually at a lost to the cause, but all ideas welcome....

Re: Kinetis and FreeRTOS

BillTheBiker — Thu, 25 Jun 2015 19:27:20 GMT

Sorry I have been very frustrated with this dev env. that I forgot my normal details:

FreeRTOS Version : 8.0.1

configAssert has been defined

heap size set to 16384

total number of task allowed : 8

total defined 3 with configMINIMAL_STACK_SIZE at 128

total queues defined 2 with depth of about 5 small elements

memory allocation scheme is heap_1.c

running KDS 3.0.0 on Win7

using tickless idle mode as we are sleeping the processor until it is woken up with an accelerometer generated interrupt.

there are a few FreeRTOS timers in use and one mutex.

Re: Kinetis and FreeRTOS

sergeisharonov — Thu, 25 Jun 2015 20:40:26 GMT

I am using FreeRTOS V8.2.0 with KDS 2.0.0, KSDK 1.1.0 and updated toolchain from ARM. However I chose not to use PE and port FreeRTOS from scratch. Reasons:

1. IMHO processor expert is a buggy and unnecessary obfuscation tool.

2. Provided port of FreeRTOS was outdated and poorly integrated.

Anyway, porting FreeRTOS from sources was a surprisingly trivial task. The only issue I ran into was interrupt priorities. That warning in FreeRTOS source is there for a reason. Poor choice in setting priorities resulted in some really weird crashes.

Regards,

Sergei

Re: Kinetis and FreeRTOS

BlackNight — Thu, 25 Jun 2015 21:23:13 GMT

Hi William,

sorry to hear that you have problems. I'm using FreeRTOS intensively, and hopefully I can give you hopefully some ideas.

To me, it sounds like a stack overflow issue. I recommend that you increase configMINIMAL_STACK_SIZE say to 200, or maybe even 300.

Your heap size should allow you that.

Next, if not already done, do you have stack overflow check (configCHECK_FOR_STACK_OVERFLOW) turned on? If not, that might be helpful.

You say you are using FreeRTOS V8.0.1. The Kinetis SDK is using v8.0.0, and my McuOnEclipse (McuOnEclipse - Browse /PEx Components at SourceForge.net) is at V8.2.0. So I'm wondering if you are using something different?

What processor are you using? M4 or M4F? Then you need to make sure you that configLIBRARY_LOWEST_INTERRUPT_PRIORITY is set correctly, see RTOS for ARM Cortex-M

Last but not least: I recommend that you turn off tickless idle mode, just to keep things little bit more simple. You can turn this on later on again.

I hope this helps,

Erich

Re: Kinetis and FreeRTOS

BlackNight — Thu, 25 Jun 2015 21:28:38 GMT

KDS V3.0.0 comes with the Q3_14 toolchain from ARM (launchpad), but you can easily swap it to the Q1_15 release too (I'm using the Q3_14 because its code density for my projects are better than the Q1_15 one).

I agree: porting FreeRTOS is rather easy, all the dependend stuff is in the port.c.

I have the 8.2.0 port as well here for the SDK:

mcuoneclipse/Examples/KSDK/FreeRTOS_V8.2.0 at master · ErichStyger/mcuoneclipse · GitHub

And I agree: using the wrong priorities or boundaries between interrupts which are allowed to call RTOS functions and the ones which are not (configLIBRARY_LOWEST_INTERRUPT_PRIORITY) can create all kind of data or stack corruption.

Erich

Re: Kinetis and FreeRTOS

BillTheBiker — Thu, 25 Jun 2015 23:05:25 GMT

Thanks Erich for the reply; I did pay close attention to the items in your list, but let me go over my configuration with you. Firstly, I use KL46Z for processor.

In the tasks I used uxTaskGetStackHighWaterMark just to make sure I was not overflowing the stack but I did have

#define configCHECK_FOR_STACK_OVERFLOW 1 /* 0 is disabling stack overflow. Set it to 1 for Method1 or 2 for Method2 */

set in the FreeRTOSConfig.h file. I also set the tasks with configMINIMAL_STACK_SIZE * 3, so each task has a huge amount of stack space. There was no indication we were even warming the stack up.

This is the setting for the interrupt levels in the FreeRTOSconfig.h file.

/* The lowest interrupt priority that can be used in a call to a "set priority" function. */

#define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 1

Both interrupts in the system are set to prio level 2. I think this is correct we need to be below configLIBRARY_LOWEST_INTERRUPT_PRIORITY, which in the ARM architecture the lower the prio number the higher the prio (please correct me if I am wrong). Lastly I am using the FreeRTOS v8.2.0 at my home office with the same source (PE does not do well with SVN so it does not seem to update at work).

I turned off tickless mode and pretty much removed the code from the tasks. All I allow are the interrupts to fire off a message which is passed between three tasks. The first time thru all works well, but the state information in the message is lost when the interrupt refires and the process is repeated. So I am at a loss.

Re: Kinetis and FreeRTOS

BillTheBiker — Thu, 25 Jun 2015 23:09:28 GMT

Great that you did that, hopefully you submitted this to the user section of ports, so the community can benefit

Re: Kinetis and FreeRTOS

BlackNight — Thu, 25 Jun 2015 23:22:08 GMT

Hi William,

Stack overflow and stack settings: that looks ok, good!

As you are using an ARM Cortex-M0+, the RTOS should run with the lowest priority which is 3 for that core:

#define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 3

And configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY should be the maxium level where you are using calls to the RTOS. As you are using interrupt level 2, this should be:

#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 2

Can you verify this?

Thanks,

Erich

Re: Kinetis and FreeRTOS

BillTheBiker — Fri, 26 Jun 2015 15:42:27 GMT

Thanks Erich,

Looks like the settings were

I'll readjust to your recommendations and see if this works...!

Re: Kinetis and FreeRTOS

BillTheBiker — Fri, 26 Jun 2015 19:28:57 GMT

What should the RTOS Interrupt Priority be set to?

I have this setting:

but I am still getting the data corruption. I turned off the tickless idle, but nothing seems to help.

Re: Kinetis and FreeRTOS

BlackNight — Fri, 26 Jun 2015 19:37:43 GMT

The RTOS should run with the lowest interrupt priority, so 3 is fine.

Just to be sure: after you made the changes in the settings, have you regenerated the Processor Expert code and rebuilt your application before downloading/debugging?

Here are a few other things:

- it could be that you have some other dangling pointers/etc which corrupt your data structure?

- other than that, and I cannot promise anything: does your project run on a FRDM-KL46Z board? If so, you might send it to me and I could have a look?

Erich

Re: Kinetis and FreeRTOS

BillTheBiker — Fri, 26 Jun 2015 19:55:11 GMT

Erich

To give you a sense of what I am seeing here is the watch output of the task variable on the first pass

The task goes back to a blocked state waiting for the next message:

As you can see the variable has gotten clobbered, the values should not have changed. uxTaskGetStackHighWaterMark( NULL ) returns 204, so plenty of stack left.

Re: Kinetis and FreeRTOS

BillTheBiker — Fri, 26 Jun 2015 19:57:35 GMT

no I think my code is solid (famous last words!), but this is simple, I have a task which generates and a message and a task which consumes the message. I do not know if this would run on the KL46 (this is a custom board), but we rely on the accelerometer to be at a certain angle. However, let me see if I can simulate the message production and see if this still works...

Re: Kinetis and FreeRTOS

BlackNight — Fri, 26 Jun 2015 20:03:51 GMT

I would set a watchpoint on that corrupted memory (see C/C++ Watchpoints with Eclipse Kepler | MCU on Eclipse ) to find out what/who is writing to that location.

Erich

Re: Kinetis and FreeRTOS

BillTheBiker — Fri, 26 Jun 2015 20:10:46 GMT

Erich,

Not sure how compatible this would be to the KL46Z dev board, but we heavily leveraged this board to get the custom board built. This program relies on a tap event from the accelerometer, so if you can get the code to run, you should be able to trap and see the problem. Appreciate all the help...

https://dl.dropboxusercontent.com/u/80917392/ElephantTimer.zip

Re: Kinetis and FreeRTOS

BillTheBiker — Fri, 26 Jun 2015 20:37:14 GMT

would love to, but this option is always grayed out. I am using KDS 3.0.0

Re: Kinetis and FreeRTOS

BillTheBiker — Mon, 29 Jun 2015 17:26:06 GMT

Thanks Erich for all the help. The problem is definitely the interrupt level scheme, which seems a little confusing to me, but I made the OS be level 3, and all components which are ISR's and signal the OS be level 2. This now works, as these were set at level 1 which is a crash situation.

The OS settings:

An EINT component setting:

I also used the latest component from GIT (FreeRTOS v8.2.0)

Hopefully other users may find this thread useful is they choose to run FreeRTOS on the Cortex-M0 Freescale processor...

Re: Kinetis and FreeRTOS

BlackNight — Mon, 29 Jun 2015 19:47:10 GMT

Now your settings look ok, with the RTOS running at the lowest level (3), and ISR's which do calls to the OS are up to level 2 max (Max SysCall Interrupt Prio). Indeed, if you have in your above configurations interrupts with level <2 (numerically lower) and calling OS functions, this will corrupt the OS, as outlined on FreeRTOS.org.

I hope this all makes sense now.

Erich