Post Go back to editing

How to implement the wake-up using a pushbutton switch and without connecting the USB on MAX17320?

Category: Hardware
Product Number: MAX17320

I would like to wakeup MAX17320 using a pushbutton switch.

The datasheet shows a circuit but it is not working on my setup:

What is the best way to do it?

  • Hey  ,

    Thanks for reaching out. Pushbutton wake-up on the MAX17320 works through the ALRT pin, and a few configuration details must be in place for it to work:

    1. nConfig.PBen (1B0h) must be set to 1 and saved to NVM. You can confirm it's active by reading HProtCfg2.PBEN (0F1h).

    2. The button only wakes the part from Ship or DeepShip mode. It will not wake it from Undervoltage Shutdown (only a charger can), and the pack voltage must be at least 4.2V.

    3. ALRT should not be used for anything else. Please check that nProtCfg.OvrdEn = 0, and that alert output (Aen/ALSH) isn't active.

    4. The button must hold ALRT low for longer than ~100ms, and ALRT should have a pull-up so it idles high.

    To help us look further, could you share:

    • Your nConfig, nProtCfg and HProtCfg2 values (or your .INI file)

    • How you're putting the part to sleep (SHIP command, communication drop, or undervoltage)

    • Pack voltage and cell count

    • A scope capture of ALRT during a button press

    Best,

    Doug

  • Hi  ,

    Thanks for the details. The warm-vs-cold behavior points to where the settings are stored.

    The MAX17320 reloads its settings from NVM every time it powers up. Writing nConfig (0x1B0) or Config (0x00B) from firmware only changes the working copy, which is lost when the cells are disconnected. The factory NVM default for nConfig is 0x2290, which has PBen = 0. So on a cold connect, pushbutton wake is disabled until your firmware runs again. On a warm cycle, your firmware has already set PBen, which is why the button works then.

    To confirm:
     

    1. After a cold connect, and before your firmware writes anything, read nConfig (0x1B0) and HProtCfg2 (0x0F1). HProtCfg2 is read-only but reports whether pushbutton wake is actually active (PBEN bit). I expect PBen/PBEN = 0.
       

    To fix: 2. Save your configuration to NVM once: nConfig = 0x2690, plus nPackCfg, nODSCTh, nIPrtTh1, nBalTh, nProtCfg, etc. Use the Copy NV Block procedure in the datasheet: unlock CommStat, write the registers, send E904h, check NVError, then do a full reset. 3. NVM can only be written 7 times, so please check how many writes remain first (command E29B, then read 0x1FD), and write all the settings in one pass.

    After that, the settings should persist through a cold connect and the button should wake the part. Let me know what the step 1 readback shows.

    Best,
    Douglas


    FOR CONTEXT   replied:

  • RAM Config (00Bh) reads 0x2610.
    nConfig = 0x2690
    PBen = 1

    nConfig = 0x2690
    nPackCfg 0xA100
    nProtCfg 0x0100 (DeepShip 0, ALRT override 0)
    nODSCTh 0x0A04
    nBalTh 0x046A

  • Hi  ,

    Thanks, that rules out the NVM settings. PBen is set in both nConfig and Config, so pushbutton wake is configured correctly.

    To narrow down the cold-boot case, could you check:

    1. Right after a cold connect, before pressing the button, does the IC respond on I²C? If so, please read ProtStatus and HProtCfg2 (0x0F1). This tells us whether the part is asleep, or awake with the FETs held off.
    2. How are the cells connected during a cold boot? If they go on one at a time, the IC may see an undervoltage cell and enter Undervoltage Shutdown, which can only be exited by connecting a charger, not by the button. Does the issue still happen if both cells are connected at once?
    3. What powers the ALRT pull-up? Please scope ALRT through the cold connect and the button press. ALRT should idle high and stay low for more than ~100 ms when the button is pressed.
    4. Does connecting a charger wake the part on a cold boot?

    Best,
    Doug

    1. Right after a cold connect, the IC is not responding  at all.
    2. Batteries are connected one at a time, low cell first then high cell last. I agree the IC may be seeing an undervoltage cell and enter Undervoltage Shutdown, which can only be exited by connecting a charger, not by the button. I have not attempted to connect the 2S batteries at once.
    3. The ALRT currently has no pullup. Where should the pullup go and what value of resistor do you recommend? (The scope is busy today so I'll try to send tomorrow when I get access.)
    4. The charger wakes up MAX17320 but MAX17320 stays in error mode. 

    To wakeup from cold boot, I was providing a short 9V pulse on the PCKP pin and it works normally after.

  • Hey  ,

    Thank you, this is helpful.

    Since PBen is already programmed in NVM and survives a cold power cycle, I no longer think the issue is related to the pushbutton configuration itself.

    Two things stand out:

    1. ALRT currently has no pull-up. The pushbutton wake mechanism depends on the ALRT signal transitioning from a valid high level to low. If ALRT is floating during a cold startup, the device may never detect a valid button event. As a first test, I would recommend adding a pull-up on ALRT (for example 100 kΩ, or 47 kΩ if preferred) to an always-available logic rail rather than to a rail that is only present after the system powers up.

    2. The cells are connected one at a time. During cold installation the gauge temporarily sees one populated cell and one missing cell. Since the device does not respond on I²C afterward, it is possible that startup is entering an undervoltage-related shutdown condition. The fact that both a charger connection and a 9 V pulse on PCKP can recover the part makes this explanation plausible.

    Could you try the following experiments:

    • Add a pull-up to ALRT and retest the pushbutton wake.
    • Connect the complete 2-cell stack simultaneously (or as close as practical) and check whether pushbutton wake behaves differently.
    • Measure ALRT during cold startup and during the button press when you gain access to the oscilloscope.

    Two additional questions: when the charger wakes the device and it remains in an error state, which fault bits are being reported in Status/ProtStatus immediately after wakeup? Also are you using your own board or is this implementation on a EVKIT

    Best,

    Douglas

Before You Switch


Switching languages will make ADI Explorer unavailable. Resume your session by switching back to English and reopening ADI Explorer.