Wake from SystemOFF with LPCOMP ANADETECT, varying VDD

I'm using the board RAK19007 with its RAK4630 nrf52840, meant for solar and battery, where the AIN3 (P0.05) comes from a voltage divider of VBAT, where AIN3 = VBAT*(1.5M/2.5M). The Thevenin equivalent resistor should be 600KOhm.

The nrf52840 is powered in High Voltage mode, where VDDH=VBAT. I noticed that VDD=MAX(3v3,VDDH) with a multimeter. We use the default LDO in regulators; I tried using the DC/DC converters but I cannot observe any difference.

I'm telling the system to go off (sd_power_system_off()) when VBAT < 3.1V (using ADC read in AIN3), but before system off, I program LPCOMP like this:

        nrf_lpcomp_config_t c;
        /* We have AIN3 with a VBAT divider so AIN3 = VBAT * (1.5/2.5)
         * We have the device going deep sleep under 3.1V, which is AIN3 = 1.86V
         * So we can wake up when VBAT>=VDD is restored to 3.3V, where AIN3 = 1.98V
         * 1.98/3.3 = 6/10, but that's close to the VBAT divider, so we
         * pick 6/8VDD, which means VBAT=4.1V */
        c.reference = NRF_LPCOMP_REF_SUPPLY_6_8;
        c.detection = NRF_LPCOMP_DETECT_UP;
        c.hyst = NRF_LPCOMP_HYST_NOHYST;
        nrf_lpcomp_configure(NRF_LPCOMP, &c);
        nrf_lpcomp_input_select(NRF_LPCOMP, NRF_LPCOMP_INPUT_3); // RAK4630 AIN0 = nrf52840 AIN3 = Pin 5
        nrf_lpcomp_enable(NRF_LPCOMP);
        
        /* Disable RAM retention in System OFF, otherwise the
         * system does not reboot well, part of config reset */
        for(int i=0; i < 9; ++i)
        {
            nrf_power_rampower_mask_off(NRF_POWER, i,
                    NRF_POWER_RAMPOWER_S0RETENTION_MASK |
                    NRF_POWER_RAMPOWER_S1RETENTION_MASK |
                    NRF_POWER_RAMPOWER_S2RETENTION_MASK |
                    NRF_POWER_RAMPOWER_S3RETENTION_MASK |
                    NRF_POWER_RAMPOWER_S4RETENTION_MASK |
                    NRF_POWER_RAMPOWER_S5RETENTION_MASK |
                    NRF_POWER_RAMPOWER_S7RETENTION_MASK |
                    NRF_POWER_RAMPOWER_S8RETENTION_MASK |
                    NRF_POWER_RAMPOWER_S9RETENTION_MASK |
                    NRF_POWER_RAMPOWER_S10RETENTION_MASK |
                    NRF_POWER_RAMPOWER_S11RETENTION_MASK |
                    NRF_POWER_RAMPOWER_S12RETENTION_MASK |
                    NRF_POWER_RAMPOWER_S13RETENTION_MASK |
                    NRF_POWER_RAMPOWER_S14RETENTION_MASK |
                    NRF_POWER_RAMPOWER_S15RETENTION_MASK
                    );
        }

        auto ok = sd_power_system_off();

I would expect that if I set VBAT=2.5V for example (with a regulable power supply), the system will go off. It does, but it reboots immediately. It reboots, then goes off, then reboots, then goes off, ...

I checked that it has to be the LPCOMP resetting the system, because if I don't program LPCOMP the system never resets.

Why LPCOMP does wake the device up immediately after SystemOff?

VBAT=VDD=2.5V, that means that AIN3 = 1.5V < 6/8*VDD = 1.875V, set in LPCOMP. The ANADETECT signal should not be triggered.

Is there a problem with the high resistance of the voltage divider? Is there something I wrote wrong?

In another test I changed the LPCOMP input to AIN7, which is Not Connected to anywhere, and it also reboots automatically.

Parents
  • I'm trying a simpler scenario with stable VDDH (USB power) without any code about ram retention, and it still doesn't work:

            // Wake up if power rises again
            pinMode(31, INPUT);
            nrf_lpcomp_config_t c;
            c.reference = NRF_LPCOMP_REF_SUPPLY_4_8;
            c.detection = NRF_LPCOMP_DETECT_UP;
            c.hyst = NRF_LPCOMP_HYST_NOHYST;
            nrf_lpcomp_configure(NRF_LPCOMP, &c);
            nrf_lpcomp_input_select(NRF_LPCOMP, NRF_LPCOMP_INPUT_7);
            nrf_lpcomp_enable(NRF_LPCOMP);
    
            auto ok = sd_power_system_off();

    Using AIN7. The pin is connected to GND, and once system is off, I connect it to 3V3. It does not reset.

  • Hi,

    You can try to disable global interrupts before executing this, and in that case also use directly NRF_POWER->SYSTEMOFF = 1; (if I remember correctly). On wakeup you can try to double check that it's waking up from system off reset (and not a soft reset due to fatal error or similar) by reading the RESETREAS register:
    https://docs.nordicsemi.com/bundle/ps_nrf52840/page/power.html#ariaid-title35 

    Maybe it's another wakeup source happening here.

    Kenneth

  • I already removed the ram retention part and now it doesn't reset.

    I tried LPCOMP + ANADETECT, and reset does not occur for me (code in prev post).

    I also tried GPIO as well, without success. No reset when I connect the pin to 3V3:

            NRF_P0->PIN_CNF[31] = ((uint32_t)GPIO_PIN_CNF_DIR_Input        << GPIO_PIN_CNF_DIR_Pos)
                               | ((uint32_t)GPIO_PIN_CNF_INPUT_Connect    << GPIO_PIN_CNF_INPUT_Pos)
                               | ((uint32_t)GPIO_PIN_CNF_PULL_Pulldown    << GPIO_PIN_CNF_PULL_Pos)
                               | ((uint32_t)GPIO_PIN_CNF_DRIVE_S0S1       << GPIO_PIN_CNF_DRIVE_Pos)
                               | ((uint32_t)GPIO_PIN_CNF_SENSE_High   << GPIO_PIN_CNF_SENSE_Pos);
            NRF_P0->DETECTMODE = 0;
    

    Am I missing something in LPCOMP or GPIO to get the wakeup?

    Do I need to set up interrupts in any particular way?

  • I finally solved the situation.

    To get LPCOMP ANADETECT to work I missed two steps before the system off: START the task, and wait for its READY event.

    When GPIO DETECT was not working for me is because I was not getting into system-off, due to some other complex bug of the whole software. Once I solved that, GPIO DETECT worked fine as well.

    I cannot tell about the unexpected reset sources I had while I was doing all this. Other pieces of the whole software I don't know about, probably.

Reply
  • I finally solved the situation.

    To get LPCOMP ANADETECT to work I missed two steps before the system off: START the task, and wait for its READY event.

    When GPIO DETECT was not working for me is because I was not getting into system-off, due to some other complex bug of the whole software. Once I solved that, GPIO DETECT worked fine as well.

    I cannot tell about the unexpected reset sources I had while I was doing all this. Other pieces of the whole software I don't know about, probably.

Children
No Data
Related