Post Go back to editing

MAX17335 shipmode wakeup problem

Category: Datasheet/Specs
Product Number: MAX17335, MAX1733

Hello I am writing here since I am not receiving any answer on the private support case I opened more than a week ago (I miss very much the time when asking for support was just a matter of a phone call to the Analog FAE from our distributor...)

I am trying to figuring out why MAX17335 is waking up by itself from shipmode without any external stimulus.

The problem first appeared on the prototype of a board we are developing, fearing it was a hardware problem I purchased a MAX17335_EVKIT_A evaluation board to test it further.

The test was carried out as follows:

1) Connect a Li-Ion battery (measured voltage 3.8V) to BATTP and BATTN pads

2) Attach a oscilloscope probe between SYSP and SYSN pads

3) Connect the EVB to a Windows PC through the USB cable

4) Download and run MAX17335 program (provided by Analog Devices) and verify the communication is working (READING label on bottom right corner of the program)

5) Verify the oscilloscope is reading a positive voltage between SYSP and SYSN pads equal to battery voltage.

6) Click on "Commands" tab, press the button "Enter Shipmode" and right after press the button "Stop Communication".

7) Verify the oscilloscope is reading zero between SYSP and SYSN pads

8) Wait a while (it could be a few minutes, half a hour, a hour...) and verify on the scope that the voltage between SYSP and SYSN pads is again equal to battery voltage, confirming MAX17335 woke up from shipmode by itself.

I tested several configurations of nConfig register (0x1b0): nConfig = 0, nConfig = 0x0440 (PBEn and COMMSH), nConfig = 0x40 (COMMSH), nConfig = 0x400 (PBEn) but the result is always the same MAX17335 wakes up by itself after a random time.

Is there anybody out there experiencing the same problem?

