Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF52+SDK13 Reset Issue

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 

Parents
  • 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

  • Thanks Kenneth, we have tried all of the above including a minimum viable build of our board but it has not resolved the issue.

    I should also add that since posting the initial problem, the firmware on many of the devices isn't running at all. They are still programmable with JLink however.

    We are also exploring the possibility that the nRF chip revision may be incompatible with SDK13 since SDK12 works fine on our boards. The reason for this is because the PCA10040 (0.9.0) experiences similar behaviour with SDK13 (because it is incompatible). 

    Our firmware and SDK13 works perfectly fine on the newer PCA10040 (1.2.1) which has a chip revision: QFAAB0-1740JK.

    Our hardware is using: nRF52832 QFAAB0-1729HH. 

    Do you think SDK13 incompatibility might be a possibility?

    Thanks

Reply
  • Thanks Kenneth, we have tried all of the above including a minimum viable build of our board but it has not resolved the issue.

    I should also add that since posting the initial problem, the firmware on many of the devices isn't running at all. They are still programmable with JLink however.

    We are also exploring the possibility that the nRF chip revision may be incompatible with SDK13 since SDK12 works fine on our boards. The reason for this is because the PCA10040 (0.9.0) experiences similar behaviour with SDK13 (because it is incompatible). 

    Our firmware and SDK13 works perfectly fine on the newer PCA10040 (1.2.1) which has a chip revision: QFAAB0-1740JK.

    Our hardware is using: nRF52832 QFAAB0-1729HH. 

    Do you think SDK13 incompatibility might be a possibility?

    Thanks

Children
No Data
Related