Post Go back to editing

LT8490 charging will not initiate

Category: Software
Product Number: LT8490
Software Version: ...


Problem: LT8490 is not initiating charging stages. It has a status code, and some SVRO pins that go high signifying an error. I designed the whole thing. Ask me anything.

Input Max = 52V, 35A

Output Max = 42.6V, 30A

I had an old board revision that the LT8490 worked, and I bolstered from a 15A to a 30A model. It doesn't even try now.

I will attach all the stuff needed to analyze the scenario. Schematic and also a measurement of all the pins with VIN  = 51V, Vbatt = 36V.


*it wouldnt let me attached an altium board file. Let me know if that is desirable and we can figure that out. Can also email me

I attached the spec sheets below. LT8490 is an LT8705 but with solar/battery logic added. I am well versed in these...


Details, notes; observations, discussion:


  1. SVRO_IOUT: blinks (roughly 1/10 second) then SVRO_FBIN follows -->
  2. SVRO_FBIN: is on long, about 1 second
  3. This signal repeats.

The FBIN resistor network uses 0.1% accurate components. I found the equations for solving those very intolerant of a 1% variance. The first equation to solve for R_FBIN1 also enters a negative region past 100kOhms (and is undefined at 100kOhms, and is why 1% variance was crazy). The table of factory values on that same page have R_FBIN1 values beyond 100k. Attempting to regenerate the factory table  is not doable, can someone advise me here? This could be the key to the problem. Because again, my R_FBIN = 93.1k because I want 52V max (solar input specs). But this value is smaller than the 40V and 60V R_FBIN values in the factory table; when I should be between them in R value, logically speaking. This is indeed a conflict.

Also, here is an Oscope of the FBIN pin. Interesting...


It is the same signal. Excuse the noise, my scope sometimes is goofy.

The SVRO IOUT pin going high is funny, because there is no output current yet. But in the pin measurements provided I drew what I saw, a periodic tiny square pulse in IMON_OUT reaching 2.8V... enough to trigger the SVRO (they trigger at 1.25V roughly).


LT8490 does get hot to touch: the higher the VIN, approaching 51V, the hotter it gets. At low voltages, 20V and down, the chip doesn't noticeably get warm. EXTVCC is fed with a 24V regulator; so LT8490 is not powered by VIN like it could be.. It does seem to be ok if I left it alone. (hot to touch is about 50C) I think it would hit 60C and stops increasing, but I do not leave it on too long cuz its an expensive repair if it burns up haha.

I swung input voltage from 6v to 51v, to see if it triggers anything. no change.
Same with output being upon 24V and 36V battery packs. No change in behavior. Same SVRO behavior as mentioned above, I have the four SVRO's on LED's.


LDO33 and INTVCC are not overloaded but please check them out if you like. I bottlenecked the power to the LED's with a single 1K (see schematic) which makes the current 3.3mA at any time, even if multiple LED's were to trigger, the 3.3mA will be divided and not exceeding 3.3mA.

  • I will admit, INTVCC could be overloaded when the very large FET's in the power stages trigger, but we aren't even there yet. That was an experiment I am trying to get too with this board; large FET gate capacitance, and paralleling FETs. None of the power stage attempts to start right now.

Temp sensor is working.. lol..


I do have a code from the STATUS pin and FAULT pin, and also some other Oscope readings I am also attaching. Can someone interpret the STATUS pin message? Apologies for scope noise, its an old sucker. It's not real noise on the board.

STATUS pin readings: 4 images.
The byte repeating.


This is the farthest zoom out, the byte repeats 8 times, then there is this longer byte at the end, then this little squirt that's lower voltage then the rest at the very end.

Just one of the bytes zoomed in a but more (the longest high bit I believe is the start of the message?)

Two of the repeating bytes, then the loooong bit in the middle for the start of the final byte of bits; with squirt included at the end.

And at last, the underwhelming and not too helpful fault reading... yah. This beep is very quick and repeats after the status pin ends its message. Perhaps that is the little squirt at the end of the status message because it is not 3.3V like the squirt above.



 Ok that's all for now. As I play with it I will say more. Please ask me questions if you need more info. This is not a new problem, I have been at it off an on for a few months, but now is crunch time to get it 'done'.


Director of Engineering



  • I solved it. I will explain in a bit. *angelic choir  sings

  • In the picture, the FBOW pin was being grounded by my microcontroller. I knew logic low from my microcontroller would ground FBOW, but I did not know that FBOW sends a 6 pulse square wave at startup like FBIW does for the FBIN pin (solar input controls). So before any initialization, the lt8490 had already faulted and was caught in a loop. Which explains the mystery 5ms pulse in the LT8490; I was confidant that was a 'reset' pulse for the 8490 firmware with every fault.

    The failure was when FBOW pulls high, it gets shorted to my micro pin, then the LT8490 reads it as a temperature fault. FBOW is the temperature digital control pin for output voltage modulation, so logically it faulting is a temp fault too; the chip just didn't know a better way to express its pains.

    The fix was open circuiting my micro pin in my firmware. I need to put a resistor from my pin to FBOW so the two can coexist together whether either is logic high or low.

    The purpose of this was to allow me to control output voltage of my charger with bigger brains (burst charging, cranking amps providing user input, equalization, etc), but I failed to implement it electrically.

    Easy fix, massive headache to find that was the problem.

    Thank you for helping. You did you a lot Charlie! You helped me narrow it down. Much appreciated.

  • This is really good to know for anyone surfing the web for a fix on a similar issue. Check your FBOW and FBIW pins to see that they are not being grounded. That they are putting out their high pulses before initialization of the startup phases described in the spec sheets. IF they are not doing this, the chip will perpetually fault and reboot.

  • FBOW and FBIW are push-pull outputs and need to reach their high and low logic level states with no more than 5mA of current. They should never be driven externally.

Reply Children