nRF5340 current consumption issues

[John Lee]

I am working on porting a product made with nRF52832 to nRF5340.
The work is in the final stages, and we are working on reducing current consumption on the 5340 board.

I was able to reduce the amount by referring to the Nordic blog, but there is still a problem with current consumption being greater than before.
(While I got an average current of 25uA on the 52832 board, I get an average current of 40uA on the 5340 board.)

I found something strange while measuring the current of the 5340 board using PPK2.
Peak current generated during radio operation is a problem that occurs more frequently than the 52832 board.
To confirm this, I captured packets using a sniffer device.

<nRF52832>


<nRF5340>

For the 52832 board, I can see empty packets in most master-slave pairs, but for the 5340 board, empty packets from the master seem to fail frequently.
Based on this, we try to guess that the condition of the radio, such as antenna matching, is bad.
Can you confirm if my guess is correct?

My connection interval is min: 60ms, max: 80ms and I am using slave latency as 3.
Below is a screen capture of the current peak.


<nRF52832>


<nRF5340>

[frax84]

Hi John,

i'm wondering if you can log the RSSI of the packets exchanged. In general, if antenna matching is poor (due to bad matching network or interferences or whatever), you should notice an RSSI averagely lower of several dBs. It's just a coarse check, but maybe it can give you some hint on the issue.

[John Lee]

Looks like my guess is wrong.
The master sometimes fails even on the 52832 board, and rssi seems to be more unstable.

<52832>


<5340>

So why is my 5340 board getting empty packet connection checks more often, even though it uses the same connection interval, slave latency?

[frax84]

Hi John, it's hard to make good hypothesis because you didn't provide neither code nor schematics. If I were in your shoes:

1. I would firstly check from the hardware side. For example, are you using an external crystal for Bluetooth? If yes, is the same in the two boards? Crystals are used to measure time flowing. If the accuracy of the crystal is not the same, or if you're using the internal oscillator, things can change.
2. Secondly, I would check if your board settings are the same (i.e. do you use PM module? The nrf connect SDK version is the same?)
3. Finally, I would make a test with slave latency = 0. Slave latency affects how frequently peripheral and central devices "can ignore" each other so this could play a role in addressing your issue.

[John Lee]

Added information that has not been explained.
In the case of the 52832 board, NCS is not used, and the sdk in use is as follows.
52832: nRF52 SDK 17.1.0
5340: NCS 2.3.0
Small differences are acceptable as they do not use the same SDK.

1. Both boards use the same 32MHz crystal and use internal RC. (32kHz is not used.)
2. Apply PM at 5340 board.
(CONFIG_PM, CONFIG_PM_DEVICE)
3. After removing the slave latency, I will upload the test results.

My question is why the interval between sending and receiving empty packets is different on both boards, although the slave latency is the same.
Is there any additional information I should check?

[frax84]

Did you try to set latency to 0 on both boards to check if these differences disappear? Latency is not so trivial to consider during packet exchange. I think it's worth a shot

Edit: sorry, I missed your 3rd bullet point.