• State Verified Answer
  • Replies 10 replies
  • Subscribers 65 subscribers
  • Views 750 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 323073
Options

Unable to recover nRF5340 flashed with invalid DCDC configuration

timonsku

I have a nRF5340 module from Fanstel that was flashed with a firmware where the DCDC weren't disabled.
The board does not have the necessary inductors for the DCDC to work (nor does it expose the pins) and the nRF53 is now in a constant power on reset loop.

There are several related issues like
Unable to recover a nrf5340 MCU after first flash on a custom board using nrf5340 DK
and
Unable to recover nrf5340 after flashing nrf9160 code on it. 

Unfortunately the tip with running nrfjprog --recover -f nrf53 in a loop did not work so far after having it do a few hundred tries.
Is there any lower level way that can be used to recover an device from an invalid power configuration or do I generally risk soft bricking a board with those settings?

The brute force solution is of course to transplant the module to a board with the DCDC setup but I would really like to avoid rework on this particular board if not absolutely necessary.

  • 0 in reply to Susheel Nuguru

    I think there is just a mixup here?

    Terminologies seem to just have changed between the nRF52 and nRF53?

    In any case if one of the engineers could give a pointer as to how to best recover the nRF53 from this situation or which power pin would be needed as a minimum to briefly keep it alive for a reflash that would be helpful for the future and probably also helpful as an app note.

  • +1

    Sorry for the mixup Timon, I continued to give you info for the nRF52.

    Now coming back to the details on nRF5340, 

    The idea is that the DCDC inductor is missing, so it can not power the corresponding DEC pin (supply output pin), similar to your case. 

    On the 53 series you have DCDC inductors for DECD which is on the application core side, and you also have DCDC inductors for DECR which is on the network core side.  Since it is the application it self that enables the DCDC, I assume it is enough to power the application supply externally (DECD) in order to flash a new application firmware that does not enable DCDC, One think we are not entirely sure is that maybe both DECD and DECN has to be powered if DCDC is enabled on both domains, and inductors are missing on both domains

    It's a good idea to have a current limiter on the external supply at 20 mA ish, to protect the regulator

    So in short try powering both DECD (and DECN just to be sure to power modem aswell) to bring the chip out of the non responsive state that occurred by enabling DCDC in firmware without necessary inductors for DCDC to work. 

  • 0 in reply to Susheel Nuguru

    Thanks for that info Susheel! That helps with future designs.

  • 0 in reply to timonsku

    Oh, one thing that would help is if the DCDC is not enabled by default in nRF Connect. It seems the Nordic DK's work with any configuration.
    My issue was that I only provided my own overlay for a sample code but did not add the KConfig options to disable the DCDC. My assumption would typically be that optional internal regulators are opt-in options and not opt-out.

  • 0

    Hi Timon

    Thank you for your feedback, but I don't think this will be changed in the SDK. The DCDC is enabled by default to showcase optimized power consumption in our sample projects by default. And since our samples generally are for the Development Kits, where the DCDC components are mounted, that will be what we're testing for. I think this will stay as an opt-out thing.

    Best regards,

    Simon

Related