NRF52+SDK13 Reset Issue

[Ryan Farrelly]

Hello,

We are having a peculiar issue with the NRF52 and SDK 13 that I hope you might be able help with.

Having migrated from SDK 12 to SDK 13 with softdevice 4.0.2, we discovered that our custom boards began locking up and were unable to communicate with JLink. 

Following the initial flash, the application will run successfully. However, the boards will enter one of two states depending on the scenario as follows:

1. Scenario 1: Board is re-flashed. The application will not run unless a reset command is sent over JLink. In this state
2. Scenario 2: Battery power is removed or fully discharged. Following a recharge or re-attaching the battery power, the board is unresponsive, application does not run and cannot accept JLink commands. The only way to revive the board is to physically disconnect then reconnect the battery power.

Furthermore, this is a chip-down design which we have had verified by Andreas Bognøy at Nordic. Please bare in mind that this issue is not present using SDK 12 on the same hardware.

It is possible that this is a configuration problem but we aren't exactly sure. Any help would be greatly appreciated.

Thanks in advance.

Ryan 

[Kenneth]

Hi,

It is difficult to know exactly where the problem lies here, but the first I would have checked is in beginning of main() toggle an GPIO, to find if the nRF52 run any code for scenario1/scenario 2 or if the application stopp for unknown reason (e.g. assert).

Typically the CPU should be halted after programming, and you must call nrfjprog --run or --reset for the application to run, so I am not very surprised there. I assume the problem here is not that you have sensors that are not reset, and thereby you may end up in a situation where the nRF52 reset and the rest of the peripherals are in a configured state, which may give any random behaviour. Also you should check that when you power up, that you may need a delay in the beginning of main() in case the sensors you may have may need longer time to power up.

Best regards,
Kenneth

[Ryan Farrelly]

Hi Kenneth,

We have resolved this issue. It turns out that DCDC mode was enabled inside the softdevice init function. Because we don't have the required inductors in our design, this was causing the softdevice to fail.

What are the implications of not using DCDC mode in terms of power usage?

Many thanks