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

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.