RTOS with Processor Expert Project where processor is not supported by KSDK

[justusandjustic]

I am using a S9KEAZN64* processor which is currently not supported by KSDK.  Is there a plan to support this chip, or others in the same family in the future?  What are the options in the way of RTOS in a Processor Expert project in the meantime?

[xiangjun_rong]

Hi, Josiah,

yes, the KEA family does not have SDK package, but i think you can download the driver package which is based on KE family from the website. But it does not have the code example based on freeRtos.

http://tinyurl.com/gsbp3co

Hope it can help you

BR

XiangJun Rong

[justusandjustic]

Thanks for the reply.

I am able to accomplish most of what I want to do with Processor Expert.  The only thing I really wanted the SDK for was RTOS.  It's not an immediate requirement for my project, so if the SDK is not an option, and there isn't a similarly simple way to do it, I will probably just come back to RTOS implementation later.

[BlackNight · Accepted solution]

Hi Josiah,

there is an open source Processor Expert component available with the McuOnEclipse project, see McuOnEclipse Components: 12-Dec-2016 Release | MCU on Eclipse  for the latest release. The download (make sure you install both files) is on SourceForge, see McuOnEclipse Releases on SourceForge | MCU on Eclipse .

Here is how it looks:

As the SKEA is a Cortex-M0+, make sure you configure it for the M0+:

I hope this helps,

Erich

[justusandjustic]

Thanks, Erich!

I had tried a RTOS component previously, but I was unable to get it fully working.  However, this looks to be a different one than the one I tried, so hopefully I will have more success.

-Josiah

[BlackNight]

Hi Josiah,

yes, this one is different from the one supplied by default with Processor Expert. This one is supporting the latest and greatest FreeRTOS with all the bells and whistles supporting 8 different architectures and 7 different compilers :-).

And let me know if you need anything to get started with it.

Erich

[justusandjustic]

Erich,

I downloaded the component and created a quick test LED blinky project and discovered that this is the component I had tried before.  I am able to successfully create a task to blink an LED, but when I try to create a second task, I get stuck.  Stepping through with the debugger, at some point I get to the function 'FRTOS1_vApplicationMallocFailedHook()', which seems to suggest I've run out of heap space?  I'm guessing this is some sort of implementation issue on my part.  Do you have any simple example projects that create more than one task?  Or any suggestions in general?  I'm a little out of my depth here...
-Josiah

[BlackNight]

Hi Josiah,

yes, you are running out of heap memory. The size of the heap is specified (in bytes) by configTOTAL_HEAP_SIZE in FreeRTOSConfig.h. See FreeRTOS - The Free RTOS configuration constants and configuration options - FREE Open Source RTOS f...  for a list of configuration items.

In the component there is a setting for this:

Erich

[justusandjustic]

Yeah, I found that setting after I replied.  I played around with changing the heap size for awhile, but each time I either got an error saying the heap was too small for FreeRTOS, or got an error saying it was too large to fit on my processor.  Apparently this chip only has 4KB: http://www.nxp.com/assets/documents/data/en/data-sheets/S9KEA64P64M20SF0.pdf 

Is there anything else I can try?  Or is my chip just not going to be able to handle FreeRTOS?

-Josiah

[BlackNight]

Hi Josiah,

4 K or RAM is possible (I'm running FreeRTOS in a product which just has 1 KByte of RAM). However, this requires careful analysis and undestanding of the settings. Mainly it depends on how many tasks you run (every task needs stack space in RAM), the number of queues, semaphore, mutex, etc and of course your application variables.

For example the default stack size for most FreeRTOS demos is set to 200 or 128 in configMINIMAL_STACK_SIZE (FreeRTOS - The Free RTOS configuration constants and configuration options - FREE Open Source RTOS f... ) which is 4x that number (so for 200 it is 800 bytes!). That's probably too much for your application, and keep in mind that there is the IDLE task too which thakes that amount. So if you create one task with configMINIMAL_STACK_SIZE this will eat up 1600 bytes of RAM. You can easily reduce these numbers.

I hope this helps,

Erich

[justusandjustic]

Erich,

I did not think about the fact that the number was 1/4th the number of bytes.  That would explain why I couldn't do more than two tasks (including Idle Task).  I changed that the Minimal Stack Size setting to 100 and my demo tasks are now working successfully!  Hopefully I will be able to adopt this into my full program.

One last question: If I reduce the stack size below what the task needs, will I get a clean error, or will I overflow and cause bad things to happen?  I'm wondering if I can just do a trial-and-error method of determining stack size I will need for the tasks in my main project.

Thanks for answering all my questions so far, you have been extremely helpful!

-Josiah

[BlackNight]

Hi Joshiah,

you won't get a clean error for stack overflow, but there is a stack overflow hook you can use:

Read as well FreeRTOS - stacks and stack overflow checking .

To statically calculate the stack size needed I'm using the method described here: GNU Static Stack Usage Analysis | MCU on Eclipse 

A good 'trial-and-error' way is to use the FreeRTOS Kernel awarness in KDS which shows the currently and max used stack: FreeRTOS Kernel Awareness for Eclipse from NXP | MCU on Eclipse  with the Task List view which shows how much stack is used: https://mcuoneclipse.files.wordpress.com/2016/07/freertos-task-list.png?w=584&h=168 

The other option is to use the McuOnEclipse Shell component which lists all the tasks with their stack size and usage:

I hope this helps,

Erich

[justusandjustic]

Erich,

I will look into the options you have described.

Thanks again for all your help!

-Josiah

[mjbcswitzerland]

Josiah

A pre-emptive RTOS requires each task to have its own stack, which must be adequately large to be able to handle its own local variables, subroutine local memory use and interrupts (and possibly nested interrupts).  Although some things are possible in 4k it is probably too restrictive in most circumstances and so either you will need a larger chip or a slim-lined solution to allow much more to be done by optimal memory utilisation.

The following co-operative solution allow powerful projects in small memory:
http://www.utasker.com/kinetis/TRK-KEA64.html
http://www.utasker.com/kinetis/FRDM-KEAZ64Q64.html

Regards

Mark