excess TX power when advertising

[bios-bob]

i have a "bare-metal" (register-level access) BLE advertising program which does not consistently consume the same amount of power when transmitting....

here's what the power profiles looks like when things are working correctly:

the TX current draw of ~5uA is consistent with my expectations (0dB, 3.0V)....  the present implementation actively polls the HFXTAL for it to stabilize, which explains the ~400us of CPU current before transmission begins....   (yes, i know how to make this more efficient....)

what happens quite often, however, is that my advertising events consume about 5mA *more* current throughout the entire event -- including during the initial period of CPU activity when i awaiting the HFXTAL to stabilize:

same code, same board, same configuration....  this program is *very minimal* (about 2K of code), and configures the HFXTAL and RADIO at the register level....  based on very recent nrf52 and nrf54 experiences, i'm extra careful to ensure HFXTAL and RADIO have in fact flagged an appropriate event after i've triggered a particular task...

still, this seems to suggest some problem on my end with "starting" the HFXTAL and RADIO before transmission...  though not by design, it's as if some other portion of the MCU is (still) powered when i'm waiting for a RADIO interrupt to signal TX on the current channel has finished....

using a standard zephyr-based program as my baseline, i've systematically compared hardware registers; and i've applied all the errata seen in zephyr's SystemInit....

one difference i did notice was a value of 0x27 for OSCILLATORS.XOSC32M.CONFIG.INTCAP in the zephyr program; i had been using the default of 0x20....  making this change, however, did not fix the problem....

when sleeping, however, my current draw is right where it should be; the problem occurs only when awake... another thought -- i seemed to almost immediately consume ~5mA of additional current (even as i'm starting the HFXTAL)....  perhaps i'm not "going idle" correctly -- though my current draw of <2uA suggests i'm fine)

one final caveat:  i'm running on a v0.9 DK board....  i should be shortly receiving a v1.0 DK board....

[Einar Thorsrud]

Hi,

In a nutshell, you sometimes see a 5 mA increase in the current consumption during the whole radio event, including when the CPU is active polling for HFXO to start. Can you say anything about the difference between when you see it an not? Are there any differences in the state of your application?

I cannot think of what in the nRF itself would add 5 mA to the consumption, so my gut feeling would be that it could be something external. Do you for instance use GPIO pins to debug, or similar, and could it be that for instance a LED is lit or something else happens during this time?

[bios-bob]

when active, my application has access to a few debug pins, an LED, and a TX-only UART; when my application goes to sleep, these peripherals are disabled....  were this not the case, my sleep current wouldn't be as low as it is....

is it possible when i re-enable UART upon awakening (following quickly with a switch to the HFXTAL over the next ~400us) that the MCU finds itself in a "bad internal state"....

i'll try this on my new DK v1.0.0 board....

[bios-bob]

so far, so good on my new DK v1.0.0 board....  let's close the ticket for now....

[Einar Thorsrud]

Hi,

bios-bob said:

were this not the case, my sleep current wouldn't be as low as it is....

I understand. So what I am wondering about is if you have some debug pins or similar that you sometimes toggle on start and stop of the advertising event?

bios-bob said:

is it possible when i re-enable UART upon awakening (following quickly with a switch to the HFXTAL over the next ~400us) that the MCU finds itself in a "bad internal state"....

I cannot rule out anything with what I know now but I am not aware of any errata or similar that match this.