RTX osTimerStart() interval short

[sunaba]

Hi! I'm trying to learn osTimerStart(), \ble_app_hrs_rtx. Compiling was successful, and it is working. If I set the timer interval shorter than 25 ms, the timer cycle becomes abnormally short. The cycle of other timers also becomes short.Is this a specification?

For example //#define RR_INTERVAL_INTERVAL 300 #define RR_INTERVAL_INTERVAL 10

[Petter Myhre]

What SDK are you using? What do you mean by abnormally short? Could you elaborate a bit?

[sunaba]

I am using MDK-ARM , s130_nrf51_2.0.0-7, Example \ ble_app_hrs_rtx \ pca10028 \ s130 \ arm5 \ ble_app_hrs_rtx_s130_pca10028.uvprojx

Usually, rr_interval_timeout_handler() is a 300 ms repeating timer. However, if I create a short cycle timer in main () as below, the cycle will be 264 ms.

OsTimer1_id = osTimerCreate (osTimer (osTimer1), osTimerPeriodic, NULL);
OsTimerStart (osTimer1_id, 10);

I found, This phenomenon does not occur if I rewritte os_idle_demon () to "for (;;) ;".

[Petter Myhre]

Why are you using S130 2.0.0-7.alpha? It doesn't have SDK support. I recommend using a production version of the SoftDevice with SDK support. For example SDK 12.2.0 with S130 v2.0.1. Maybe you could try that and see if the behavior is the same?

[sunaba]

I launched Keil MDK-ARM and downloaded "ble_app_hrs_rtx" via the Pack installer. I understood that you say, this process is out of support. When using the same experiment using nRF5_SDK_11.0.0_89a 8197 (s130_nrf 51_2.0.1 _softdevice.hex), and project file is \nRF5_SDK_11.0.0_89a8197\examples\ble_peripheral\ble_app_hrs_rtx\pca10028\s130\arm5_no_packs\ble_app_hrs_rtx_s130_pca10028.uvprojx, the same phenomenon occurred. rr_interval_timeout_handler () is repeated 284 ms. And if I rewrite os_idle_demon () "for (;;);", this phenomenon does not occur.

[sunaba]

I found a strange thing in the os_idle_demon () description. If os_tick is less than 2, the CPU executes "os_resume (expected_time)" without experiencing __WFI ();   The argument of the os_resume function is slept time. In this case 0 is correct. For example, if os_tick is 2, does os_tick count up by two more?