Not able to flash custom board with nordic nrf52840 DK unless the reset pin tied to NRF_VDD

[Kalrz]

Hallo,

IDE: Segger Embedded Studio

nrf52840 DK

Custom Board with ProteusIII

I have designed a custom board with ProteusIII (nrf52840 SoC) and was working with the board for the past 1 month. Recently in the middle of nowhere, the custom board cannot be flashed using the nrf52840DK anymore unless the reset pin from the custom board is held high using a jumper. 

Please find the error log below:

Connecting ‘J-Link’ using ‘USB’
Connecting to target using SWD
Loaded C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 5.10a/bin/JLink_x64.dll
Firmware Version: J-Link OB-SAM3U128-V2-NordicSemi compiled Mar 17 2020 14:43:00
DLL Version: 6.80a
Hardware Version: V1.00
Target Voltage: 3.300
Device "NRF52840_XXAA" selected.
InitTarget() start
InitTarget() end
InitTarget() start
InitTarget() end
connect failed
Failed to connect to target.
No idcode detected.
Please check connection and Target Interface Type

I am able to flash other boards using nrf52840 DK (Evaluation board from ProteusIII). I had programmed many times without the use of reset pin. Now each time, I need to provide high voltage to reset pin in order to flash the chip properly.

How do I resolve this issue? Is there anyway to reset the chip to its previous configurations? 

Thank you

[Håkon Alseth]

Hi,

 

I am able to flash other boards using nrf52840 DK (Evaluation board from ProteusIII). I had programmed many times without the use of reset pin. Now each time, I need to provide high voltage to reset pin in order to flash the chip properly.

It sounds like you are using P0.18 as a GPIO, and either pulling it low (input + pull-down) or setting it as output low; while having P0.18 configured as nRESET.

Are you using P0.18 in your firmware?

 

To use P0.18 as a generic GPIO, you have to ensure that preprocessor define "CONFIG_GPIO_AS_PINRESET" is not set. In case it is already set explicitly in the UICR area, issue a "nrfjprog -e" to erase the UICR area before programming your firmware that tries to use P0.18 as a GPIO.

 

Kind regards,

Håkon

[Kalrz]

Hallo Hakon, 

Thanks for the quick reply. 

Håkon Alseth said:

Are you using P0.18 in your firmware?

I am not using P0.18 in my firmware. I also flashed a blinky example from SDK with reset pin held high. Then tried to flash it again, disconnecting the header wire from reset to nrf_vdd. This time it does not flash and gave the same error log. 

I do not wish to use reset pin as GPIO. In the preprocessor directive, "CONFIG_GPIO_AS_PINRESET" is set. 

Are there any methods to reconfigure the nrf52840 SoC to its initial configuration? 

Håkon Alseth said:

issue a "nrfjprog -e" to erase the UICR

Would this method work? I am not vey comfortable with command lines. Can you please explain this a bit more clearly?

Thank you

[Håkon Alseth]

Hi,

 

Kalrz said:

I am not using P0.18 in my firmware. I also flashed a blinky example from SDK with reset pin held high. Then tried to flash it again, disconnecting the header wire from reset to nrf_vdd. This time it does not flash and gave the same error log. 

I do not wish to use reset pin as GPIO. In the preprocessor directive, "CONFIG_GPIO_AS_PINRESET" is set. 

Are there any methods to reconfigure the nrf52840 SoC to its initial configuration? 

Then it sounds like the issue is else-where.

Are you powering your external board with a 3.0V source?

I usually provide VDD_NRF and GND from the nRF52-DK, to ensure that the voltages are equal on custom board and the DK.

Kalrz said:

ssue a "nrfjprog -e" to erase the UICR

Would this method work? I am not vey comfortable with command lines. Can you please explain this a bit more clearly?

This method will erase the flash on your device, and all the flash content will be empty.

Open up a command line prompt, enter "nrfjprog", and a help screen will be printed.

 

Note that this requires that you have already installed the nrf command line tools:

https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Command-Line-Tools/Download

 

Kind regards,

Håkon 

[Kalrz]

Hallo Hakon,

Håkon Alseth said:

Are you powering your external board with a 3.0V source?

I am powering the board from the DK to match the NRF_VDD voltage (just like you!)

Håkon Alseth said:

Open up a command line prompt, enter "nrfjprog", and a help screen will be printed.

I followed the instructions and erased the flash. 

Even now the command "nrfjprog -e" is producing an error when the reset pin is floating. When tied to VDD, i am able to erase the flash but this does not solve the problem. 

I have to mentioned this behavior started all of a sudden. I was flashing the custom board from morning and now it is no more possible without the reset pin been held high externally. 

best regards,

[Kalrz]

Just an add on:

1. Yes the board is detected in the device manager.

2. The board is powered by a lipo 3.7 V battery. An LDO output of 2.8V is provided to the SoC. 

3. The board was never run above the limits mentioned in electrical specifications.

4. DK is functioning properly since I just flashed programs to a second custom board successfully. 

5. No significant changes were made in the previous firmware and also tried flashing sdk examples. 

Any suggestions are invited. 

Thank you

[Håkon Alseth]

Hi,

 

Kalrz said:

I have to mentioned this behavior started all of a sudden. I was flashing the custom board from morning and now it is no more possible without the reset pin been held high externally. 

This is very interesting.

Do all custom boards behave similarly, or is it only one board that misbehaves?

What is the voltage level of the nRESET pin on the faulty board? meaning; is there any reason why it should have to be forced to VDD?

 

Kind regards,

Håkon

[Kalrz]

Hallo,

Håkon Alseth said:

Do all custom boards behave similarly, or is it only one board that misbehaves?

It is just one board that misbehaves.

Håkon Alseth said:

What is the voltage level of the nRESET pin on the faulty board? meaning; is there any reason why it should have to be forced to VDD?

I did not measure the voltage level of the RESET pin. I should have done that first. But pretty sure it was not VDD. May be way too less to be recognized as an high level. (But again, I did not measure it and I feel so bad since I didn't). 

Again today morning after 3 days i power up the board and successfully flashed firmware using DK. Strange. Reset pin reads a voltage of VDD without forcing it to be (externally). 

Now the problem is resolved but is quite disappointed that I was not able to find the root course. I think it might happen in the future as well. Might be quit a good idea to connect reset pin to VDD with a 0 ohm resistor in the final design of my board.

What do you think?

best regards,

Karlz

[Håkon Alseth]

Hi Karlz,

 

Kalrz said:

I did not measure the voltage level of the RESET pin. I should have done that first. But pretty sure it was not VDD. May be way too less to be recognized as an high level. (But again, I did not measure it and I feel so bad since I didn't). 

Don't worry too much. If it happens again, it would be interesting to see what the voltage is on the reset pin.

 

Kalrz said:

Again today morning after 3 days i power up the board and successfully flashed firmware using DK. Strange. Reset pin reads a voltage of VDD without forcing it to be (externally). 

Since this only occurred on one board, it might be a small speck of solder-tin that caused problems for all we know.

If this exact issue happens on several boards; the problem might link to design-wise problems.

 

Kalrz said:

Now the problem is resolved but is quite disappointed that I was not able to find the root course. I think it might happen in the future as well. Might be quit a good idea to connect reset pin to VDD with a 0 ohm resistor in the final design of my board.

 What I would recommend is to check on several of your boards, and see if this issue appears on more than one board. If that is the case, more in-depth investigation is needed. nRESET pin has internal pull up, so in normal use-cases; there's no need to add a hard connection between VDD and nRESET.

 

Kind regards,

Håkon