Modem FW 1.3.4 Error 0x10

[mrks115]

Hey,

we're currently testing our devices with Modem FW 1.3.4 / nRF Connect SDK 2.2.0 and have observed the following error:

00:01:37.478 <inf> app_event_manager: e:modem_module_event REQ_DISCONNECT (timeout = 30, lte_lc = offline)
00:01:38.236 <err> nrf_modem: Modem error: 0x10, PC: 0x7ce68
00:01:38.236 <err> lte_lc: Failed to set functional mode. Please check XSYSTEMMODE.
00:01:38.239 <inf> nrf_modem: Modem has faulted, re-initializing

• LTE-M
• Connection was successful before, no other issues
• Data was transferred
• GPS was used in-between
• No PSM/eDRX
• State before error: RRC connected

Does this information help you in any way?
If not, what details will help you further?

Kind regards
Markus

[Achim Kraus]

With almost 4 decades of software development, trying to catch a sporadic error as this one (once in a couple of weeks) in a "black box approach" (without the sources to see potential causes and be able to focus tests on that) is a waste of time. In my opinion, this make only sense with sources and the possibility to focus on some weakness or obscurities. With that someone may have a chance to catch it. So, it's up to Nordic and your software development to go for it. Or not.

Therefore my question, if It's generally possible to downgrade from 1.3.4 to 1.3.3. ?

(Just to mention: therefore I gave up reporting such very rare or long term issues. With the Nordic policy of "user provided logs" that doesn't make sense and is very ineffective.)

[mrks115]

Regarding this error I also won't investigate further. Seems to be not reproducible.

I'm happy to help where I can, but I also want to emphasize what Achim Kraus  is saying. As a developer, if I see a bug on my desk by chance, I'm glad to provide a modem trace. On field test devices or when colleagues report such an error to me, I unfortunately don't always have the opportunity to reproduce it and I see Nordic as being more obliged here.

[Didrik Rokhaug]

Hi, and sorry for the late reply.

I understand that it is not always easy/practical/possible to gather modem traces, especially for devices out in the field.

However, it is not always possible for us to recreate the same conditions in a lab, or even know what the conditions were. There can be quite a lot of differences in how a cellular network is configured, and sometimes, the problem is caused by the network itself.

We do test our modem FW in different networks, to try to avoid network specific problems, and to test the modem FW in different environments. But, even within the same network, there might be differences between different regions, or even between different cell towers. So it is not possible for the testing to account for everything.

Where did you experience these problems (the more specific location, the better. If you don't want to post the location here, you can send it to me in a private message)? We are currently planning a new field-test trip, and might be able to visit that location to try to reproduce this problem.

Best regards,

Didrik

[emdi]

Hello Achim Kraus , as long as you have the _original_ patch you updated from, you can rollback.

If you have updated the device over the air using `nrf_modem_delta_dfu` APIs, it is possible to rollback as long as you don't erase erase the modem firmware patch (using `nrf_modem_delta_dfu_erase()`).

The rollback process is documented here: Delta firmware updates — nrfxlib 2.4.99 documentation (nordicsemi.com)

[Achim Kraus]

My question is about using the official Nordic download of the modem firmware.

e.g. the modem was updated to 1.3.3, but I feel, it's better to got back to 1.3.2.

I use normally the "nRF Connect for Desktop => Programmer" and a Jlink.