Initialization problem and bricked nrf52833 with nrf connect sdk

Hi,

I'm working on a custom board based on PCA10100, nrf52833 but it seems to be stuck at the function "lfclk_spinwait".

my custom board does not have an external LFCLK.

The crazy thing is, after exiting debug mode my nrf52833 is bricked, I cannot recover, erase or flash anything on device.

I followed this issue:  Initialization problem

and added the CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y" to your prj.conf which solved the problem.

Some additional data:

  • SDK:  NCS v2.0.0
  • FW: blinky sample.

The full call stack in the image below:

The custom boards are in production ready level, passed QA and work perfectly fine with my application using nrf5 SDK.  In nrf5 SDK if I were to configure my LFCLK incorrect, i would not brick devices to a level were i cannot recover.

Appreciate you look into this.

thanks

Dan

Parents
  • You need to set the correct lfclk source (that is available for the design) in the project, else the code will freeze/hang during initialization (waiting for a lfclk source to start), however this does not explain the below issue:

    The crazy thing is, after exiting debug mode my nrf52833 is bricked, I cannot recover, erase or flash anything on device.

    Are you sure you have not enabled pin reset by some mean, and that the pin reset is pulled low? This could explain this issue. Try to connect the pin reset pin to VDD to see if the boards can allow reprogramming then. If that didn't help, it could be interesting to measure VDD on the board, to check the voltage.

    Best regards
    Kenneth

  • Hi,

    I am using the nrf52833 overlay / I also tried a new board

    1. HW: p.0.18 is not connected to anything. see design below.

    2. i did not add defines in prj.conf like CONFIG_GPIO_AS_PINRESET

    3. I did not touch PSELRESET[n] registers that are in default set to p0.18

    4. this is all done on a clean blinky example, the only thing i had to add to the prj.conff is the CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

    here is a similar schematics from nrf52833 product specification document:

    you can see that design does not have external pull up / down resistor.

    our design is the same.

    VDD is 3v connected directly to SoC as suppose to be, there is nothing much to see here.

    reset pin we have no access, no test point. on this 0,3mm pitch BGA so that's not an option either.

    never had issues on nrf5 SDK.

    Thanks

    Dan

  • Do I understand it correctly that the "bricked" boards are still "bricked", meaning you have found no way to recover them? Not even using "nrfjprog --recover" from command line?

    Kenneth

  • Okey, the only reason I am aware of is that you have by accident program some project that had the pin reset enabled. I have seen multiple of these cases, and they have all been related to pin reset. In such case there is no way to recover the boards without access to the pin reset pin, so for future I suggest to route out the reset pin to a test point so you can test for it/recover. I don't see any way for us to help you with this issue unfortunately.

    Best regards,
    Kenneth

  • 1)

    By default these registers are configured to be disconnected..

    when we erase or recover with nrfjprog before a program, (that's what west/ncs does) doesn't the UICR get erased too?

    2)

    and if these register were by mistake enabled, and pin 0.18 is configured to nRESET function.

    I still don't understand what does that have to do with not being able to recover and flash?

    thanks

    Dan

Reply
  • 1)

    By default these registers are configured to be disconnected..

    when we erase or recover with nrfjprog before a program, (that's what west/ncs does) doesn't the UICR get erased too?

    2)

    and if these register were by mistake enabled, and pin 0.18 is configured to nRESET function.

    I still don't understand what does that have to do with not being able to recover and flash?

    thanks

    Dan

Children
  • Dan_Y said:

    and if these register were by mistake enabled, and pin 0.18 is configured to nRESET function.

    I still don't understand what does that have to do with not being able to recover and flash?

    If pin reset is enabled, and the pin is low, e.g. due to shorted/connected to ground and/or set low by the application, then the chip will enter reset state, when in reset state the chip is not in any valid operation that allow any code to execute or any debugger to be connected through the SWD interface.

    Best regards,
    Kenneth

Related