nRF9160 Modem lock up

[RUL]

Hi

According to Case ID: 279868 it seems like there has been some issues with modem lock up on nRF9160.

Some questions:

Do you know if this issue is still valid on later FW versions / HW versions?

Do you know if modem lock up happens on real products in field or only on devices connected to a debugger?

Do you recommend to add circuitry on the PCBA for power cycling to get out of a modem lock up situation?

/BR RULU

[Håkon Alseth]

Hi,

 

According to Case ID: 279868 it seems like there has been some issues with modem lock up on nRF9160.

No, this is not a modem lock up. This is a returned EMM cause code #17 from the network to the UE, in which indicates a problem with the LTE network itself.

Problems like these should be reported to the specific network provider.

Do you know if modem lock up happens on real products in field or only on devices connected to a debugger?

What is important here is that you test within the scope of your application, meaning that if you plan to deploy in several countries; you test in all of these to ensure the operation of your product is within your expected tolerances (performance, power consumption, response time, etc.).

Do you recommend to add circuitry on the PCBA for power cycling to get out of a modem lock up situation?

Hardware-wise, you should always follow the latest reference design.

Also have a look at the guidelines for nRF9160 hardware and verification: https://infocenter.nordicsemi.com/topic/struct_nrf91/struct/nrf91_guidelines.html?cp=2_0_6

Software-wise, in addition to the former comment related to generic testing of your application, you should consider always enabling the mobile termination errors: https://infocenter.nordicsemi.com/topic/ref_at_commands/REF/at_commands/mobile_termination_errors/mob_termination_errors.html?cp=2_1_8

I would also recommend having a look at this white paper:

https://infocenter.nordicsemi.com/topic/nwp_044/WP/nwp_044/intro.html?cp=17_0

 

Kind regards,

Håkon

[RUL]

 Hi

The ref designs do not have any HW functionality for power cycling of the modem.

You mention that it is important to test 'within the scope of your application' to avoid issues.

So is there a risk of modem lock up if we haven't tested everything 100% and do something 'illegal'?

FYI: We have encountered modem lock up during development with the debugger attached.

The only way of getting out of the situation is to re-boot the product.

We don't want to have this behavior in a real product.

/BR RUL

[Håkon Alseth]

Hi,

 

RUL said:

So is there a risk of modem lock up if we haven't tested everything 100% and do something 'illegal'?

There is a larger chance that the application, which interacts with the modem, locks up in some way.

You can for instance use the watchdog to ensure that you're reset if something goes wrong.

 

RUL said:

FYI: We have encountered modem lock up during development with the debugger attached.

The only way of getting out of the situation is to re-boot the product.

Could you elaborate on what happened in this case?

 

Kind regards,

Håkon