nrf9160: Modem error: 0x4, PC: 0x7ef22

RE: nrf9160: Modem error: 0x4, PC: 0x7ef22

ClemensG — Thu, 09 Feb 2023 22:31:37 GMT

No worries. It was a bit of a ride but finally works.

Thanks for the support!

RE: nrf9160: Modem error: 0x4, PC: 0x7ef22

Michal — Thu, 09 Feb 2023 18:45:39 GMT

Thank you for the feedback.

I am sorry to hear that. I understand your frustrations, but unfortunately, modern embedded devices with complex communication protocols are also causing a big increase in software complexity and the choice was made to use Zephyr as the base of our SDK.

If you feel satisfied with your workaround then I think we can close this ticket, otherwise the lack of modem trace is unfortunately blocking possible deeper debugging.

Best regards,

Michal

RE: nrf9160: Modem error: 0x4, PC: 0x7ef22

ClemensG — Thu, 09 Feb 2023 11:18:24 GMT

Hi Michal,

unfortunately I do not have a trace. It happened in a long run experiment after one week where I just logged my debug output. I then used a custom modem error handler that just resets the system. I have 24 units running for a few weeks now (somewhere out in the nature running on batteries, so no trace collector attached) and I have seen three resets due to modem errors but do not know the error code or PC for them.

I know it does not help you but may help others: For me adding resets (watchdog triggering when not receiving anything for time x, reset on modem error) finally made the thing "reliable". It is ugly but during development I came across so many (undocumented or documented at places you don't look at while dealing with the Zephyr API) reasons things could go wrong that I decided to go this way. Not the best for battery life, absolutely not my favorite style of programming but works.

I came from a FreeRTOS world, where I tried to cleanly deal with errors that could happen in the system while trying to avoid complex scenarios (like dynamic memory allocation) and get things as error free as possible. Just alone that Zephyr adds so much complexity makes this approach impossible. My personal opinion on that: For these small, low power devices, with this small processor (with limited peripherals), Zephyr and all these layers are a complete overkill and unmanageable in a clean way. Especially for the intended applications: small low power devices (with low complexity in their task) that may run for years.

Best regards,

Clemens

RE: nrf9160: Modem error: 0x4, PC: 0x7ef22

Michal — Wed, 08 Feb 2023 09:13:37 GMT

Hello again,

Would it be possible to get a modem trace anyway?

It looks like it is a blocking thing in that case.

Best regards,

Michal

RE: nrf9160: Modem error: 0x4, PC: 0x7ef22

Michal — Mon, 12 Dec 2022 03:54:05 GMT

Hello Clemens,

Sorry for the delay, I will look more into it.

Best regards,

Michal

RE: nrf9160: Modem error: 0x4, PC: 0x7ef22

ClemensG — Sun, 04 Dec 2022 20:19:09 GMT

Hmmm.... I am sending one packet (UDP) each minute. I guess adding 200ms delay somewhere might not help. Or is there some kind of a race condition while sending a single packet (haven't looked at the code where you added the delay)?

RE: nrf9160: Modem error: 0x4, PC: 0x7ef22

wasan — Fri, 02 Dec 2022 04:39:52 GMT

Hi Clemens,

I have an issue similar you. Error memory 0x04 appeared in my code. I think there is a problem with the modem's firmware or library.

I'm trying to fix this problem by adding a 200mS delay to the function. It can make sending data less likely to go wrong.

sdk 2.1.2 > nrf > lib > nrf_modem_lib > nrf_modem_os.c

void *nrf_modem_os_shm_tx_alloc(size_t bytes)
{
    extern uint32_t nrf_modem_lib_shmem_failed_allocs;
    void * const addr = k_heap_alloc(&nrf_modem_lib_shmem_heap, bytes, K_NO_WAIT);

    k_msleep(200);
    if (IS_ENABLED(CONFIG_NRF_MODEM_LIB_MEM_DIAG_ALLOC) && !addr)
    {
        nrf_modem_lib_shmem_failed_allocs++;
    }

    return addr;
}

Note:

The signal strength in my area is about -70 dBm. If your signal is less than -100. I think you should add more than 200mS to the delay.

I hope that the Nordic support team will find out what's going on soon

Wasan

RE: nrf9160: Modem error: 0x4, PC: 0x7ef22

ClemensG — Wed, 30 Nov 2022 20:41:43 GMT

Okay, had a bit time to look into this (from user side).

As outlined here i can define my own modem fault handler. Guess saving data and rebooting is the safest option for me.

Also couldn't reproduce that error, yet.

So in case it still is interesting to Nordic to hunt something down I am happy to help, otherwise I can live with it.

As with most of the stuff I am discovering I mention it here again: I would love to see a general document/manual/best practices writeup of how to get a robust solution. I would not have looked down into the modem_lib documentation as I thought this is "just" a middle layer and I use it through the zephyr interface. Yes, now that I know what to look at I see it's applied in some samples.

RE: nrf9160: Modem error: 0x4, PC: 0x7ef22

ClemensG — Tue, 29 Nov 2022 11:15:37 GMT

Ah, forgot to mention:

the lte_handler() installed is roughly the same as in the udp sample. So every event handled there should be visible in the log but there is nothing.

Also no special messages from that handler after the last successful tx+rx (besides: "RRC mode: Idle.")