Is it necessary to add another task? If so, how?

My application on top of the Bluetooth part is requiring operations running for a couple of seconds. Currenty I use YAKINDU to generate a statemachine code for me and I “trigger” the statemachine from a timer callback every 10ms.

This works as expected unless I start a function that runs for a coule of seconds (e.g. it shows information on an attached LED display). The long running function uses a lot of Sys_Delay_ProgramROM functions to achieve the desired timing. If this function runs for about 2…3 seconds, the RSL10 resets.

I already tried to insert Sys_Watchdog_Refresh calls so the watchdog does not expired. But still the same effect.

I get the impression, that this long running function crashes something in the main APP task. Is it necessary to add another task for my purposes? If so, are their examples of a simple additional task?

regards
Michael

@mschmidl

You are trying to develop as if you had a multitask OS, but unfortunately the RSL10 kernel is just a simple scheduler. I must admit the word “task” (as described by RSL10 Firmware Reference) is confusing!

So, if you have a function that executes during several seconds and using several internal Sys_Delay_ProgramROM, you must be aware of the fact that no other application task can execute in parallel (only interrupt service routines can). Maybe this isn’t a big problem for your application, but it might be for system level (BLE stack in particular) as the internal timer expiry processing is deferred… It is difficult to tell what is the limit (300ms / 1s / 3s) as it depends on the configuration.

The correct way of thinking your application is to split your big function in several parts and make usage of kernel timers (instead of Sys_Delay_ProgramROM) to continue the processing… Kernel timers are in fact messages sent to the task on expiry. Between your applicative timers other events might also be processed among which some system events.

Even if your reset is not caused by the watchdog, it seems probably caused by a starvation of system events leading to unpredictable behaviors.

3 Likes