2026-02-21 1:24 AM
Hello,
I am evaluating the STMicroelectronics IIS2MDC magnetometer and measuring its supply current using a Joulescope. According to the datasheet, the device should draw approximately ~1.5 µA in idle mode, yet I consistently measure about 450 µA, which is far from the specified behavior.
Supply: 3.0–3.3 V (also tested across the allowed 1.71–3.6 V range).
Measurement instrument: Joulescope (µA resolution).
Verified results across multiple PCBs and multiple IC samples.
Tested the sensor stand-alone (no MCU connected, only power rails).
Same behavior observed on the STMicroelectronics evaluation board.
After power-on, the device performs a ~20 ms boot procedure to load trimming parameters and then enters Idle mode automatically.
In Idle mode, most internal blocks are switched off to minimize power consumption, while I²C/SPI remain active.
Idle mode is selected with MD[1:0] = 10 or 11 in CFG_REG_A.
A single-measurement cycle (MD=01) performs one conversion and then returns to Idle automatically.
Verified successful writes to CFG_REG_A (0x60).
Tested mode settings:
MD = 10 and 11 → Idle mode
MD = 01 → Single measurement then auto-idle
Tested both:
Low-power mode (LP = 1)
High-resolution mode (LP = 0)
Verified default ODR settings (10 Hz) and tested other ODR values.
Confirmed device exits measurement and returns to Idle.
Continuous mode current at 10 Hz:
~100 µA (high-resolution)
~25 µA (low-power)
After a single measurement, the device should return to Idle, where only leakage and interface logic remain active.
After boot and automatic idle entry → ~450 µA
After single measurement and return to idle → ~450 µA
No change when:
sensor runs stand-alone
MD bits changed
LP mode enabled
different boards or IC batches used
This current level corresponds roughly to continuous measurement at ~50 Hz rather than Idle mode.
Has anyone observed similar behavior with the IIS2MDC?
Could there be a condition that prevents the device from truly entering Idle mode (e.g., pin states, offset cancellation, DRDY configuration, or supply sequencing)?
Any insights would be greatly appreciated.
2026-02-25 5:28 AM
Hi @nikosandreadakis ,
A few things you can check to narrow down where the discrepancy comes from:
Make sure you are measuring only the IIS2MDC current
On the ST eval board, the supply rail may also feed:
Do a full register dump after your initialization
Don’t rely only on MD in CFG_REG_A. After your configuration sequence, read back all relevant registers (at least 0x60–0x62) and check:
MD[1:0] = 10 or 11 (Idle)LP = 1 (low power)CFG_REG_B or CFG_REG_C can keep analog blocks active.Minimal test setup on a single device
With just the IIS2MDC on a simple PCB:
MD = 10 (Idle)LP = 1Exclude accidental continuous/single conversions
Make sure your firmware is not:
MD = 01 (single) faster than the ODR, effectively keeping the device always convertingHope this helps :)
2026-03-02 3:56 AM
Hello Federica,
Thank you for the detailed suggestions.
Step 1 — Evaluation board isolation
I have already tested this on the evaluation board. All connections to on-board peripherals were disconnected so that only the IIS2MDC supply path remained active during the measurement.
Step 2 — Register verification
After switching modes, I dumped CFG_REG_A and verified that the configuration is correct.
I also tested CFG_REG_B and CFG_REG_C with all bits cleared; however, the current consumption remains high.
Minimal setup on a single device
I repeated the measurements on a custom board where I have full control of the hardware and the IIS2MDC supply path. The measured current is the same.
Additionally, the same behavior is observed across all 60 test boards, which suggests this is not an isolated assembly issue.
I also found the following discussion on the ST Community regarding leakage current on the LIS2MDL package: link
In that case, the increased current consumption was attributed to leakage caused by flux residues during PCB production. The contamination created parasitic leakage paths between pins, leading to significantly higher standby current.
Given that we observe the same elevated consumption across all boards, could a similar flux-related leakage mechanism be possible in our case? Do you have specific cleaning process recommendations (e.g., mandatory washing for LGA packages) or inspection guidelines for this device?
At this point, the device appears to remain in a higher-than-expected consumption state even when configured for Idle + low-power mode.
Looking forward to your feedback.
Best regards,
Nikos
2026-03-09 10:45 PM
Hi Nikos,
We are trying to repeat tests by updating with different footprints (More solder mask open, extended pads to allow flux residue come out from under IC area/ IC pads area). So that there will be chance of cleaning.
Once tested we will share results and observations.
Best Regards,
Mallik