Bobtb wrote:...It does report Err 3 and even a lady anouncing "Charging Error 3". The Err 7 is another board, it's 2 different issue.
IMO, you should have kept these cases (err3 vs err7) separate, by appending to existing topical threads, or starting new ones, as necessary. In this reply I will limit my response to err3.
You did not say that problem lies with the FET but I was just hoping to try my luck on it since the board is sitting there collecting dust as I chance upon your post mentioning something about FETs. There is no harm trying as I could not find any post with solution for Err 3 or did I just miss it?
I don't recall whether err3 has been treated directly, and I did not search for it, but you might try searching again for err3
, w/o a space character.
I think you may be helped by knowing more about how the Charging-FETs Test
functions. With better understanding, you may be able to craft more useful search search strings and uncover applicable work.
What I say next should be prefixed with weasel words such as "as far as I know", or "our present understanding is...".
The Charging-FETs Test is performed only in the half minute following connection of charging power to Roomba.
Two power MOSFETs are connected in series to provide a means for the robot to always be able to halt charging if one of the FETs should become always-conductive (by transforming into an always closed switch (these FETs are either ON/CLOSED or OFF/OPEN; they are not operated as partially ON devices)). Their board markers are Q17 & Q18.
IOW, two in series provide a safety function. The purpose of the FETs check is to verify that each FET is controllable (i.e., when its gate voltage is HI, its channel is OPEN (high resistance), and when gate voltage is LO, the channel conducts current).
As charging voltage reaches Q17 & Q18 it normally can't pass through the FETs because they are biased OFF by battery voltage applied to their gates; and at that instant the presence of charging voltage is detected by the MCU causing it to switch from standby mode to charging mode. Charging voltage takes over the biasing job to hold FETs OFF.
The first thing done by the charging routine is to call its FETs check routine into service; and the first thing that must be known is whether charging current happens to be flowing already (which would show that both FETs are conducting when they should not). That would be Test-1; pass IF no current / fail IF current is high.
Tests two & three, individually, sequentially pull Q17 (or Q18) gate LO, then check for current flowing (through both, since in series). IF current is zero, pass, else IF current greater than 0 amps, fail. Failure shows that one FET is permanently shorted, its gate voltage has no effect, which means charging current control is via only one FET, and if it too were to become uncontrollable, the robot would be unable to halt the charging process. The MCU executes the Err3 announcement.
The final test, Test-4, pulls both FETs gates LO, turning ON both FETs, and the MCU expects to see high-rate charging current (1.3A) flowing through the battery. Pass, IF current is HI, fail IF current is below some unknown threshold. Failure here produces the Err3 announcement, but the actual fault may have nothing to do with the FETs -- it could be a PSU fault, or resistive contact along the charging path, or even the battery's cells.
If all tests pass, the charging controller removes gate-drives (gates go HI) to switch FETs OFF, and then steps up (using PWM control, rather than analog control to increase current to max.) charging current over a short interval to the high-rate level, and the battery is formally under charge.
All sampling of charging current is done by measuring voltage developed across the system's master current shunt resistance (0.05 ohms of R235//R257).
Q17 & Q18 are located in the forward, left quadrant of the mobo, as shown here:
Before you fool around with testing Q17 & Q18, it would be prudent for you to read a method
that discusses hand testing the charging FETs on a 4XXX-Roomba's mobo. That same process can be applied to the 5XX-Roomba mobo, but with one difference: 4XXX=Roomba's FET-gates have a single driver xstr, whereas 5XX-Roomba uses two drivers.
I will be very surprised if your 5XX-Roomba has suffered failed charging FETs -- there are several design features that, when combined, make failure of Q17 & Q18 much less likely than we saw for the 4XXX series.