Device not booting up after SystemOff (NRF52840)

[AGeegee]

NRF52840

We are using NCS v3.3.0, however this issue occurs also on NCS 3.0.0.

When using the SoftDevice Controller stack. ie MPSL etc enabled, at times we enter SYSTEMOFF without calling bt_disable and mpsl_unit.

There is a chance that our device does not seem to wakeup again when using the GPIOTE PORT Detection. It's a simple switch used to wake up the device and it works 90% of the time it seems.

However, it seems that if we call:

bt_disable() followed by mpsl_lib_uninit(), the device seems to wake up all the time

Do you have any idea what could be going on?

When the device does hang, I attach a debugger to it without restarting the device and the PC register appears to be at the early stages of Init in Zephyr land generally. After which I hit 'RUN' and the device continues to boot as normal.

Thanks

[Kenneth]

Hello,

Not directly related to the problem, but there is a note in the datasheet that: "Before entering System OFF mode, all on-going EasyDMA transactions need to have completed."

So in general we do recommend that you have a safe/proper disabling everything before going to system off. But in this case I suspect that there may be some higher level interrupts occurring shortly before you want to go to system OFF, and indirectly reconfigure or change "something" that prevent wakeup from system OFF to work. So you might also at some point shortly before you go to system OFF disable all interrupts before you configure the hardware exactly as you want before going to system OFF.

Kenneth

[AGeegee]

Thanks for the quick reply.

Before entering SYSTEMOFF a call to __disable_irq is made. ISB and DMB for good measure too. Before the System goes off all interrupts are disabled and the GPIOs are setup for DETECT on LATCH.

If there are on going EasyDMA transactions, what would happen?

[Kenneth]

Hello,

So just so I don't misunderstand the flow, you are doing:

1.  __disable_irq is made. ISB and DMB for good measure too

2. the GPIOs are setup for DETECT on LATCH

3. Go to System OFF

Right? I just want to ensure you have not swapped step 1 and 2.

AGeegee said:

If there are on going EasyDMA transactions, what would happen?

Slightly undefined. Usually higher power consumption and partial transfer, but it may I guess also cause lockup.

Kenneth

[AGeegee]

Yes the steps are correct.

1. Disable IRQs

2. Setup GPIO

3. SYSTEMOFF

I would like to understand the situation where the lockup can occur, because it can cause our device to never turn back on.

As a test inserted a SPI EasyDMA Tx between 2 & 3, and it doesn't make the lockup any easier to reproduce.

[Kenneth]

Hi,

We don't really characterize behaviour that we specify should not occur. So we don't unfortunately have any data on the consequences.

Assuming this is pretty easy to replicate, can you maybe instead of going to system OFF in step 3, add an infinite while(1); loop.

Then run: python .\read_global_registers.py --all

To store the output to a file call: python .\read_global_registers.py --all  > file1.txt  

I assume you need to power cycle and do this several times, but it could be interesting to see if any of the readouts give any indication if some configuration differ from the other (e.g. indicating that if it went to system OFF it would not wakeup because pins are not configured as you expect)

7558.nrf52840.zip

Btw: Is the pin you configure as wakeup configured or used for anything else at any time?

Kenneth