Skip to content

troubleshooting.md

Latest commit

 

History

History
104 lines (74 loc) · 4.01 KB

troubleshooting.md

File metadata and controls

104 lines (74 loc) · 4.01 KB
Raw

Troubleshooting

A symptom‑first index of every dead end we hit, and the actual cause.

The module powers off / resets every ~15 seconds

Cause: the PWRKEY line (BCM GPIO4) is floating, so it "presses itself" and the module cycles on→off→on forever. This is not a power fault, even though it looks identical to one.

Fix: hold GPIO4 low. Add gpio=4=op,dl to /boot/firmware/config.txt and reboot. Runtime test: pinctrl set 4 op dl should make it stop.

No response to AT at all

Work through these in order:

  1. Send AT twice. The first command after opening the port often gets no reply while the module auto‑baud‑syncs.
  2. Wrong baud. Try 57600 first (not 115200) on the PL011. Fix it with AT+IPR=57600. Use scripts/modem_raw_capture.py to watch raw bytes at different baud rates.
  3. You're on the mini‑UART. ls -l /dev/serial0 — if it points to ttyS0, Bluetooth isn't disabled and the baud is unstable. Add dtoverlay=disable-bt, reboot, confirm it's ttyAMA0.
  4. The serial console still owns the port. Disable the login shell on serial (raspi-config → Serial Port) and remove console=serial0,... from cmdline.txt.
  5. The module is actually off. Press the physical PWR button, or pulse GPIO4 (scripts/modem_power.sh) and wait ~15 s for it to boot.
  6. Something else holds the port. sudo lsof /dev/serial0 — a stray pppd or another process can block it.

AT works, but it never registers (+CEREG: 0,2 / NO SERVICE)

  1. It's scanning every band (can take ~20 minutes). Lock your carrier's band: AT+CBANDCFG="CAT-M",28 (Telstra AU B28), then AT+CFUN=0 / AT+CFUN=1. This is the usual culprit.
  2. Wrong RAT. AT+CMNB=1 for Cat‑M1 (default is often NB‑IoT). AT+CNMP=38 for LTE‑only.
  3. Antenna — on the MAIN (cellular) connector, not GNSS, and rated for your band. Test near a window / outdoors.
  4. SIM not provisioned for the tech. A consumer SIM is usually fine for Cat‑M1 but not for NB‑IoT (which needs an IoT‑data SIM). A rejected attach shows as EMM cause 12 in AT+CEREG? detail.
  5. Verify the SIM is alive: AT+CPIN? → READY, AT+CIMI returns an IMSI.

It registers, then drops repeatedly / the whole Pi reboots

Cause: the 5 V rail sags under the module's ~2 A TX current spikes.

Fix: the 1000 µF capacitor mod across VCC/GND, and/or a stronger 5 V supply / separate HAT feed.

Remember: vcgencmd get_throttled = 0x0 does not clear the supply of suspicion — the sags are too fast to latch the flag.

AT+CSQ returns 99,99 even though it's registered

Normal on some SIM7080/7028 firmware. Use AT+CEREG? as the health signal, not CSQ. Enable unsolicited registration reports with AT+CEREG=2.

Registration reports (AT+CEREG=2) keep resetting to 0

The module rebooted (see the "resets every ~15 s" and "power sag" sections). A volatile setting reverting to its default is a cheap way to detect an unexpected module reboot. With a fixed baud you can also watch for the boot banner (RDY / +CFUN: 1 / +CPIN: READY) in the raw UART stream.

PPP won't come up

  • Make sure the module registers first — no point dialing on NO SERVICE.
  • nocrtscts in the peer file — the GPIO‑header UART has no RTS/CTS.
  • Match the peer file's baud to the module's fixed AT+IPR (57600 here).
  • pppd needs root; run via sudo, and it needs the serial port free (stop any AT session first — PPP and AT can't share the UART simultaneously).
  • Watch the chat in the log: journalctl -t pppd (or /var/log/syslog).

Useful one‑liners

# what is /dev/serial0 really?
ls -l /dev/serial0 ; pinctrl get 14 15 4

# full status snapshot
./scripts/modem_at.py "AT" "ATI" "AT+CPIN?" "AT+CIMI" "AT+CEREG?" "AT+CPSI?" "AT+CBANDCFG?"

# is the Pi rebooting unexpectedly? (short/odd boot durations = trouble)
journalctl --list-boots | tail