Disabling / Re-enabling Bypass Control of TPS62730 from the Stack for measuring Battery Level

I've noticed the previous developer used 

osal_pwrmgr_device( PWRMGR_BATTERY );   

&

osal_pwrmgr_device( PWRMGR_ALWAYS_ON );

through out different control algorithms in the code.  I believe the PWRMGR_ALWAYS_ON does disable changing this pin through the HCI_EXT_MapPmIoPortCmd  function.  However is there not a way for me to bypass this and directly change the pin state to measure the battery?  Hope someone can chime in.  Thanks

I'm still struggling with this, if anyone from Ti can chime in.  Thanks

Have you tried just manually setting the pin that enables the TPS to zero?  Px.x = 0 and then call the battery measurement function that is found in the KeyFob example, then set it back to 1.

Yes, as part of my logic routine, I tried to disable Stack control of the the pin and set the pin manually, wait ~2msec, then read the battery level.  However it appears that disabling Stack control doesn't work and my attempts to manually set the pin are overridden.  

Kevin,

Take a look at the following app note AN097 and posts.  They may provide you with the information you need.

http://www.ti.com/lit/an/swra365b/swra365b.pdf

http://e2e.ti.com/support/low_power_rf/f/538/t/151573.aspx

http://e2e.ti.com/support/low_power_rf/f/538/t/158097.aspx

Thanks,

Thanks for the links greenja, still not luck solving this problem.  I have tested/verified that disabling control from the stack HCI_EXT_MapPmIoPortCmd( HCI_EXT_PM_IO_PORT_NONE..   and manually setting the pin works to measure the Battery properly.

However, ONLY as long as I dont re-enable control back to the stack afterwards.  For some reason if after completing the Battery measurement I reassign Stack control, nothing works.

HCI_EXT_MapPmIoPortCmd( HCI_EXT_PM_IO_PORT_P1, HCI_EXT_PM_IO_PORT_PIN2 ); //return control

Battery level always reports at 22% indicating bypass did not work in the first place.

I've even gone as far as waiting 5 seconds after disabling Bypass Control from the Stack and manually bypassing, to assure the voltage has settled on the cap bank.   

I'm at a loss here, the only thread I can think of, is there are times when the peripheral buzzer or LED routine is running and Power Management is disabled during that time.  I know there was mention of Power Management required to be enabled for the Bypass pin to change states.  Though its unclear exactly how this applies.  Long term testing indicates that even while these "stay-on" routines are not running and Power Management is enabled, Battery Measurement is still not working.  I hope I'm not the only one to face this problem.

Hello Kevin,

If you are using the manual method in the last link of my previous post, are you re-enabling  the port pin and DIR correctly?  Can you verify this in debug that the pin is an output.

http://e2e.ti.com/support/low_power_rf/f/538/t/158097.aspx

Thanks,

Yes I'm doing almost exactly that.  I am using P1.0 and P1.1, so my logic statements are slightly different.  I verify that the pin should be Again manually everything works fine.  

P1DIR |=04;
P1 &= 0xFB;      //set Bypass ON P1.2 -> 0

P1DIR |= 04;

P1 |= 04;          //set Bypass ON P1.2 -> 1

However, again if I re-enabled Stack control of the regulator with

HCI_EXT_MapPmIoPortCmd( HCI_EXT_PM_IO_PORT_P1, HCI_EXT_PM_IO_PORT_PIN2 ); //return control

after the manual override then all the pin switching stops working as it did.

Hi Kevin,

How about;

HCI_EXT_MapPmIoPortCmd( HCI_EXT_PM_IO_PORT_NONE, HCI_EXT_PM_IO_PORT_PIN2 );
P1_2 = 0;

.... measure and stuff, then later

HCI_EXT_MapPmIoPortCmd( HCI_EXT_PM_IO_PORT_P1, HCI_EXT_PM_IO_PORT_PIN2 );

You shouldn't have to disable power saving in the waiting period while you wait for the capacitors to equalize to the battery voltage.

BR,
Aslak

I've tried this in many different forms.  I see stepping thru the code slowly that the pin does does state properly.  The voltage rail also changes from 2.1v to 3.0v as expected.   However when running as full speed without debug steps this doesn't work.

The part that breaks this whole process seems to be re-enabling control back to the stack with HCI_EXT_MapPmIoPortCmd( HCI_EXT_PM_IO_PORT_P1, HCI_EXT_PM_IO_PORT_PIN2 );

If as a test I don't use this command, I can verify that the first line of code disables control from the stack properly:

HCI_EXT_MapPmIoPortCmd( HCI_EXT_PM_IO_PORT_NONE, HCI_EXT_PM_IO_PORT_PIN2 );
P1_2 = 0;

I set three events separated by 500msec.  

Event 1: Disable stack control

Event 2: Voltage has settled, Measure

Event 3: Return control to the stack.  

Event 3 is always the one that kills this process and seems to override everything.