nrf52840 P0.25 is pulled up before application starts

RE: nrf52840 P0.25 is pulled up before application starts

hmolesworth — Fri, 01 Dec 2023 21:22:51 GMT

I ran the same test on an nRF52840 and don't see the pull-up enabled on P0.25. So .. is it possible your chip supplier is providing parts with software such as a bootloader or manufacturing test sequence already installed? Maybe that software has a pull-up enabled on that pin; a full chip erase would remove that if so on the off-chance that hasn't been tried already..

RE: nrf52840 P0.25 is pulled up before application starts

and0792 — Fri, 01 Dec 2023 15:28:29 GMT

Thank you for the insights, I will have a look at those phantom power/back-drive discussions you mention.

Nevertheless, I ran a test with a completely different board that never had an external device connected and where, in fact, P0.25 is not connected to anything. I put a breakpoint on the _start entry point and on main() and what I see is P0.25 being pulled up.

Also, power to the external device is given by a power switch that is enabled by a nrf52 gpio (and also has an external pull down resistor) which means that the external device should be powered up after the nrf52. This power switch is activated when the enable pin goes high.

As a workaround, I put an external pull-up resistor on the power switch and everything worked fine. The drawback is that I will have static power consumption when the enable pin is low and this is something I'd like to avoid.

RE: nrf52840 P0.25 is pulled up before application starts

hmolesworth — Fri, 01 Dec 2023 04:18:59 GMT

Thanks, that's helpful. I see now that the MOSI signal is from the external device driving into the nRF52 pin P0.25, in which case this looks like a classic phantom power issue, where P0.25 is powering up the internal VDD of the nRF52 via the nRF52 internal schottky clamp diode sufficiently high such that the nRF52 reset function fails to correctly operate when nRF52 VDD is turned on. This is a known issue with most MCUs. The effect is likely to have damaged P0.25 such that it no longer behaves normally and may indicate the pull-up enabled (not sure about that). The only solution to phantom power of this nature is to isolate the MOSI signal by either ensuring no power is applied to the external device until the nRF52 has correctly reset or to insert a buffer (aka level-shifter even if voltages are similar) which is enabled by the nRF52 VDD and thus blocks the MOSI signal until nRF52 VDD is established.

"I can plug the external device after flashing (meaning that the MCU has enough time to run the code that properly configures all the pins) and all is good" - to clarify my comments this issue is unrelated to the nRF52 programming the pins, it is simply that the nRF52 reset function will not work with phantom power applied prior to nRF52 VDD rising. In this particular case the pin maay already be damaged; maybe test a new board but ensure nRF52 VDD rises before the external device VDD.

Searching the devzone for "Phantom power" and "back-drive" should highlight other discussions regarding this.

nrf52832-io-problem - I suggested a buffer in this thread; I use this buffer on our design.

RE: nrf52840 P0.25 is pulled up before application starts

and0792 — Fri, 01 Dec 2023 03:43:24 GMT

Sorry, I try to clarify.

I am working with a PCB (which I designed) that has an nrf52840 on it. This PCB also has a header that can be used to plug an external device and communicate with it through SPI.

I use Segger to flash the firmware and before flashing I can be in either one of these two different cases:

1- no external device is plugged

2- an external device is plugged

In case 1, the MCU boots up perfectly fine and everything works as expected. I can plug the external device after flashing (meaning that the MCU has enough time to run the code that properly configures all the pins) and all is good.

In case 2, the MCU doesn't boot up and no code is executed. After a few tests I realized that if I left the pin of the external device that is connected to P0.25 floating, the MCU boots up and the code is executed as it should.

So I ran this test:

- I plugged all the pins of the external device except the one that is connected to P0.25

- I set a breakpoint at _start as well as one at the main() function

- I flash the firmware

- I run the code

- the program counter stops at _start

- I look at the PIN_CFG[25] and I see that P0.25 has it's internal pull up activated

- I measure the voltage on P0.25 and I see it is high

-I click on the play button to continue executing the code

- the program stops at main()

- I measure the voltage on P0.25 and I see it is high

- I look at the PIN_CFG[25] and I see that P0.25 has it's internal pull up activated

This is where the "Upon inspecting the code and the register banks with Segger, I noticed that PIN_CFG[25] is initially configured as a pull-up" comes from.

Then I ran this test:

- I plugged all the pins of the external device including the one that is connected to P0.25

- I set a breakpoint at the _start entry point as well as one where you suggested in your previous comment and one in main()

- I flash the firmware

- I run the code

- the code never stops at any of the breakpoints

I ran one more test:

- I plugged all the pins of the external device but this time I avoided using P0.25 and used a different gpio instead

- I flashed the firmware and everything worked fine

It seems clear to me that the problem is on P0.25 which, for some reason, is the only pin that, when the system boots up, has its internal pull up enabled.

I hope it is clearer now.

RE: nrf52840 P0.25 is pulled up before application starts

hmolesworth — Fri, 01 Dec 2023 02:12:55 GMT

er .. how do you know the MCU doesn't "boot up" and not just hang in the reset sequence? If the MCU didn't boot up, where did "Upon inspecting the code and the register banks with Segger, I noticed that PIN_CFG[25] is initially configured as a pull-up" come from? Are there two MCUs? An outline circuit would help ..

RE: nrf52840 P0.25 is pulled up before application starts

and0792 — Fri, 01 Dec 2023 01:33:39 GMT

Hi hmolesworth,

the MCU doesn't even boot up, it would never reach the breakpoint.

RE: nrf52840 P0.25 is pulled up before application starts

hmolesworth — Thu, 30 Nov 2023 17:34:07 GMT

Just checking, are you setting the breakpoint before inits and errata handling? If not break here (or equivalent), immediately after jump to reset vector in case there is a side-effect of work-arounds. (nRF52832 had an issue with P0.25 though not nRF52840)

_vectors:
  .word __stack_end__
  .word Reset_Handler

Reset_Handler:
  /* Perform prestart tasks. */
  ldr r0, =nRFInitialize         <== break here

RE: nrf52840 P0.25 is pulled up before application starts

and0792 — Thu, 30 Nov 2023 16:59:45 GMT

Hi Kenneth,

thank you for your reply.

Even when no debugger is attached, I can see P0.25 being pulled up by measuring the pin voltage with a multimeter. For this reason I don't think these two problems are related.

Any other suggestions?

Andrea

RE: nrf52840 P0.25 is pulled up before application starts

Kenneth — Thu, 30 Nov 2023 14:51:28 GMT

Hello,

I am just wondering if the problem may be related to this one:
https://infocenter.nordicsemi.com/topic/errata_nRF52840_Rev3/ERR/nRF52840/Rev3/latest/anomaly_840_81.html#anomaly_840_81

Kenneth