VGPIO HL7800 unsolicited wakeup

Hi there!

I’m checking in to get a better understanding of the HL7800 and its VGPIO as I am getting a bit of an odd behavior. For a bit of context, we are using it in a low power application with a Bluetooth chip as a remote monitoring solution. In order to know when the modem is in hibernate we track the VGPIO pin and then control the wake line accordingly.

This has worked well so far, however we have a unit that we’ve deployed overseas which is exhibiting signs of the VGPIO rising high without any solicitation from the Bluetooth chip. I haven’t been able to find anything explicitly in the control logic that would cause this and as far as I can see the VGPIO goes high / low when the modem is awake / asleep.

Would anyone have any potential thoughts on this?

Did you enable psm mode for hl7800?

AirPrime_HL7800_Low_Power_Modes_Application_Note_Rev2_0.pdf (627.3 KB)

PSM is disabled, but I do have eDRX enabled and it was working on the device that was facing issues. I’m seeing it happen in Japan but can’t find how to re-create it here in North America

You might disable edrx mode and see if problem still happens

Is the eDRX related to VGPIO at all? It won’t be easy to do adjustments to the deployed unit if at all, so I’m mostly looking to try and understand how the system is waking up as it does.

I see the VGPIO mention for the PSM in the low power reference sheet however I don’t see anything for the eDRX. I did see however that it can sometimes go to lite hibernate with

If this were to be the case, is it possible that it would go active → hibernate → lite hibernate (raises VGPIO)?

It worths a try on your side as in page 18 of the application note, the VGPIO will also have acitivity for edrx mode.

Also, have you checked if this is related to abnormal reset of module?

I can try to look into it, but out of curiosity, is there any particular pin you recommend for tracking when the modem is in hibernate?

At first I thought it was GPIO6 but then it mentions that it will only work when eDRX has been successfully negotiated, but this isn’t always the case as it is network dependent.
image

I thought afterwards that VGPIO would be the next best but according to the low power document there is still activity on the line.
image

What is the recommended low power tracking method?

why the VGPIO is not suitable for you?
If it goes up, that means it wake up, is it ok for you?

The challenge is more so in the interpretation; when the VGPIO line was raised I previously thought that this meant that the device was requiring certain activities would be needed, but it seems like this includes the paging windows as well which don’t need anything

it might just respond to the network and then go back to sleep mode again

Following up a bit more on this, I’m trying to test VGPIO and hibernate on a unit I have with me, and it seems like I can set it up to enter hibernate correctly with hardware control signals, and I see it using eDRX + almost no power by measuring it’s current consumption, but the VGPIO line doesn’t go low.

Is there any possible case where the modem can enter hibernate but the VGPIO line stays high?

Did you pull the wake up pin to low

I have the wakeup pin low, the current measurement shows the system on very low power, and on eDRX paging windows I’m seeing the following for current consumption:

On UART_CTS and VGPIO however on those eDRX paging windows, I’m seeing the following:

where the VGPIO seems to be stuck high overall.

Sorry, the time scale wasn’t quite clear on the current measurement:

Only happen to one module and other are low state for the vgpio pin?

So I thought I should update this topic with what I believe caused the issue. What I’ve observed was that some of my sims were allowed to use eDRX and some weren’t, the tests I was performing on the units that could use eDRX however did not have the permissions for sim deactivation.

The unit that was deployed had a sim card which had both. which led it to go into hibernation of which some of the handling needed to get fixed.