RAK5860 (BG77) on RAK6421 — continuous reboot loop (RDY flood), never registers, reproduced across 2 modules / 2 boards

[wunM (Jamie Mortland)]

What product do you wish to discuss?
None of the listed options exactly — this isn’t a RUI3 core module setup. We’re using a RAK6421 WisBlock Pi HAT with a RAK5860 (BG77) LTE module plugged into its IO slot, connected to a Raspberry Pi 4B (not one of your core boards). Apologies if this needs to be routed to a different team — flagging in case the intake criteria are core-module-specific.

What firmware are you using?
Not RUI3 or Arduino BSP. We’re communicating with the BG77 directly via raw UART/AT commands from RAKPiOS (Debian Linux), using shell scripts + gpiod/libgpiod to toggle the WIS_PWRKEY GPIO and read /dev/serial0. No custom firmware or IDE involved — this is host-side scripting, not firmware on a RAK core.

What firmware version?
BG77 firmware: unknown — module is in a continuous reboot loop and hasn’t stayed responsive long enough to complete an AT+QGMR query. Happy to provide this if support can help us get a stable session first.

Computer OS?
Linux — RAKPiOS 1.0.0 (based on Debian 13/trixie)

What Computer OS version?
RAKPiOS 1.0.0, image date 20260807, kernel 6.18.39+rpt-rpi-v8

How often does the problem happen?
Every time, on every cold boot, across every hardware combination tested. Time-to-reboot-loop varies (anywhere from immediate to 65+ reboot cycles before occasionally settling), but the underlying instability has been 100% reproducible.

How can we replicate the problem?

1. RAK5860 seated in RAK6421 IO Slot 2 (also reproduced in Slot 1 using the corresponding pin)
2. Pulse WIS_PWRKEY GPIO high ~700ms (GPIO25 for Slot 2, GPIO17 for Slot 1, per RAK6421 datasheet pin table)
3. Wait ~12s, then open /dev/serial0 (ttyS0 on Pi 4, per RAK6421 quickstart) at 115200 baud
4. Module responds to some initial AT commands, then begins emitting repeated RDY (reboot indication) within seconds to tens of seconds
5. AT+CSQ when briefly responsive always returns 99,99; AT+CREG? always 0,2 (searching, never registers)

Commands:
gpioset -c gpiochip0 25=1
sleep 12
stty -F /dev/serial0 115200 raw -echo
exec 3<>/dev/serial0
printf ‘AT+CSQ\r\n’ >&3; sleep 1; timeout 3 cat <&3

Additional context / variables ruled out:

• Reproduced across two separate RAK5860 units and two separate RAK6421 boards
• UPS HAT removed, powered direct from wall via USB-C — no change
• meshtasticd (native to RAKPiOS image) stopped during testing to rule out shared-VBAT contention from LoRa TX — no change
• RAK12501 GPS module removed from Sensor Slot A to rule out UART contention — no change
• VBAT measured steady at 4.87–4.89V throughout, including during active reboot loop (measured at J8/J9 test points) — no sag observed
• gpiomon on the PWRKEY GPIO during idle: completely silent, ruling out floating-pin noise
• Tried holding GPIO26 high before pulsing GPIO25, based on a similar RAK5860 reboot-loop issue resolved on RAK19011 via correcting WB_IO1/WB_IO2 assignment (reference thread) — no change on the 6421
• we’re unable to query AT+QGMR (firmware version) because the module doesn’t stay responsive long enough to complete the command — it’s currently mid-reboot-loop as we prepare this report.

Questions:

1. Does the RAK6421 require a separate slot-power-enable signal distinct from WIS_PWRKEY (GPIO25/17), analogous to the WB_IO2 requirement found on RAK19011? If so, what’s the correct pin?
2. Is there a known reboot-loop issue with this BG77 firmware revision?
3. Is our power-on timing/sequence correct for the 6421 specifically?

Note: we found and read the WB_IO1/WB_IO2 fix in RAKwireless Support Request: RAK5860 (BG77) Constant Reboot Loop before posting, and attempted the equivalent on the 6421 (holding a second GPIO high before pulsing the documented WIS_PWRKEY pin) — this did not resolve the issue for us. It’s possible the 6421 uses a different GPIO than 26 for this purpose, or the underlying issue on our end is unrelated to a slot-power-enable pin at all.

[xoseperez (Xose Pérez)]

There might be two thing happening in parallel:

1. you are asserting PWRKEY but not de-asserting it, try something like gpioset -c gpiochip0 -t 700ms,0 25=1 (that’s a 700ms high pulse).
2. The OS is using the UART and that will explain the random behavior you are seeing. Remove console=serial0,115200 from the /boot/firmware/cmdline.txt file and add enable_uart=1 line to /boot/firmware/config.txt. Then reboot.

Try again and tell me if the modem behaves properly now.

[wunM (Jamie Mortland)]

That fixed it — thank you.

Both changes together resolved the reboot loop entirely. cmdline.txt/config.txt were already correctly set (we’d disabled the serial console via raspi-config earlier, which apparently doesn’t guarantee proper de-assertion), but the pulse syntax was the real gap — we’d been using timeout 0.7 gpioset ... & to fire-and-kill the process, which evidently doesn’t cleanly de-assert the pin the way -t 700ms,0 does.

After switching to:

gpioset -c gpiochip0 -t 700ms,0 25=1

the module booted with zero RDY reboots — completely clean. AT returns OK immediately, and AT+COPS=? sees multiple carriers (Verizon, T-Mobile) with good signal. Currently working through registration/APN config, but the core instability is fully resolved.

For anyone finding this later with a RAK5860 on a RAK6421 (Raspberry Pi HAT rather than a WisBlock core module): the fix is the same root cause as the RAK19011 case linked above, but on the Pi side the practical takeaway is — don’t use timeout <n> gpioset ... & to pulse WIS_PWRKEY. Use gpioset’s built-in pulse/toggle syntax (-t <duration>,<idle_value>) so the line is explicitly driven back down, not just abandoned when the process gets killed.

Thanks again for the fast, precise answer.

[wunM (Jamie Mortland)]

Update: fully resolved, thanks again.

After the -t 700ms,0 fix, the reboot loop was gone completely — module came up clean every time. But it stayed stuck at CEREG: 0,2 (searching, never registering) even though AT+COPS=? could see multiple carriers with good signal.

Turned out to be a second, unrelated issue: our AT+CGDCONT was left pointing at an APN from an earlier project on the same host (a USB dongle setup with a different APN), not our 1NCE SIM’s actual APN (iot.1nce.net). Once corrected:

AT+CGDCONT=1,"IP","iot.1nce.net"
AT+COPS=0

It registered within about 30 seconds — CEREG: 0,5 (roaming), CSQ: 14,99 (usable signal).

So for anyone landing here with a RAK5860 that’s stable (no more reboots) but still won’t register: check your APN isn’t left over from a different SIM/carrier config. Two separate root causes stacked on top of each other in our case — the reboot loop masked the APN issue entirely until it was fixed.

Thanks for the fast turnaround on this.