FreeRTOS ported to the PSoC 4

Correction: The CapSense component does not use SysTick; the issue was an unrelated interrupt issue.

I am having some issues that appear to be because the CapSense uses interrupt 15. You say it does not? However, if change interrupt 15 to point to the SysTick ISR in FreeRTOS, then it no longer works. Specifically, the Capsense_Start() function never returns.

--Isaac

The interrupt numbers should not be an issue. And CapSense is independent of SYSTICK.The issue with our CapSense software is that you must enable interrupts before calling CapSense_Start(). If you do not the software waits for a condition that gets set from an ISR that cannot fire, so it does not return. The macro to enable interrupts is CyGlobalIntEnable,so make sure your code is something like this...

CyGlobalIntEnable;

CapSense_Start();

We are fixing this problem in our next s/w release (and we will make sure the code you write today will still work once we make that change).

-- Mark.

I'm still concerned.

In my main code, I copy the interrupt handler address into vector 15 with:

CyRamVectors[ 15 ] = ( cyisraddress ) xPortSysTickHandler;

The xPortSysTickHandler is defined in port.c and is responsible for activating the scheduler.

The interrupt tab in my .cydwr file shows the capsense peripheral as using interrupt 15. Even with enabling interrupts before calling capsense_Start(), execution stops after FreeRTOS is started (and the new ISR is installed).

Isaac

Hello!

You are confusing exception and interrupt vectors. In the ARM architecture you have an internal SYSTICK exception that gets triggered by the M3. The handler for this has to be installed in slot 15 - the "exception" number for SYSTICK. The interrupts that are generated by the PSoC CapSense block are handled by the M3 interrupt block and, coincidentally, by "interrupt" number 15. CapSense is definitely not using SYSTICK and you are not clashing interrupts. PSoC Creator just happens to pick that number.

What I strongly suspect is happening here is that you are running out of SRAM. I had this same problem when I added CapSense to Nicholas' example. To determine if this is the case I recommend starting the debugger and putting a breakpoint at the beginning of pvPortMalloc() (this is line #95 in heap_1.c, but you may have elected to use a different heap file). Then run the code. Each time your application needs to grab memory it will break in this routine. Open the Call Stack window and you will see something like this.

The xWantedSize argument is the (decimal) number of bytes being requested from the heap. For each task you create this function is called twice - I am 99% sure this is for the task control block (a fixed-size piece of RAM to hold the task state, priority, pointer to the stack, and so on) and then for the stack that is allocated to the task. In the example you grab 68 bytes for the task control blocks and 400 bytes for the stacks. At some point you will see that the debugger stops hitting that breakpoint and your application is hung. Press the halt button (looks like a VCR pause button - if you are old enough to know what one of those is. Er, was). You will be in vApplicationMallocFailedHook().

So, if you do all that, and it does what I think it will do,you have a memory allocation problem. The good news is that it is easily fixed.

Firstly, be aware that PSoC Creator allocates default stack and heap for you. It allows you to set the size of these memory areas without having to learn about linker scripts and other unpleasantness! But, with an RTOS, the OS handles this stuff for you as well. You want to make sure you give as much memory as you can to the OS. So, open the "cydwr" file - the resources file in PSoC Creator - and find the System tab. In there you will see entries for the stack and heap size. Reduce the heap to 0 - I assume you are not using things like printf(). Reduce the stack to something very small. Start with 0x100 for now. That is plenty of room and you will be able to adjust that down later. This stack is only used by main() and the APIs it calls. As soon as the RTOS starts it will have used as much of this stack as it ever will so you can safely reduce the size and save space.

Next, take a look in FreeRTOSConfig.h and look for the following defines.

#define configMINIMAL_STACK_SIZE    ( ( unsigned short ) 100 )

#define configTOTAL_HEAP_SIZE        ( ( size_t ) ( 2048 ) )

The heap size gets used in a big array definition. This heap array is used to allocate that memory I wrote about above. You want to make it as big as you can. Experiment with it by making the size bigger and building the application. If you get too big you get errors like this from the linker "Build error: region RAM overflowed with stack". Remember that PSoC Creator also allocates the CYDWR stack (that I wrote about above) and your global variables and little bit of stuff for boot code - so you cannot just go to 4096 bytes (the total amount of RAM in that device), but you can get close to that number.

Next up,consider the minimal stack size. It is 100 - but those are longs, not bytes, so you are allocating a minimum of 400 bytes for every task. I think that is quite a lot for a minimum. Unless you plan to do a lot of computation in the IDLE task I would halve that - at least. The IDLE task is what runs when none of "your" tasks are doing anything. It typically does nothing and so you only need enough of a minimum stack to store the task's state. I have used 50 without issue.

Lastly, look at the tasks you are creating and the amount of stack they request. In Nicholas' code he has this:

xTaskCreate(vBlinkTaskGreen, (signed portCHAR *) "BlinkGreen", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY + 3, NULL);

There is nothing wrong with that but he is asking for 100 longs - 400 bytes! That is quite a big stack for a task that blinks an LED. Because I reduce my minimum stack to 50 I save a lot of space and can create more tasks - or ones that need a bigger stack. Please note that I am not criticizing the code Nicholas wrote here - he is expecting to add more interesting code to those tasks (or that you will) and so a little head room is a very good thing. I think you just happened to run out!

I hope this advice helps. With small devices like this you really need to be frugal with SRAM when running an RTOS. I would set the minimum for the IDLE task, and then think carefully about each of my own task's needs (setting the value in the xTaskCreate() call). It's good to go through the exercise I outlined here a few times, so you get the hang of things, and then it becomes quite easy to partition up your RAM in a real application. Happy scheduling!

-- Mark.

Wow!   Mark,  just a quick reply to say "Thanks" for the very well thought-out, thorough, and very informative reply you gave to Isaac.  That is the sort of technical depth that is nice to see in these postings.

PS: I started playing with the FreeRTOS port myself. 

Nice,  ;-)

-- Richard

Wow!   Mark,  just a quick reply to say "Thanks" for the very well thought-out, thorough, and very informative reply you gave to Isaac.  That is the sort of technical depth that is nice to see in these postings.

PS: I started playing with the FreeRTOS port myself. 

Nice,  ;-)

-- Richard

I'd like to second that thanks, and apologize for not doing so earlier. I have put that project on the back burner for the time being, and haven't given it much thought.

Thanks!

Isaaac