NRF9151 replaces NRF9160: LTE not working any more

[AraNRF91]

Greetings,

we developed a custom board with a NRF9160 last year to be used with NB-IoT (LTE-M as Fallback) to communicate over HTTPS with our Servers. Now this worked quite well and without any problems, every LTE Connection built up and established in under 10 seconds.

Now with the change from the NRF9160 to the NRF9151 we adjusted the Driver to what was written as changes in the new Documentation (new RX/TX length of modem, UICR, internal Clock, CFUN=1 after config,...). We are using the embassy-net-nrf91 Rust driver. But the NRF9151 does not get any connection to any LTE provider. We can clearly communicate fully with the modem and also get all information from the Sim-Card (no eSim) and do all AT-Commands with correct/possible Responses. The NRF9160-Board still works with the new firmware but not the NRF9151, and it takes now about 30 seconds to establish a connection. 

Now the question is: What has to be changed for the driver or hardware to get the new Board with the NRF9151 working as this is the only hardware changed in the whole process? Are there changes in the LTE-Provider-Call setup or similar?

You can take a look at the patched Rust driver at https://github.com/embassy-rs/embassy/pull/4098 (currently dirty PR, needs rebase cleaned). The driver is based on the nrf_modem_lib.c et.al.

Edit: working on Ubuntu Linux 24.04.2 LTS with VSCodium 192.2, rustup 1.28.1, rustc 1.85.1, embassy at 141c170d + Patch

[Hakon]

Hello,

there are a lot of changes from the nrf9160 to nrf9151. Have you checked the antenna/RF design? The nrf91x1 use a different modem firmware than nrf9160. You have not provided much information other than linking to a 3rd party Rust driver, so it would be nice if you could tell more about what you have done.

[AraNRF91]

Hello Hakon,

thanks for your reply.

The antenna/RF design was adjusted by our hardware engineer according to the documents provided with the nrf9151.

And the list of changes from nrf9160 to nrf9151 to get it halfway working:

• UICR:

/// Ensures that the UICR registers that control the HF clock source
/// are properly initialized. On the nRF9151, the modem expects to use the internal oscillator,
/// so HFXOSRC must be 0. If the registers are erased or misconfigured, they are updated
/// and the system resets to apply changes.
let so = unsafe { read32(UICR_BASE + HFXOSRC_OFF) };
let co = unsafe { read32(UICR_BASE + HFXOCNT_OFF) };
let bad = so != 0 && so != 0xFFFF_FFFF;
let erased_so = so == 0xFFFF_FFFF;
let erased_co = co == 0xFFFF_FFFF;

if bad || erased_so || erased_co {
    warn!("Fixing UICR");
    ... set UICR values

• set HfclkSource and LfclkSource to internal RC clock as it would otherwise look for a external RTC
• then comes initialising the modem and network
  • init IPC Mem at 0x2000_0000 and init modem and network driver with the embassy_net_nrf91::new lib
  • spawn modem task for IPC and state management
  • spawn net task for network I/O with default driver settings and 8 available sockets
  • spawn control task to set APN+Pin
  • getting some Modem/Sim Infos to verify connection (AT+CGMM, AT+CIMI, AT%XICCID)
  • after that i call "wait_config_up" of the library, as this attaches the modem to the LTE network and then responds with a result if we get a connection with IP+DNS from the provider. At this point the nrf9151 runs eternally without any connection. the nrf9160 with the same setup and Sim gets one.

And changes done in the embassy_net_nrf91 lib:

• verifying SHMEM/SPU Region size at init for length be 8kb-aligned & greater 0 & in the lower 128kb of RAM
• adding a variable RX Control length and RX Data length. Those were hard written for 16b for the nrf9160 but with the nrf9151 we got 32b. Now the lib reads the lengths from the modem itselfs and uses the provided ones, either 16b or 32b
• adding trace logs for AT notifications of the modem

I hope this helps in understanding the changes. One of the open questions is still if other things changed in the process? I worked trough the Modem logs, Documentation and nrf-modem-lib.c but could not identify any other related changes.

Also i will clean up the provided patch today to make it easier to verify

[Hakon]

Okay, it is hard to say exactly why your modem does not connect. A lot of the changes are internal information and can not be shared publicly. If you can provide a modem trace, I will ask the modem team for assistance.

[AraNRF91]

that would be great. What should be included in the modem trace? i can toggle there trough various options in the lib

[Hakon]

What should be included in the modem trace is everything from start to finish of a network search. We need to see what is happening when the modem is unable to find the network.

[AraNRF91]

i created a full log from starting the lte test application with setting up IPC and configuring everything for the modem to the whole "wait for lte connection" until the timeout after 60secs; it also includes the modem trace, marked with "modem trace:" as well as the libraries modem traces.

As the log is too big for posting it here, i added it at lte_standalone_nRF9160_xxAA_1749196801820_channel0.txt

[Hakon]

Can you please provide a modem trace in the format .mtrace or .bin?

[AraNRF91]

i gathered the modem trace as mtrace and the regarding full log again here:

nrf9151_lte_example_nRF9160_xxAA_1750233445688_channel0.mtrace

nrf9151_lte_example_nRF9160_xxAA_1750233445688_channel0.txt

as i experimented further with the modem and AT commands i found, that using "AT+COPS=?" for searching operator cells nearby draws 6 times the usual current but while setting CFUN=1 and waiting for attach the modems power draw does not change in comparison to CFUN=0? Are there any other commands or functions to be activated to power on the modem for CFUN=1?

Also while working on a improved lib with extended tracing and capability to extend the AT usage, we found that only very few already have a NRF9151, which is why approving and verifying is certainly very hard. We will get a nrf9151-DK to test on it in the next weeks.

[Hakon]

AraNRF91 said:

i gathered the modem trace as mtrace and the regarding full log again here:

Thanks, what modem firmware is this captured with?