nRF9160's RX no longer receiving data

[Mikael Jansson]

We've designed our own board based on nRF9160 for main CPU w/ LTE and an nRF52 for BLE. Using BMP for debugging.

I've successfully run several boards through the production process:

- update modem firmware to 1.3.6

- use nrfcredstore to generate certs for use with Azure IoTHub w/ at_client (pre-built merged.hex and zephyr.elf from v2.5.2 that has always worked).

- upload firmware

Everything working great and successfully deployed. These cards were produced and installed around new year 2025/206.

------

Then one of our boards in the field suddenly "lost" its DPS.  I started working on that. Eventually, I realized I had to regenerate the certs to provision the device again. 

So: flashed pre-compiled at_client as part of my provisioning script, but then all went wrong:

- USB-TTL said "the device does not respond to AT commands. Flash at_client"

- console output in Minicom is correct, "Booting nRF Connect"-, "The AT Host sample started", "Ready" -- so TX from board to PC works.

- tried another USB-TTL adapter of the same brand -- note: both have been working previously. (Waveshare TTL/485/422 w/ separate header for TTL, set at 3.3v).

- changed cables, tested with multimeter that there's a connection between TX-terminal on USB-TTL and RX-pin on board.

- did a minicom cross-connection test with USB-TTL RX<->TX, worked

- wrote a small test program that toggled LED when state of the RX pin was modified, which works, so there is no problem with the connection.

- wrote a small test program with IRQ for UART RX. same for polling UART RX.

- wrote a small test program that sent AT commands to the modem (internally) and printed out the communication on serial port ie. minicom, so I know AT->OK, AT+CFUN?->CFUN: 0, etc. works - ie. modem fw good.

- rebooted

- tried another computer

- tried another board. and another. and another. and another.

But the exact same results -- nothing on RX. What gives? I have no idea how to continue from here :(
And each of these boards *did* work just a few months ago, haven't touched them. Obviously cannot update modem firmware either.

macOS, MacBook M1 Pro, if that matters.

[Einar Thorsrud]

Hi,

If I read this correctly you have verified UART communication with other test firmware, but it fails with the AT client? Can you double check that you have built the AT client for your board with the correct UART pins?

[Mikael Jansson]

Hello,

It turns out I have the intelligence of a monkey! See, my nRF52 on the board is cross-wired on UART, and I thought I had loaded a blank nRF52 FW file, setting all pins to hi-z. Well, turns out that if your DTS file sets up UARTs and SPIs and whatnot, they most definitely won't be hi-z even though you have a main() {}. :-)