Increasing supply current of a delivered and unflashed nRF52832-based electronics (up to 55 mA (!)); then going back to some mA ?!?

[matthk]

Hello,

When I power our customer-designed nRF52832-based electronics I see the ingoing suply current (at 3.1V) rising in about 3 seconds up to 55 mA (!), then decreasing in the same time down to some mA. We use the Taiyo Yuden module EYSHCNZXZ and have an SPI-based accelerometer and a TWI-based temperature sensor and -serial memory at the board. For the chips at both buses we can switch off the power supply.

When connecting a Segger JTrace Pro the increasing and decreasing input current behaviour is exactly the same. But after erasing and flashing the BLE stack and our application firmware everything runs well; in the active state we see a supply current of around 1.8 mA and in sleep mode we turn at about 160 µA which is already quite good. And I can't see any more this increasing and decreasing input current at power-up. Up to now I can't detect a mising function in the electronics, but I'm afraid that in the high current phase something will be damaged inside the BLE module.

My questions are:

Are in the Reset-Phase not all pins in high-impedance or input-mode?

Is already a Firmware flashed in the delivered nRF52832 (maybe optimized for another electronics) which could be the reason for some collissions at the ports?

Best regards

matthK

[LimeTronics]

If your NRF52 is really consuming 51 mA, then your NRF52 silicon is destroyed / damaged and needs to be replaced.

However there is also a good possibility that the 51 mA is going to other components on your board. An accelerometer, temperature sensor and flash memory is highly unlikely to be able to consume 51 mA.

Are you sure you are not driving IO pins to a chip that you've powered off? SPI can sometimes also make pins high, so make sure it is LOW or FLOATING + pull-down.

[matthk]

The problem appears only for a freshly delivered nRF52 without any erasing or programming of the flash from my side. When I then erase and flash with my firmware this doesn't appear any more. But as you say I fear that something is already burned in the electronics - it is quite strange that everything still works...

The SPI from the accelerometer is connected to the nRF52, but the accelerometer's supply pin is connected to the output of a logic driver (74AUP2G17) which is controlled by a nRF52 GPIO; this one should behave after Reset as an input (hopefully without Pull-Ups) as long it is not configured by my Firmware, so no supply voltage should appear at the accelerometer.

Exactly the same is for the TWI-Bus and the connected temperature sensor and serial RAM: the Data and clock lines are connected to GPIOs at the nRF52, but the supply pins are connected to the second output of the upper mentioned logic driver; the corresponding input is connected to another GPIO.

I have just made a test: I have erased the flash of a working nrf52 electronics and I could see the increase of the supply current again. What I still can not understand: Even if the external chips would be supplied in Reset state and even if they would like to send anything about the SPI- or TWI-Bus (which is not possible without a SPI master): as long as the nRF52 has no configuration of these GPIOs they should behave as input, probably high impedance, so no current can pass...

How can we advance?

Best regards,

matthK

[run_ar]

On Reset all GPIO's on the nRF will be in the input, disconnected state. This means that if you have gpuios, connected to inputs on external devices, you do not know which state these will be in. Do you have any external pull up/downs connected to the 74AUP...? Maybe try not to initialize the gpio pin controlling this in sw, i.e. leave it floating to see what happens as an experiment.

[matthk]

No, there are no pull-ups at the 74AUP..., neither at the temperature sensor, serial RAM or accelerometer. 

Just to remember: the problem appears when no firmware from my side is running; at an empty or maybe prefilled flash…

Should I send the schematics in a protected area for discussing?

[run_ar]

What happens if you try 'not to' initialize the GPIO that controls the 74AUP in your firmware?

[matthk]

I see that the current rises up to the mentioned high values and comes back, only later due to the used blocking mode of the TWI-transfer functions the firmware hangs up...

[run_ar]

OK, so if you leave the output pin controlling the 74AUP floating, you will see the excessive current draw (This happens if you do not initialize the control pin, or if there is no firmware on the nRF). To me that sounds like the input pin to the 74AUP needs to be in a known state. Please consider adding an external pull up/ pull down.

Not sure if the 74AUP will be damaged by this, so please check the datasheet.

[matthk]

OK, I will try this in the next days - thanks...

[run_ar]

ok, let us know if you have any further questions.