SAR and Battery monitoring.

Writing software that controls the system and peripherals such as displays, SD cards, Buttons, LEDs, Serial Ports etc.
Post Reply
jedm@vpitech.com
Senior User
Posts: 50
Joined: Wed 2016-11-02 22:50

SAR and Battery monitoring.

Post by jedm@vpitech.com »

I'm trying to monitor battery level using the SAR and VHMON but am running into problems as this is a low level task running infrequently. I'm using the code in RdsRadio/fm_init.c as a model - possibly dangerous since it's commented out but the only one I could find. The attached code works most of the time but if interrupted, dies horribly.
xxx.c
(1.78 KiB) Downloaded 404 times
Is there a better example of battery monitoring or using the ADC?
User avatar
Henrik
VLSI Staff
Posts: 1294
Joined: Tue 2010-06-22 14:10

Re: SAR and Battery monitoring.

Post by Henrik »

Hello!

Is this in a system that uses the Touch LCD or on a text-based system?

If the Touch LCD driver TOUCH288.DL3 is in use, there's your problem: the driver uses the SAR hardware to read the touchpad. And your code snippet as it is misses on reserving the hardware for your use. To correct this issue:

Code: Select all

u_int16 VoltageTest(void) {
  /* Reserve the SAR hardware for your use. The touch driver will respect this. */
  ObtainHwLocksBIP(HLB_NONE, HLIO_NONE, HLP_SAR);

  /* All your SAR manipulation code comes here. */

  /* Release the SAR hardware. */
  ReleaseHwLocksBIP(HLB_NONE, HLIO_NONE, HLP_SAR);
}
Does this help you?

Kind regards,
- Henrik
Good signatures never die. They just fade away.
jedm@vpitech.com
Senior User
Posts: 50
Joined: Wed 2016-11-02 22:50

Re: SAR and Battery monitoring.

Post by jedm@vpitech.com »

It's text based (actually just push buttons in the real world with a LED or two). I'll try the hardware locks, I've been trying to write up how to use them for the next person in line.
User avatar
Henrik
VLSI Staff
Posts: 1294
Joined: Tue 2010-06-22 14:10

Re: SAR and Battery monitoring.

Post by Henrik »

Hello!

If your system is text-based then I don't know what tomfoolery goes on behind your back. Anyway, check that the TOUCH288 driver isn't started in your config.txt.

If you still can't get sensible values, you could try the Forbid() / Permit() method of stopping multitasking for the time of your measurement even though comments seem to suggest that it won't necessarily help.

And if everything fails, let me know, and we'll think of something else.

Kind regards,
- Henrik
Good signatures never die. They just fade away.
jedm@vpitech.com
Senior User
Posts: 50
Joined: Wed 2016-11-02 22:50

Re: SAR and Battery monitoring.

Post by jedm@vpitech.com »

I'm now getting good readings but have trouble with the SAR and ANA_CF1_VHMON with values below 3.6 volts. I've set the AVDD to 2.8 volts (2.45 + 8 * 0.04) using the following which now allows me to get readings down to about 3.1 volts.

PERIP(REGU_VOLT) &= (PERIP(REGU_VOLT) & 0x3FF) | (0x0008 << 10);
PERIP(REGU_CF) |= REGU_CF_REGCK;
PERIP(REGU_CF) &= ~REGU_CF_REGCK;

If I use any value smaller than 0x0008 I start to get a buzzing on the audio channel.
Questions:
1) What is the dividing factor of VHIGH used by VHMON?
2) By setting AVDD this low am I causing other trouble?
3) Will plugging in 5v USB then exceed the limits on the SAR (relates to question 1)?

Jed
User avatar
Panu
VSDSP Expert
Posts: 2829
Joined: Tue 2010-06-22 13:43

Re: SAR and Battery monitoring.

Post by Panu »

Hi!

Try reading the RCAP/GBUF (bandgap) reference voltage with the SAR. That voltage doesn't change even if the SAR reference voltage changes.

In the Hi-Res Player I monitor battery voltage with a resistor divider on the PCB. (I do it because I want to read the real battery voltage even if we are charging the battery and VHIGH is at USB voltage).

My battery voltage resistor divider (1:2) is connected to SAR_AUX0 pin, and the bandgap voltage seems to be about 1.64 volts. Thus the battery voltage is universally V_BAT = ( 2 * 1.64 ) / V_BANDGAP, irrespective of the SAR analog reference.

I read it in integer millivolts, e.g. millivolts = SAR_AUX0 x 1640 x 2 div SAR_RCAP, but in the Hi-Res player it's converted to float volts.

Code: Select all

float GetBatteryVoltage() { ///< works with 1.6V bandgap
	u_int16 sar_aux, sar_rcap;
	float volts;
	
	sar_aux = GetSarValue(SAR_AUX0);
	sar_rcap = GetSarValue(SAR_RCAP);
	//printf("\n aux=%4d,  rcap=%4d  ",sar_aux,sar_rcap);
	sar_aux = ((s_int32)sar_aux * 3280) / sar_rcap;
	volts = sar_aux * 0.001;	
	//printf("volts=%4.2f,  mv=%d  ",volts,sar_aux);
	return volts;
}
This approach frees you from setting the AVDD to some strange voltage you'd otherwise not use, just for getting the battery voltage. You can keep AVDD at the value which is best for the performance.

Oh, hmm, I'd perhaps not change the voltages in the system by directly poking to the registers... if possible you should consider calling the SETCLOCK library program, e.g. with something like RunProgram("SETCLOCK","-a3.3"); if you need to change the analog voltage. SetClock is a versatile tool; it can be used to change just about any aspect of VS1005 clocking, peripheral bus speeds and voltages.

-Panu
User avatar
Henrik
VLSI Staff
Posts: 1294
Joined: Tue 2010-06-22 14:10

Re: SAR and Battery monitoring.

Post by Henrik »

A strong nod to what Panu said!

SetClock is a relatively new tool nad has some pretty nifty functions. For instance, unless you specifically forbid it, it will adjust the core voltage when you change the master clock.

Kind regards,
- Henrik
Good signatures never die. They just fade away.
Post Reply