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

BMD-350 Erratic Current Consumption BLE

I recently designed a PCB and have been testing it.The PCB mainly consists of the Bluetooth Module BMD-350 ( based on NRF52832 SOC ) and HX711.( There is an accelerometer and RGB-LED as well but we haven't mounted them yet). The schematic is attached herewith:

While testing it, I was baffled by the strange current consumption pattern of the device. We are powering the device up by a Li-Po battery 3.7V 1500mAh.And we have programmed it in such way that for 30 seconds, HX711 is active and sending weight data and BMD-350 is active and transmitting packets. For the next 30 seconds, we put the HX711 in low power mode while BMD-350 is still active and sending earlier info. Thereafter, the BLE also enters deep sleep mode.

As it is a battery powered device, we wanted to monitor current consumption and hence we connected a multimeter to the device terminals. The PCB is displaying different current consumption patterns:

Generally, every time I power it up, the device goes into either of these two states.I guess state B is the desired behavior. However, out of every 10 attempts on switching on the device, 3-4 times, it enters into state A and consumes high currents, even in sleep mode.And whats even more strange is that sometimes,when device is consuming 9.4mA in state A third mode, after 30 odd secs, it suddenly starts consuming 0.03mA. So the behavior is kind of erratic.

I de-soldered the HX711 section and the strange current pattern kind of still continued which makes me think that the problem is with BMD-350. The BMD-350 has been programmed to transmit in DC-DC Enable mode in active state and goes to deep sleep with sd_power_system_off.

Could you it be the firmware or the floating pins causing this issue ? Has anyone here faced similar problem while testing a device ? Any help will be appreciated ! Thanks.

  • we wanted to monitor current consumption and hence we connected a multimeter

    A multimeter is no use for this kind of application.

    The current consumption of a BLE radio - like any such radio - is extremely "spiky"; eg,

    Multimeters cannot give a meaningful display of such waveforms.

  • Yes it is not the most elegant option for sure but I am concerned with the general trend over here, don't need a lot of precision. My multimeter Extech EX330 is working fine in the "mA" mode and is able to display the currents in both the active and sleep states. And also functionality wise, the BMD -350 module is working fine , sending data packets which I can view using the nrf app and then stopping packets in sleep. So I suspect that it has something to do with floating pins maybe.

  • Hello,

    Have you tried to disable one and one module at the time from software to see whether you can see what's drawing the power? Have you tried to debug anything?

     

    out of every 10 attempts on switching on the device, 3-4 times,

     That sounds like either:

    One of the external peripherals are stuck in some state between the resets, or there is something flash dependent that behaves different on every reset.  Do you use flash (e.g. peer manager)?

    What SDK do you use? Do you see anything interresting in the log?

    BR,

    Edvin

  • Hi

    As shown in the schematic, we just have the regulator, BMD-350 and HX-711 on the board and out of them,i had de-soldered the HX711 last week just to observe how the circuit behaves. It was still sometimes consuming high current of 11mA in active state and 8-9 mA in sleep state. This makes me doubt that it is the BMD-350 which sometimes is in a confused state maybe !

    We are using nRF5_SDK_15.2.0_9412b96.

    I can provide more info to you after a couple of days after debugging some more with our firmware engineer. Is there something specific that we should be looking for while debug logs?

    I remember him saying that the unconnected / unused pins are not mentioned in FW at all. Can that be a problem here ? Do we have to pull - up /down the unused GPIO pins ?

  • Your engineer is probably thinking feedthrough might be an issue; the nRF52832 is not affected by floating pins left in the default state. Internally these are held (and read) at '0' but without bus loading.

    More likely the nRF52 is not properly in sleep. Easy check just toggle a spare pin set as an output either side of the sleep and watch with 'scope or your meter; the m:s ratio indicates the time in sleep.

Related