NRF9151DK autonomous resets when simultaneously starting LTE connection and GPS on modem FW 2.0.2

[Sebastiaan Merckx]

I have updated a board (NRF9151DK) from modem FW 2.0.1 to 2.0.2. The board is also equipped with nrf7002-EK, and the support for the wifi driver is enabled (SB_CONFIG_WIFI_NRF70, SB_CONFIG_WIFI_NRF70_SCAN_ONLY, haven't verified if this makes a difference).

The previous version of the application works fine, in which we initialize the modem at startup, and simultaneously initiate an LTE connection and activate the internal GPS. On the new 2.0.2 firmware, this simultaneous action results in an autonomous reset, which can be fixed by e.g. adding a 100msec sleep before activating the internal gps. The same problem occurs on other devkits too (observed on 2 out of 2).

I mainly want to notify you of this difference, because I'll not be the only person suffering from this. I leave it up to you to consider if a fix is possible.

I can try out alternative solutions if necessary.

Best regards,

Sebastiaan

[Susheel Nuguru]

The first thing that comes to my mind when you say autonomous resets is that this should be trackable. Can you put a breakpoint in the sys_reboot() function, run the application in debugger and let the breakpoint hit. When you look at the function call stack at this point it will give us more context on why this is happening and we can take it from there on how to avoid or workaround.

[Sebastiaan Merckx]

Hi Susheel,

I rather think this is a brownout reset. The function sys_reboot() is never hit.

[Susheel Nuguru]

Sorry for late response. Then you should be able to read the reset reason

If you see 0x00000004 then it is a brown out reset and then we need to see if your power source is stable.

[Sebastiaan Merckx]

Are you sure this command exists? I can't find it in the documentation https://docs.nordicsemi.com/bundle/ref_at_commands_nrf91x1/page/REF/at_commands/intro_nrf91x1.html and I also couldn't get it to work, it returns ERROR while e.g. "AT%DEVICEUUID" does provide a response.

[Susheel Nuguru]

Sebastian, I am sorry, I got this from a forum thread which seemed logical but it does not look like this AT command will work on our product.

You can manually print the reset reason as done in many other samples like below.

static void print_reset_reason(void)
{
	uint32_t reset_reason;

	reset_reason = nrfx_reset_reason_get();
	LOG_INF("Reset reason: 0x%x", reset_reason);
}

[Sebastiaan Merckx]

The reset reason seems to be watchdog. Verified by nrfx_reset_reason_get and hwinfo_get_reset_cause function.

Indeed, watchdog is enabled. But it's initialized with a task configured with a timeout of 5 seconds, whereas the device resets way faster than 5 seconds. I've made sure that watchdog init and feeding is started before anything else, but that doesn't help anything.

It seems to me that GPS initialization tampers with the watchdog and that results in a reset, that's the best conclusion I can draw so far. Removing the main task from watchdog control (so that there's no task whatsoever under WD control), or not initializing the watchdog at all seems to prevent the issue, but that's not sufficient.

BTW I also have a callback registered to the watchdog, which should print if it expires (in the normal way, this has been verified) and that print is also not taking place.

If you want, I could try to strip down my code to a bare minimum and share it? I'm not new to using NRF91, but this seems like a strange problem and I don't think it's due to my code.

[Susheel Nuguru]

That seems strange that you are feeding the WDT in time and still it resets before the 5 seconds timeout expires. Can you toggle a gpio everytime you feed the WDT to see if the context you are feeding it is getting CPU in time or if that context is masked by some other high priority contexts? 

After you GPIO toggle test, if you think the feeding is still in time, then yes, please give me a minimalistic project that I will look into early next week.

[Sebastiaan Merckx]

The GPIO toggling is not very relevant, the reset occurs even faster than that (rather 1.5 to 2 seconds).

A more or less minimal reproduction codebase can be found at https://drive.google.com/file/d/1ivy9eGtTYCgckw6WrWdGo_HJNOSL1UGk/view?usp=sharing. Let me know once you downloaded it so I can remove it again.

This is for nrf9151, it's reproducible without sim card, you also don't need nrf7002.

It doesn't matter if you set GPIO's to IO-expander (via board configuration tool) or keep them on GPIO.