NPM1300 adc interrupts and IBAT questions

RE: NPM1300 adc interrupts and IBAT questions

Yaxit — Thu, 24 Jul 2025 12:48:03 GMT

Apparently I'm super dumb, I was observing the value after rescaling it to 5V range, hence the 5x factor 🤦

RE: NPM1300 adc interrupts and IBAT questions

Yaxit — Thu, 24 Jul 2025 11:51:04 GMT

Interesting. I'm observing it in automatic, single measurement mode. Maybe I have a driver issue? Let me verify and come back to you

RE: NPM1300 adc interrupts and IBAT questions

Menon — Thu, 24 Jul 2025 11:43:18 GMT

Hello,

Are you observing this in manual or automatic mode? Is it a single measurement or a burst?

I’ve also raised this question with our internal team, as I’m not entirely sure. One of our team members mentioned that this issue does not occur in his setup at any load level. His measurements appear quite stable, with only the LSB fluctuating occasionally.

Kind Regards,

Abhijith

RE: NPM1300 adc interrupts and IBAT questions

Yaxit — Tue, 22 Jul 2025 07:12:25 GMT

Thank you for the clarifications.

I'm still not convinced about the 5 LSBs oscillation. I understand that the actual accuracy might be lower than what can be represented on 1 LSB, but it's odd that those LSBs are skipped entirely, I would rather expect oscillations

RE: NPM1300 adc interrupts and IBAT questions

Menon — Mon, 21 Jul 2025 18:07:39 GMT

Hello,

Sorry for getting back to you a bit late. It's summer vacation here in Norway, and some of my colleagues are on vacation, which caused the delay in addressing this issue.

VSET1 and VSET2 are input pins, not ADC-measurable outputs. They are used to set the initial buck output voltage via external resistors to GND (see Output Voltage Selection). The interrupts are likely triggered at startup, when those resistors are read. These events are not generally useful during normal application runtime.

Enabling ADCIBATMEASEN works reliably, it performs a sequential VBAT and IBAT measurement whenever a VBAT measurement is triggered, either manually or automatically. The results for both are then provided through the IBAT event. However, this approach is not compatible with burst mode, since the result registers for IBAT and burst VBAT are shared, which can cause conflicts.

As for IBAT measurement using the TASKIBATMEASURE trigger, I still need to clarify its behavior. Some follow-up is required with the R&D team, but that may take some time due to vacation schedules.

[quote user="Yaxit"]ADCVBAT2RESULTMSB and ADCVBAT3RESULTMSB seem to contain IBAT and VBUS measurements. Are the corresponding LSBs found in the ADCGP1RESULTLSBS register, in the last two fields as well?[/quote]

See the overview table, IBAT uses the same MSB/LSB pair as VBAT2.VBUS uses the same MSB/LSB pair as VBAT3.

[quote user="Yaxit"]ADCCONFIG is very unlcear. BURSTENABLE's description is "Trigger a single/4 consecutive measurements". Does this register generate the trigger? Does the trigger need to be generated by still with the TASKVBATMEASURE register? When VBATAUTOENABLE is selected, does the host need to issue a first trigger?[/quote]

VBATAUTOENABLE immediately starts automatic measurements, no manual trigger is required after enabling. BURSTENABLE simply enables/disables burst mode, but does not trigger measurements on its own.

[quote user="Yaxit"]Is it possible to have ADC auto measurements in burst mode? If so, what happens to potential IBAT and VBUS measurements issued manually? Can they be lost, overwritten by VBAT burst measurements?[/quote]

Not sure but auto-measurements should work fine with burst mode. Manual IBAT or VBUS measurements may conflict with burst-mode results because they share the same result registers. If the application carefully schedules manual measurements to avoid clashes, it should be possible.

[quote user="Yaxit"]

Seems VBATAUTOENABLE starts the acquisitions right away, to answer my question.

For some reason, though, VBAT measurements seem to oscillate with +-5LSBs, not 1. I assume the ADC values are unsigned?

uint16_t vbat = ((uint16_t)reg[0] << 2) | (lsbs1.vbat_resultlsb & 0x03);

[/quote]

Yes the ADC results are unsigned.

I guess this refers to the System Monitor Electrical Specification, It says the accuracy is ±1%, not 1 bit.

Kind Regards,

Abhijith

RE: NPM1300 adc interrupts and IBAT questions

Yaxit — Tue, 15 Jul 2025 15:46:30 GMT

Seems VBATAUTOENABLE starts the acquisitions right away, to answer my question.

For some reason, though, VBAT measurements seem to oscillate with +-5LSBs, not 1. I assume the ADC values are unsigned?

uint16_t vbat = ((uint16_t)reg[0] << 2) | (lsbs1.vbat_resultlsb & 0x03);

RE: NPM1300 adc interrupts and IBAT questions

Yaxit — Tue, 15 Jul 2025 13:14:31 GMT

Following up, more clarifications are needed.

ADCVBAT2RESULTMSB and ADCVBAT3RESULTMSB seem to contain IBAT and VBUS measurements. Are the corresponding LSBs found in the ADCGP1RESULTLSBS register, in the last two fields as well?
ADCCONFIG is very unlcear. BURSTENABLE's description is "Trigger a single/4 consecutive measurements". Does this register generate the trigger? Does the trigger need to be generated by still with the TASKVBATMEASURE register? When VBATAUTOENABLE is selected, does the host need to issue a first trigger?
Is it possible to have ADC auto measurements in burst mode? If so, what happens to potential IBAT and VBUS measurements issued manually? Can they be lost, overwritten by VBAT burst measurements?