Thank you.

  • Hi!

    Noticed same and it happens if system output is too floating.
    It needs to be pulled down to keep it in shipmode.
    Tested with 2.2k resistor. Stayed in shipmode for many hours.

    I quess the charger detection is way too sensitive.

    Regards,
    Esa

  • Hello Esa,

    I think you meant "pulled up" as the wake up signal needs to be set low by the push-button to actually wake the IC from shipmode (see the highlighted text at page 27 of the datasheet below).

    Note that the datasheet recommend to not use a pull-up resistor.

    The evaluation kit actually mount a 1M pull-up resistor (R10 to I2C isolated power rail) probably needed just to bias the mosfet Q4 that drives the LED D1.

    I will try to mount a small value pull-up resistor to the battery rail as you have done and see if something changes, anyhow I am not comfortable with making a battery discharge current path using a low value pull resistor.

    Eventually it is quite frustrating not being able to see shipmode fully working even when using the official evaluation board...

    Thank you.

    Best regards.

    Amel

  • No, I added pulldown/load between SYSN/SYSP. I guess this is because the charger detection is way too sensitive so the chip thinks it sees the charger - which cancels the shipmode. With resistor it seems to stay in shipmode much longer but still seems to wake up randomly - maybe because of glitches from lab wires. But at least it stays in shipmode much longer now. Yesterday it stayed 5...6 hours until I removed the resistor and it woke up immediately! But today I have seen it still waking up randomly even with that resistor. I guess I'll put a LED to the output next to monitor it without using long labwires or oscillosope.

    Starting shipmode seems to be also very tricky. Need to click 'etner shipmode' and 'stop communications' very quickly and then remove the USB cable very quickly before it enters shipmode. Otherwise it will wake up right after USB cable is removed. I wanted to remove the USB to minimize any glitches outside. Just the eval board connected to battery.

    Clearly this chip has issues with shipmode or charger detection but I would like to find some workaround for this to create proper schematics.

    The ALRT wakeup you mentioned needs to be activated and I don't have it activated so the S2 doesn't have any effect in my tests yet.

    Regards,

    Esa

  • No, I added pulldown/load between SYSN/SYSP. I guess this is because the charger detection is way too sensitive so the chip thinks it sees the charger - which cancels the shipmode. With resistor it seems to stay in shipmode much longer but still seems to wake up randomly - maybe because of glitches from lab wires.

    Make sense the glitches that are causing unwanted wake up are coming from SYSP/SYSN, as when nConfig.COMMSH and nConfig.PBEn bits are cleared the only way to exit ship mode should be to apply power at SYSP/SYSN pads... 

    Even if the 2.2K pull-down you used would have worked and kept the IC in ship mode, it would have become a not negligable load during battery operation.

    Starting shipmode seems to be also very tricky. Need to click 'etner shipmode' and 'stop communications' very quickly and then remove the USB cable very quickly before it enters shipmode. Otherwise it will wake up right after USB cable is removed. I wanted to remove the USB to minimize any glitches outside. Just the eval board connected to battery.

    Removing the USB cable caused exit from shipmode also during my test when I was not fast enough with the unplugging. That should have not happen either as nConfig.COMMSH was cleared during testing and the power from USB port on evaluation board is used just to power the FTDI chip and the I2C signal isolator.

    Clearly this chip has issues with shipmode or charger detection but I would like to find some workaround for this to create proper schematics.

    It comforts me to know that I am not the only one having problems with shipmode on MAX17335. I would also like to find a workaround to make it work but I do not know what to do anymore.

    At the same time I am also consulting with a field application engineer from Analog who unfortunately is unable to replicate the problem.

    I also think that this chip has problems with shipmode... Unfortunately I have already invested too much time in looking for a workaround. Barring last minute miracles I fear we will have to replace MAX17335 with another IC or maybe two as there are not many alternatives that integrate a fuel-gauge and battery charger in the same chip.

    Regards.

    AMEL

  • Still happening.. Now I have only monitoring LED+series resistor for it, in parallel with 1k load resistor at SYSN/SYSP. All cables unplugged. Battery connected with only 2 cm. leads. Started shipping mode properly and left it to the lab table. Maybe a hour later LED was turned on... So, even when it works better it's still 100% sure workaround.

    Regards,

    Esa

  • Hello Esa, you want to try this (from ):

    We confirmed that changing the nProtMisc.CurrDet from 2 to 5 also was able to keep our device in ship mode overnight.  This option does not increase the active mode IQ.

    We would recommend you keep nADCCfg = 0x5008 (the original recommended setting) and changing nProtMiscTh from 0x7A28 to 0x7A58.

    Regards,

    AMEL

  • Hi AMEL,

    Very good finding, thanks!
    I tested this also overnight and it worked!

    But.. I noticed it will stay only as long I keep the USB cable connected in PC - which means I2C SCL/SDA lines are kept high. As soon I diconnect the cable and I2C lines goes low it will wake up. This is little bit problematic because in our end solution the MCU which masters the I2C bus will lose power when the shipping mode is activated and this is exactly what we want to happen to save the battery. And we want to use pushbutton to wake up it from that mode.

    I also found an automatic shipping mode based on I2C status, by setting nConfig to 0x0040 and Config to 0x2240 (which means COMMSH = 1 on both of them) it gone to ship mode a moment after disconnecting the USB from PC and seems to stay also. No need to send shipmode command at all... I already though that now this is finally solved but no.. Right after enabling pushbutton wakeup with nCongig set to 0x440 it will start to cycle between shipping mode and system turned on endlessly.

    I found out that the reason is that ALRT is driven low when the shipmode is activated and I didn't find any way to turn this off even with disabling all kind of alerts. So we are now very close, but not there yet..

    So the only known solution to make this work for now is to use COMMSH automatic shipmode, pulldown the I2C lines when shipmode is wanted and then create a circuit which pulls up the I2C lines when button is pressed - to wake it up again.

    Good thing with COMMSH shipping mode is that when we have a removable battery it could go to shipmode automatically if it's removed.

    Regards,

    Esa

  • Hi AMEL,

    I just found out what is pulling the ALRT down!

    Way too simple... I didn't check the eval schematics carefully how the ALRT signal was actually handled... It was the eval board circuits pulling down the ALRT pin when USB was removed because it's pulled up to the voltage which comes from the USB - obviously...

    So I ended to remove R8 and pulling up the ALRT pin directly to the battery positive. Well the button S2 doesn't work anymore but I can emulate it with jumper wire to the ground.

    Now it finally does exactly what it should be and even better; now it goes to shipmode automatically when I2C collapses due to battery pack removal (this chip will be included in our battery pack). With battery pack connected but unit turned off it will wake up from the button. In the final circuit I'll connect the ALRT pullup after the current measurement resistor - even when there's no significant current drawn by ALRT pin.

    Thanks for your help - now I'll continue with longer run tests with the shipmode. I hope it will now stay.

    Regards,

    Esa