This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Custom board using BT832 and BT832X ...power drain issue.

I am new to Nrf52832.......I have started development of a custom board based on Bt832 and BT832X.

I have built 2 proto boards one with BT832F and the other with BT832X except that the HW is identical.

I have I prepared a code using AdafruitGLX Nfr Arduino libraries .This code is basically a BLE uart server , with a certain command will activate some Gpio port. 

The code works without any problem on Bt832X  and give an acceptable power drain of

1mA during advertising and

100uA during main loop.

Now I have tried the BT832 and I have discovered that same code works only if I add an external 32kHz oscillator.This is because the low freq. 9scillator is only present on Bt832X! It should not be possible to run the code on the RC oscillator? I haven't be able to do it!

But after having added a 32768 Cristal and 2 12pF capacitors I have run the same code on BT832F .......but with following power drain figures

7mA during advertising

3mA during loop if not connected

6mA during loop if connected.

I would like to understand what is going on!! Can anybody tell me?

Parents
    1. It should not be possible to run the code on the RC oscillator? 
      Yes, it is possible. How you do it depends on what SDK you are using?
    2. Do you have any tools to measure and plot current over time? Average currents aren't very meaningful. 7 mA could e.g. be the CPU running constantly or the radio going haywire. If we could see a plot of the current over time we would probably be able to guess which one it is. 
    3. Do you know whether both the BT832X and F module are using the DCDC regulator? After skimming through the datasheets it seems like the BT832F does have the necessary components to use DCDC, while the BT832X doesn't. Do you somehow deal with this in your code?
    4. Have you tried to run an example from the SDK just to compare the currents? If you still get high currents, then it could be a HW issue. Did you solder on the crystal? Could there be any accidental solder bridges drawing currents?
    5. Are you running the exact same .hex-file on both modules?
  • Hi Martin, thanks for your reply.

    i did some additional test as i describe  answering your question:

    1. adafruit libraries use 11.0.0 SKD.

    2.i had the power profiler kit in order since 2 weeks....waiting for restock......i will order it from elsewhere!

    3.As far as i know, only BT832X has an internal DCDC converter.... I have tested his function in my code and got an important power saving.

    4.I have tried several examples on BT832F BT832X and nRF52 DK. The only board that give always low uA is ddevkit. On my laast test I have assembled a new BT832X and this time got same high power drain as for BT832. I doubt it could be due to a combination of an HW and SW problem. Some results is described at this link:https://github.com/adafruit/Adafruit_nRF52_Arduino/issues/165. Fanstell modules are LGA type and since I have solder those myself , I am afraid there could be some short on GPIO locate on the hidden pads that i cannot reach and check. Neverless when I put a Serial.begin statement all strange behaviour is gone.........

    5.I always upload identical .hex files, but i doubt is some chip could be on debug mode....how to check?

  • If the exact same .hex file produces different results on two different boards you can assume it is a HW or soldering issue:

    If you desolder a misbehaving module from a board, solder it onto another board, and the problem problem persists, then it is likely related to the module. 

    The UART peripheral uses the HF clock. This clock system draws ~470 uA. 

  • My application doesn't use UART, I have made one .hex without UART.init and one with UART.init.

    The .hex with UART.init is the one of the PPK plots. The .hex without UART.init is the one of the first message (abnormal behaviour)!

    I do believe that the difference from one module to another one is HW dependent....soldering of those LGA modules is not easy!

    Anyhow I do not understand why the strange drain show up only if UART.init is not present (it should not be present, since UART lines are not used and there is the addition draw of 470 uA).

  • It sounds strange indeed.

    Could it be that if you don't configure the UART pins they are left floating, and due to some solder issue the pins are leaking current? While if you do configure the UART pins they are tied to the correct logic level and don't leak?

  • I have run several test this is final result that seam more SW than HW realated.

    I have run same .hex ( a BLE peripheral UART example from Adafruit library) on BT832 and BT832X and I have different results.

    Bt832

    Bt832X

    There is a 500 ms  short pulse on BT832X that is much larger (about 500ms) in the BT832.

    Inote:

    1-horizzontal scales are differents

    2-floor (minimum level) is similar 340uA (Serial is on);

    3-pulse level in BT832 is 6.4 mA

  • This behaviour is probably related to a delay(500) statement in main loop().. Delay() is used to put the processor in low power mode , so if there is no delay i will have a 6.4 mA floor level.

    It look like for BT 832 power saving mode is entered only once every 2 cycles!

Reply Children
  • For your RC 32kHz oscillator question: The SoftDevice does support several modes of generating low frequency clock, but it needs to be told so.

    Adafruit/Bluefruit.begin() is responsible for initializinf the SD and it does so (based on the USE_LFXO define) with  NRF_CLOCK_LF_SRC_XTAL, that is, it claims there is a 32k xtal.

    This define is pretty much hardcoded in platform.txt in the Arduino integration, though you might be able to override it if you define your own board - since you're using different hardware than nRF52 Feather, it is a sensible thing to do - I did so for my project, where I use nRF52 Feather mostly for prototyping, then deploy and test on a cusom board (even using different pin assignment).

    But the code in AdafruitBluefruit::begin still misses the case for USE_LFRC, you'd have to add that too.

Related