FP kernel crash stm32F4 discovery

[Frank]

Hi All,

I have a question about using Erika on the STM32F4 discovery board.

background info:
I have 5 task defined within the oil file, all of them have different priorities and a shared stack other then that, the "schedule" property is "FULL".
In my application (media streaming application) I send data from my laptop to the board over UART. Also, I'm using Fixed Priority scheduling

The problem:
when I fire up the board everything runs fine, and
I can see (using UART/leds) that all the 5 tasks are executed on time regarding the period (or cycle).

Now what happens, is that after a short period of time (few seconds) the board stops responding and hangs completly. When I debug the application this is my result:

#1 <signal handler called>
#2 0x0800028e in MyFunction (
imageBuffer=0x2000000c <MyBuffer> "\003", new_block=0x54532030)
at ../application_func.c:9
#3 0x08000dd2 in FuncTask_node_rp () at ../code.c:277
#4 0x08001ce4 in EE_std_run_task_code (tid=1)
at some_path/ee_files/pkg/cpu/common/src/ee_context.c:55
#5 0x08001c92 in EE_cortex_mx_change_context (tid=1)
at some_path/ee_files/pkg/cpu/cortex_mx/src/ee_context.c:54
#6 0x080016c6 in EE_cortex_mx_pendsv_ISR ()
at some_path/ee_files/pkg/cpu/cortex_mx/src/ee_gnu_change_context_isr.S:229
#7 0x080016c6 in EE_cortex_mx_pendsv_ISR ()
at path_to_erika/plugins/---Type <return> to continue, or q <return> to quit---
some_path/ee_files/pkg/cpu/cortex_mx/src/ee_gnu_change_context_isr.S:229
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

where MyFunction is a function from my application and MyBuffer is a globally defined buffer.

Worth telling is the fact that when I change the priority of the 5 tasks in such a way that they are all the same (for example all priorities are "5") then the application does not hang.

As far as I can make up from the stack-trace I think that the board crashes on the moment of a context-switch, My guess so far is that, because the task hasn't finished execution yet, it gets preempted.
But the stack size is not sufficient enough and then the board crashes, could this be the case? and if so, how to solve this?

If you need some other information let me know.

Best regards,
Frank

[e.guidieri]

As you suggested thi seems a stack corruption problem or a concurrency problem, since it doesn't happen without preemption. Wich compiler are you using? GCC?

If yes, you can try to increment the default Stack Size (0xC00 bytes) with OIL CFLAGS=-D__STACK_SIZE=<number_greater_than_default_stack_size>. (I don't know if there an OIL field for that, because I didn't find documetation about, and I didn't make the porting).

If enlarging stack size won't fix your problem, it's a concurrency problem, you shall find the shared data structure that can be accessed in concurrent way and protect it with a RESOURCE or suspendin interrupts (I suggest the resource approach, formally more correct and better for interrupt latency).

Errico

[Frank]

Thanks for your reply e.guidieri,

Yes i'm using GCC, I tried increasing the stack by adding "D__STACK_SIZE=128" to the "CFLAGS" property int he oil.conf-file but when i look at the memory-map generated (c_mX.map) by eclipse I cannot see any increase in the size... are you sure this is the right way to increase the stack-size?

Also a bit more background information about my project, I'm using FP as a scheduler, but not in every case my schedule is feasible. This means that according to the Rate-monotopic theory, i will miss deadlines. This brings up the following question about erika for me:

When a schedule is not feasible (on preemptive scheduling), and task miss their deadlines... how will erika respond to this? in other words, can there be multiple instances of a task within the ready-queue? for example, when I have a task and it has to be released every 5 os-ticks, but the time a single run of that task takes 10 os-ticks... will there be another instance of that task? or will it (after 5 ticks) assume that the task has finished? and use the same memory sector for that new release of the task? if so, this would explain my problem ^^.

Frank

[paolo.gai]

A task is never present twice on the stack.

if you are in overload and you activate a task a lot of times, the "pending" activations will be counted inside the "nact" counter, up to a limit.

On BCC2/ECC2 the number of pending activations is limited and specified in the OIL file. Note that the BCC2/ECC2 kernel maintains the order of activations as specified by the OSEK/VDX standard.

I hope this helps...

PJ

[e.guidieri]

Paolo already responded to you according multiple TASK's activation (RUNNING max one (until the end), READY+RUNNING less or equal than "nact" (number activation) value, modifiable by TASK.ACTIVATIONS OIL filed) .

Regarding the stack size I made a mistake pointing the work around for enflating the stack. The Stack is declared in a .S file ($(ERIKA_FILES)\pkg\mcu\st_stm32_stm32f4xx\src\startup_stm32f4xx_gnu.S) so you shall use the ASFLAGS=-D__STACK_SIZE (don't forget the dash...).

Plus I checked that the standard way to declare the "system stack size" do not work for stm32F4 and GCC for now. (RT-Druid correctly generate correctly the standard EE_SYS_STACK_SIZE in eecfg.h, but startup code look for another macro (__STACK_SIZE)).

Code: Select all

  CPU_DATA = CORTEX_MX {
      ...
      SYS_STACK_SIZE = 256;
      ...
  };

Regards,
Errico

[Frank]

Hi guys,

Thanks for the replies. This makes everything a lot more clear to me =).

A task is never present twice on the stack.

Oke so there can be no more then 1 instance of a task present within the kernel? and if a task is released while the previous execution has not finished yet, it will increase a number (this 'nact') do determine how many times it should have fired before current execution is that right?

I hope this helps...

^^ yea it does

Best regards,
Frank

[e.guidieri]

I found a introduction to OSEK, maybe it will help to understand better the execution model (in particular TASK "Run to Completion" and multiple activation).

http://www.algonet.se/~staffann/developer/rtbasics.htm