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?

  • Can you upload a screenshot showing the current consumption of the bad device?

  • In your first post you talked about 

    7mA during advertising

    3mA during loop if not connected

    6mA during loop if connected.

    Your screenshot looks quite normal and you are drawing 441 uA on average.

    A couple of weeks ago you also mention that "On my last test I have assembled a new BT832X and this time got same high power drain as for BT832". Is it so that what module you are using doesn't matter anymore? That points to a problem with your HW doesn't it?

    Can you please summarize your current situation and problems?

    Do you know what goes on in the areas I have marked with green here:

    Are you toggling on and off an LED for example? It could also be a peripheral (TWI or UART for example) that does some work.

  • Just to explain and summarise:

    All initial measurements have been done with a multimeter that normally give a inaccurate average measurement.

    All initial test where done with no UART while final ppk plots where both done with UART active.

    This explain why ppk average reading on BT832X exceed the one performed with the multimeter.

    I am not home now, but as soon as I am back, I will repeats PPK plots with disabled UART on BT832X , BT832 and nRF52DK.

    I have noted that abnormal consumption is related to UART....

    When UART is disabled I have found minimal drain on nRF52Dk and even less on BT832X, while I find abnormal values on BT832(the ones of first message).

    When UART is enabled I find higher drain (300 to 500uA) with similar results for all boards.

    Yes, the problem may be HW related...could be that with a faulty soldering of the BT832 LGA pins ...a UART pin could be grounded..... 

    Could this explain the UART related behaviour?

Reply
  • Just to explain and summarise:

    All initial measurements have been done with a multimeter that normally give a inaccurate average measurement.

    All initial test where done with no UART while final ppk plots where both done with UART active.

    This explain why ppk average reading on BT832X exceed the one performed with the multimeter.

    I am not home now, but as soon as I am back, I will repeats PPK plots with disabled UART on BT832X , BT832 and nRF52DK.

    I have noted that abnormal consumption is related to UART....

    When UART is disabled I have found minimal drain on nRF52Dk and even less on BT832X, while I find abnormal values on BT832(the ones of first message).

    When UART is enabled I find higher drain (300 to 500uA) with similar results for all boards.

    Yes, the problem may be HW related...could be that with a faulty soldering of the BT832 LGA pins ...a UART pin could be grounded..... 

    Could this explain the UART related behaviour?

Children
  • 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!

Related