Modem does not connect after Modem delta upgrade

[hjetschko]

Hi, we used the modem_delta_update example as a reference in our firmware to be able to do modem delta FOTA upgrades from an S3 bucket. We are currently using NCS V2.2 The upgrading works very well, we use it to upgrade modem firmware V1.3.3 to V1.3.4. The problem is that on some units the modem stops connecting to the LTE network after the upgrade. The modem still responds correctly to AT commands, but no matter what I try, it does not want to connect to LTE. I manually programmed modem firmware V1.3.3 and V1.3.4 to see if this will fix the problem, but no luck. Are there any non-volatile settings in the modem that could have been lost?

Thank you for your help.

Hubert

[Øyvind]

Thanks for providing the modem fw. Could you please redo test with both mfw 1.3.3 and 1.3.4? Please start modem trace and then reset board in order to see what happens before main. Could you please leave the trace running for a minimum of 20 minutes for each? This way we can ensure that the network is found and the connection progress is done completely.

Thanks

[hjetschko]

Hi Øyvind

Thank you for your help analyzing these files. I have done both 1.3.3 and 1.3.4 traces doing the following:

1. Started the RTT logging
2. Reset the nRF9160 firmware
3. Leave it running for 20 minutes

Please let me know if you need more information.RTTLogger_Channel_modem_trace_modemfw_1.3.3.logRTTLogger_Channel_modem_trace_modemfw_1.3.4.log

[Øyvind]

Unfortunately, the modem traces do not capture required information. Are you not able to collect modem traces via UART1? By default, nRF Connect SDK's modem library uses the UART1 peripheral for trace output

Still investigating.

[hjetschko]

Hi Øyvind

Thank you for your help. Our product used UART1 (lpuart) for communication to another micro. I moved it to another UART and made sure it works. UART1 should be free but I cannot get it to compile. This is the error I get when trying to use modem trace with UART1:

gen_isr_tables.py: error: multiple registrations at table_index 9 for irq 9 (0x9)
Existing handler 0x775a9, new handler 0x7d7c1
Has IRQ_CONNECT or IRQ_DIRECT_CONNECT accidentally been invoked on the same irq multiple times?

We do not call IRQ_CONNECT or IRQ_DIRECT_CONNECT from our code. Can you please give me advice about this?

[Øyvind]

hjetschko said:

We do not call IRQ_CONNECT or IRQ_DIRECT_CONNECT from our code. Can you please give me advice about this?

No, this is handled by the Zephyr OS interrupts kernel service. IRQ_CONNECT is used to initialize an interrupt handler. 

hjetschko said:

Has IRQ_CONNECT or IRQ_DIRECT_CONNECT accidentally been invoked on the same irq multiple times?

This explains what is happening in your project. If this is new, then you need to check what is causing this error. How did you move the lpuart to another UART?