Timer issue: triggers immediately and never repeats

I am testing coding with RUI and I found my code didn’t work.
I noticed that the timers trigger immediately and repeating timers never repeat.
I then wrote some simple testing codes (included at the end) with a clean project and verified that the problem persists.
Please help investigating/pointing out whether I have configured anything incorrectly.
I am using RAK811 Version: with the online compiler

// global variables
RUI_TIMER_ST test_timer;
uint32_t interval = 5;
void timer_callback() {
    RUI_LOG_PRINTF("Timer callback interval: %lds\r\n", interval);
// in main() before loop
RUI_LOG_PRINTF("Preparing timer\r\n");
test_timer.timer_mode = RUI_TIMER_MODE_REPEATED;
rui_timer_init(&test_timer, timer_callback);
rui_timer_setvalue(&test_timer, interval);

Expected result: UART1 prints “Preparing timer” immediately, then prints “Timer callback interval: 5s” every 5s.
Observed result: UART1 prints “Preparing timer” then “Timer callback interval: 5s” immediately

Hi @rlui . Welcome to RAK forum :slight_smile:

Regarding your question,

Can you try to change the interval to (interval*1000)?

I suspect that you trigger immediately because instead of 5sec, your timer trigger at 5mS.

Oops my bad
Regarding the simple test code,
I copied the wrong code. It was indeed 5ms.
But setting
test_timer.timer_mode = RUI_TIMER_MODE_REPEATED;
still have no effect.

Regarding my main testing code,
it was already *1000. I will check it again and see what went wrong.

How many timers can be used simultaneously on RAK811?
I was actually using 2 timers in the main test code to

  1. trigger reading data from UART3 which is written into a buffer during rui_uart_recv()
  2. trigger writing data to UART3 periodically to request data from external devices

Now I have rewritten the simple test code to test the timer based mechanism and remove as many source of error as possible.
And I found that triggering the read timer during the write timer would triggers “hard fault exception” with messages as the following:

Firmware name: stm_xx, hardware version: v1.0.0, software version: v1.1.0
Fault on interrupt or bare metal(no OS) environment
===== Thread stack information =====
  addr: 20007ec0    data: 00000080
  addr: 20007ec4    data: fffffff9
  addr: 20007ec8    data: 01800100
  addr: 20007ecc    data: 8b850101
  addr: 20007ed0    data: 00000000
  addr: 20007ed4    data: 200006f2
  addr: 20007ed8    data: 20007e94
  addr: 20007edc    data: 08005be5
  addr: 20007ee0    data: 08005bd8
  addr: 20007ee4    data: 61000000
  addr: 20007ee8    data: 08003030
  addr: 20007eec    data: fe797f0e
  addr: 20007ef0    data: ffa8c560
  addr: 20007ef4    data: 0e7f79fe
  addr: 20007ef8    data: 0a112020
  addr: 20007efc    data: 01000000
  addr: 20007f00    data: fa4e34b0
  addr: 20007f04    data: 604ad5da
  addr: 20007f08    data: 58a13992
  addr: 20007f0c    data: 22a0cd54
  addr: 20007f10    data: ffa8c560
  addr: 20007f14    data: 0e7f79fe
  addr: 20007f18    data: ff091fac
  addr: 20007f1c    data: 110823f9
  addr: 20007f20    data: ffa8c560
  addr: 20007f24    data: 0e7f79fe
  addr: 20007f28    data: ff091fac
  addr: 20007f2c    data: 110823f9
  addr: 20007f30    data: 05000000
  addr: 20007f34    data: 0258f500
  addr: 20007f38    data: 00010001
  addr: 20007f3c    data: 00000000
  addr: 20007f40    data: 00000000
  addr: 20007f44    data: 00000000
  addr: 20007f48    data: 00000000
  addr: 20007f4c    data: 00000000
  addr: 20007f50    data: 00000000
  addr: 20007f54    data: 00000000
  addr: 20007f58    data: 00000000
  addr: 20007f5c    data: 00000000
  addr: 20007f60    data: 32395341
  addr: 20007f64    data: 02000033
  addr: 20007f68    data: 00007530
  addr: 20007f6c    data: 00010101
  addr: 20007f70    data: 00000000
  addr: 20007f74    data: 00000000
  addr: 20007f78    data: 00000000
  addr: 20007f7c    data: 00000000
  addr: 20007f80    data: 00000000
  addr: 20007f84    data: 00000000
  addr: 20007f88    data: 00000000
  addr: 20007f8c    data: 00000000
  addr: 20007f90    data: 00000000
  addr: 20007f94    data: 00000000
  addr: 20007f98    data: 00000000
  addr: 20007f9c    data: 00000000
  addr: 20007fa0    data: 00000000
  addr: 20007fa4    data: 00000000
  addr: 20007fa8    data: 00000000
  addr: 20007fac    data: 00000000
  addr: 20007fb0    data: 00000000
  addr: 20007fb4    data: 00000000
  addr: 20007fb8    data: 00000000
  addr: 20007fbc    data: 00000000
  addr: 20007fc0    data: 00000000
  addr: 20007fc4    data: 00000000
  addr: 20007fc8    data: 00000000
  addr: 20007fcc    data: 00000000
  addr: 20007fd0    data: 00000000
  addr: 20007fd4    data: 00000000
  addr: 20007fd8    data: 00000000
  addr: 20007fdc    data: 00000000
  addr: 20007fe0    data: 00000000
  addr: 20007fe4    data: 00000000
  addr: 20007fe8    data: 08003165
  addr: 20007fec    data: 08002a20
  addr: 20007ff0    data: 08002a20
  addr: 20007ff4    data: 00000000
  addr: 20007ff8    data: 00000000
  addr: 20007ffc    data: 08016b5b
=================== Registers information ====================
  R0 : 2000211c  R1 : 00000000  R2 : 00001860  R3 : 00000001
  R12: 40eb48ec  LR : 08016a4f  PC : 00001860  PSR: 20000039
Usage fault is caused by attempts to switch to an invalid state (e.g., ARM)
Show more call stack info by run: addr2line -e stm_xx.elf -a -f 00001860 08016a4b 08005be1 08003161 08016b57 
The Hard Fault exception occurs!

Hi Carl,

Is there any updates on the issue regarding:
a) timer doesn’t repeat even if timer_mode is set to RUI_TIMER_MODE_REPEATED, and
b) using 2 timers simultaneously on RAK811?

For (a), I can still work around it by restarting the timer in the callback.

For (b), I think I can work around it by using a counter to track the cycle with combination of (a).
But I still wish to retain as much time resolution as possible.
Is there any methods to acquire a timer value like in millis() in Arduino?
Would there be conflicts with RUI if I use SysTick as described in here ?

Hi rlui,

I am not the RUI expert but probably the sample Timer app that we have might be a good reference.

i have almost same issue at RAK811-H online compiler
my case is timer call-back interrupt can not serviced after LoRa Message sending at P2P mode
i think, last week did not occur this interrupt problem
Now I’m testing what’s the problem
Is there an API to know if timer interrupt is running?
Best Regards