We have recently purchased the new RAK3172**-T** modules. Three of them were already onsite at our client. I have noticed that after 4 days of continuous operations, all the 3 RAK3172-T modules stopped working (nearly at the same time). The modules have the same firmware and use the same code based on RUI3 API. Below are the device parameters.
Lorawan, EU868
ADR - ON
DR - defined by the network
Default module tx power.
send messages based on events.
21:31:36.503 → AT+SN=AC1F09FFFE0AED44
21:31:36.503 → OK
21:31:44.583 → AT+VER=RUI_4.0.5_RAK3172-T
21:31:44.583 → OK
21:31:50.384 → AT+CLIVER=1.5.10
21:31:50.384 → OK
21:31:56.155 → AT+APIVER=3.2.6
21:31:56.155 → OK
21:32:03.803 → AT+HWMODEL=rak3172T
21:32:03.803 → OK
21:32:12.530 → AT+HWID=stm32wle5xx
21:32:12.530 → OK
21:32:21.681 → AT+BOOTVER=RUI_BOOT_0.7_STM32WLE5CC
21:32:21.681 → OK
I was onsite today to intervene, I tried resetting the module with No success. I then powerOFF and then powerON the device and only this time the RAK3172-T was able to connect to TTN.
Note: I have already deployed some of the devices in different locations it’s been 2 days already, and 1 of them already stopped working.
I don’t know if this is related to Timer Mode, correct me if wrong, code as shown below.
Can I have a few more details?
I guess the RAK3172-T is running as stand-alone MCU on a custom PCB?
Can you share more details of your code? You say event driven, so I guess your loop() is empty?
Is it only waking up on the timer events or are there other events that can wake up the device (external interrupts)?
I have multiple RAK3172 (not -T) running for weeks only waking up by external interrupt (door open/close) and timer. I will try to run a test with your 30 minutes timer settings.
The firmware of the RAK3172 and RAK3172-T are basically the same, the difference is only in the setup for TCXO and oscillator.
Your timer setup looks ok, I don’t see a problem there.
Greetings, thanks for your swift response as usual
Yes, you are right, the RAK3172-T module is running as standalone (without a host MCU) on a custom PCB.
I am using both the timer and external interrupt, but my devices are configured as class C which is always ON. so in my case there is no wake-up from deep sleep.
I don’t have much in the loop() it is very simple. below is the extract of the loop().
I am constantly monitoring the same on my side, see the below snapshot I have another device that is currently down after 4 days of continuous operation (it’s been 2 hours since the device is down).
@Avishek I think I am experiencing the same problem as you do with the RAK3172. I had mine not respond after 156 cycles (4 minutes) and I am 90% sure that the timer failed to create or start.
In my application, I am using 2 timers with fixed IDs to run
A periodic sample timer at 100 Hz
A one shot sampling duration timer with 60 seconds duration
Both set a flag in ISR which gets processed by the main loop.
Additionally, I added a blink of the LED in the main loop.
What I observed is a blinking LED that lasts longer than 60 seconds and no output on Serial from the periodic sampling timer. Looks like the flags are never set and the system is stuck in the main loop.
I implemented some retry and recovery logic now. Hopefully this fixes the problem.
Let me gather some more insights on this problem. If there is a problem at all. Maybe I am doing something wrong here and some other wakeup source is causing this problem.
I am working on removing as much as possible to make a minimal example.
So this is all based on a recent (latest) version of RAKWireless/RAK-STM32-RUI. Please correct me if I am wrong.
However, he specified some build flags here and there -DLORA_STACK_104 -DLORA_IO_SPI_PORT=2 -DSYS_RTC_COUNTER_PORT=2 -DATCMD_CUST_TABLE_SIZE=64 -DWAN_TYPE=0 -DLORA_STACK_VER=0x040700 -DSOFT_SE -DSECURE_ELEMENT_PRE_PROVISIONED -DLORAMAC_CLASSB_ENABLED -DSUPPORT_SPI -DSUPPORT_AT -DRUI_SDK" which I still need to check.
Max’s work looks like a good toolchain for PlatformIO but work in progress (I guess?).
I deployed a node with RAK3172 and RUI3 4.2.0 on it which has been running fine for a week.
I could not investigate this issue any further. I am using this code right now to retry timer creation and starting. Although, I don’t know if it is actually being used or not since I did not integrate monitoring for this.
void createAndStartTimerWithRetries(RAK_TIMER_ID timerID, RAK_TIMER_HANDLER handler, RAK_TIMER_MODE type, uint32_t period, void *arg)
{
const int maxRetries = 5; // Maximum number of retry attempts
const int retryDelayMs = 100; // Delay between retries in milliseconds
int retryCount = 0; // Current retry attempt
bool timerStarted = false; // Flag to track success
while (retryCount < maxRetries && !timerStarted)
{
// Attempt to create the timer
if (api.system.timer.create(timerID, handler, type) == true)
{
// Attempt to start the timer
if (api.system.timer.start(timerID, period, arg) == true)
{
timerStarted = true; // Success, exit the loop
}
else
{
Serialport.printf("[%d] Starting timer #%d failed on attempt %d.\n",
millis(), timerID, retryCount + 1);
// If start fails, the timer will be recreated on the next iteration
}
}
else
{
Serialport.printf("[%d] Creating timer #%d failed on attempt %d.\n",
millis(), timerID, retryCount + 1);
}
if (!timerStarted)
{
retryCount++;
if (retryCount < maxRetries)
{
delay(retryDelayMs); // Wait before the next attempt
}
}
}
// Check if all retries failed
if (!timerStarted)
{
Serialport.printf("[%d] Failed to create and start timer #%d after %d attempts. Rebooting...\n",
millis(), timerID, maxRetries);
Serialport.flush();
delay(100);
api.system.reboot(); // Reboot the system
}
}
