RUI3 (RAK3172) with `AT+LOCK` – timer/loop behavior changes?

RUI
1

I’m working with a device running RUI3 on a RAK3172.

Setup / Architecture

I have a function that communicates with an external device over UART.
Since the communication can be blocking, I’m not running it directly inside the timer callback.

Instead, the timer callback only sets a flag, and the main loop checks that flag:

  • If the flag is set → run the UART communication function
  • If the flag is not set → go to sleep using api.system.sleep.all();

Observed behavior (unlocked)

When the device is unlocked, the timer interrupt/event wakes the device up, and after the timer callback runs, the main loop continues, so the communication function is called at the expected times.

Behavior after locking

However, after locking the device using AT+LOCK the communication function no longer seems to run.

I’m not sure whether this is because:

  • the timer callback is no longer being executed, or
  • the main loop is no longer running after wakeup, or
  • sleep/wakeup behavior changes when locked.
  • Serial1 is also locked.

Question

Is AT+LOCK expected to change behavior related to:

  • main loop execution
  • timers / wakeup sources
  • low power behavior (api.system.sleep.all())
  • UART peripheral behavior

If this is expected, what is the correct approach for running timer-triggered blocking UART communication while the device is locked?

Any guidance would be appreciated.

Thanks!

2

How did you initialize the UART that communicates with your external device?
Which UART are you using to connect to the external device?

AT+LOCK locks ALL UARTs that are setup as (e.g.) Serial.begin(115200) or Serial1.begin(115200) the UART is in RAK_DEFAULT_MODE == RAK_AT_MODE

After AT+LOCK none of the UARTs that are set in AT command mode can be used until you unlock them again.

You can avoid this by using (e.g.) Serial.begin(115200, RAK_CUSTOM_MODE ) or Serial1.begin(115200, RAK_CUSTOM_MODE)

Using RAK_CUSTOM_MODE disables AT commands on the specified UART. So be careful, you should not use it on SERIAL (UART2), or you will not be able to send AT commands anymore or update the firmware.

3

I was using: Serial1.begin(2400, SERIAL_8E1)However, even changing it to: Serial1.begin(2400, SERIAL_8E1, RAK_SERIAL_MODE::RAK_CUSTOM_MODE)
does not solve the problem.

Are you sure the default mode for Serial1 is RAK_AT_MODE?
From what I see, it is defined as:

#define DEFAULT_SERIAL_UART1_MODE       SERVICE_MODE_TYPE_CUSTOM

Adding the following code before using the UART fixes the issue:

    if (service_nvm_get_lock_status_from_nvm(SERIAL_UART1) == SERIAL_WLOCK_LOCKED) {
        service_nvm_set_lock_status_to_nvm(SERIAL_UART1, SERIAL_WLOCK_OPEN);
    }

Is there a way to prevent the custom UART from being locked without using internal APIs?