FU-Dyson-BMS - An (Unofficial) Firmware Upgrade for Dyson V6/V7 Vacuum BMS

[tinfever]

I noticed the format I had for the EEPROM dump was not the same in terms of whitespace - so here is a version that matches the sample ones

Thanks for the info. I'm glad you were able to get some more life out of the 188002 you rescued! 

I'm not sure why the python script didn't work when you tried it, but it might be a python install issue on your machine? Anyways, I took a look at your EEPROM data. The formatting was different than I've seen before so I took the opportunity to improve my script so it can now handle either of the EEPROM data dump formats you provided. I hope you don't mind that I also included your two EEPROM dumps in the GitHub repo as test examples for the EEPROM-parsing-script, just so I have examples of all the different EEPROM data dump formats the parser supports.

Here is the parsed EEPROM data for your BMS:

Code: [Select]

{
    "Firmware": "Tinfever FU-Dyson-BMS V1",
    "Total_Runtime_Seconds": 0.0,
    "Faults": [
        {
            "index": 0,
            "error_meaning": [
                "DISCHARGE_SC_FLAG"
            ],
            "detect_mode": "None",
            "timestamp": 0.0
        },
        {
            "index": 1,
            "error_meaning": [
                "DISCHARGE_SC_FLAG"
            ],
            "detect_mode": "None",
            "timestamp": 0.0
        },
        {
            "index": 2,
            "error_meaning": [
                "DISCHARGE_SC_FLAG"
            ],
            "detect_mode": "Trigger",
            "timestamp": 0.0
        },
        {
            "index": 3,
            "error_meaning": [
                "DISCHARGE_SC_FLAG"
            ],
            "detect_mode": "None",
            "timestamp": 0.0
        },
        {
            "index": 4,
            "error_meaning": [
                "DISCHARGE_SC_FLAG"
            ],
            "detect_mode": "Trigger",
            "timestamp": 0.0
        }
    ]
}
It looks exactly as you'd described. The output has never worked at all, hence the timestamp is always zero, and the DISCHARGE_SC_FLAG is being tripped both when the trigger is pulled, and just when the vacuum awake for any other reason (as shown in the detect_mode field).

Someone on GitHub has success with a PCB 180207 just like yours so I suspect there isn't a hardware difference at play here.

I'm thinking a hardware fault is most likely, unfortunately. It's interesting to hear that the original firmware was at least charging and very briefly enabling the output. I wonder if the original firmware isn't quite as obsessive as mine in checking for faults, and maybe they only check the ISL fault flags (and the output short circuit flag specifically) after enabling the output when the trigger is pulled, whereas my firmware just checks them all repeatedly no matter what.

If you wanted to, you could try disabling the short circuit protection to see if that gets it up and running again. It's not exactly the safest thing to do, but I am curious. In theory there is still the fuse so it might not catch fire if there is a fault with SCP disabled. In the firmware I also have the PIC manually read the discharge current shunt using the ADC and implemented a 30A current limit in software, so that function will still be active just as a last resort.

It's unclear whether it is just the SCP function that is damaged on the ISL, or if it will be everything relying on the DSENSE (discharge current sense) terminal on the ISL94208. It's possible that normal OCP is also broken but we haven't noticed yet because SCP trips first.

(Note: the following should be considered dangerous and increases the chance of fires and such. Please don't sue me.)

To disable SCP, you'd need to disable the ISL94208 function that automatically turns off the MOSFETs independently, and also disable the firmware function that checks if the SCP flag is tripped.

For the first part, I'd change line 35 in the isl94208.c file to "ISL_Write_Register(DischargeSet, 0b00010100);" This should disable the ISL automatic control of the discharge FET.

Then find line 782 in main.c that contains "ISL_Read_Register(Status);". Add a new line below it and insert "ISL_RegData[Status] &= 0b11111011;" This should effectively hide any SCP flags on the ISL from the firmware.

Then compile and download to the BMS.

If you start getting ISL OCP fault code 9, do the above steps but using "ISL_Write_Register(DischargeSet, 0b10010100);" and "ISL_RegData[Status] &= 0b11111001;" respectively. This will disable the ISL OCP functionality as well.

[cunningfellow]

I would say it is shagged.  I probed around the board and looked for obvious faults but none jumped out at me.

The vacuum cleaner is my mothers not mine, so I don't feel comfortable disabling any safety features.

Will just order a replacement battery.  Maybe from Lanplus as they claim to have aftermarket ones with with VTC6 cells.  Much preferable to giving any more money to Dyson.

Here are some shots of the PCB if that is of use for your documentation.

[Terry Bites]

Double FU Dyson- the traitor and double traitor.

[robca]

Thought experiment on how hard it would be to add LED support for the V8:
As tempting as it is for me to try to fix the LED codes for a V8, I think it would require some non-trivial modifications to my LED handling code, which is kind of a mess as it is. I'd have to figure out how to detect that specific PCB version (perhaps by reading pin B0 going to the additional Blue LED 2? No ADC on that pin though.) and then probably add a translation section to my Set_LED_RGB function that everything calls, or have everything that calls that function include alternate handling for this PCB. It also looks like it may not even be possible for me to PWM both RB0 (Blue LED 2) and RB3 (Blue LED 3) without doing something weird like rapidly switching between the two in software. All this is possible, and might not end up being terribly hard, but it's probably more than I want to do right now. Especially since I'm quite afraid of breaking something in the code now that I've got the monstrosity working.

Just wondering if having a build switch for V6/V7 and V8 would help. After all, for someone flashing a battery, would not be hard to choose the right hex file. I mean, runtime detection is a nice thing to have, but it's not like the battery type will change at runtime

If flashing both RB0 and RB3 LEDs is not possible, just flashing one is more than enough. Having a separate code path for the LED flashing for V6/V7 and V8 seems a low risk change and would add value

If there is any interest, once I get a V8 pack to experiment with I might submit a PR. But if you are not interested in the approach, no point in doing it

Did you ever have time to fix the first cell discharge issue? Not asking for a fix, just a status update. I discovered your project only now and plan to use it

[tinfever]

Thought experiment on how hard it would be to add LED support for the V8:
As tempting as it is for me to try to fix the LED codes for a V8, I think it would require some non-trivial modifications to my LED handling code, which is kind of a mess as it is. I'd have to figure out how to detect that specific PCB version (perhaps by reading pin B0 going to the additional Blue LED 2? No ADC on that pin though.) and then probably add a translation section to my Set_LED_RGB function that everything calls, or have everything that calls that function include alternate handling for this PCB. It also looks like it may not even be possible for me to PWM both RB0 (Blue LED 2) and RB3 (Blue LED 3) without doing something weird like rapidly switching between the two in software. All this is possible, and might not end up being terribly hard, but it's probably more than I want to do right now. Especially since I'm quite afraid of breaking something in the code now that I've got the monstrosity working.

Just wondering if having a build switch for V6/V7 and V8 would help. After all, for someone flashing a battery, would not be hard to choose the right hex file. I mean, runtime detection is a nice thing to have, but it's not like the battery type will change at runtime

If flashing both RB0 and RB3 LEDs is not possible, just flashing one is more than enough. Having a separate code path for the LED flashing for V6/V7 and V8 seems a low risk change and would add value

If there is any interest, once I get a V8 pack to experiment with I might submit a PR. But if you are not interested in the approach, no point in doing it

Did you ever have time to fix the first cell discharge issue? Not asking for a fix, just a status update. I discovered your project only now and plan to use it

I was kind of trying to avoid having multiple different firmware builds for different models, mostly just because it sounded like a hassle when releasing updates. Given that there have been no updates, that concern was probably a bit overblown. You're right that something like a #define wouldn't be a big deal and having two different hex files would also be fine.

If you're interested in adding LED support for the V8 model, by all means. I'd be happy to consider any pull requests.  The LED code is probably the most stupidly convoluted part of the code though, so I'm pretty concerned about not breaking what is currently (barely?) working.

I think the easiest way to do it might be to re-implement the existing LED.c functions in a way that the rest of the code can be left completely unmodified. Then the existing V7 LED functions could be included in a #ifdef, and the same for any V8 LED function re-implementations. That would be essentially zero risk for the V7 build, that definitely works at the very least.

Regarding the first cell discharge issue, I haven't fixed that yet. I still feel bad about leaving it like that but I try to focus on one project at a time, and that isn't it unfortunately.

[robca]

I think the easiest way to do it might be to re-implement the existing LED.c functions in a way that the rest of the code can be left completely unmodified. Then the existing V7 LED functions could be included in a #ifdef, and the same for any V8 LED function re-implementations. That would be essentially zero risk for the V7 build, that definitely works at the very least.

Yes, that was my idea (I had a quick look at your code). Implement changes only in LED.c, possibly using the RGB value to determine what to do with the V8 blue LEDs. No changes required to the rest of the code

Regarding the first cell discharge issue, I haven't fixed that yet. I still feel bad about leaving it like that but I try to focus on one project at a time, and that isn't it unfortunately.

Thanks for the update on the cell discharge, I understand about competing priorities out of curiosity, what would the code fix look like? (high level description). You say "BMS will go to sleep and put the ISL94208 to sleep after charging is complete.". What would the alternative to putting the ISL94208 to sleep be? I looked at the graph of the code states, but I'm not sure I understand what other state the ILS94208 could be in

[tinfever]

I think the easiest way to do it might be to re-implement the existing LED.c functions in a way that the rest of the code can be left completely unmodified. Then the existing V7 LED functions could be included in a #ifdef, and the same for any V8 LED function re-implementations. That would be essentially zero risk for the V7 build, that definitely works at the very least.

Yes, that was my idea (I had a quick look at your code). Implement changes only in LED.c, possibly using the RGB value to determine what to do with the V8 blue LEDs. No changes required to the rest of the code

Regarding the first cell discharge issue, I haven't fixed that yet. I still feel bad about leaving it like that but I try to focus on one project at a time, and that isn't it unfortunately.

Thanks for the update on the cell discharge, I understand about competing priorities out of curiosity, what would the code fix look like? (high level description). You say "BMS will go to sleep and put the ISL94208 to sleep after charging is complete.". What would the alternative to putting the ISL94208 to sleep be? I looked at the graph of the code states, but I'm not sure I understand what other state the ILS94208 could be in

IIRC, the WKUP pin on the ISL94208 is pulled high while the trigger is pulled or the charger is connected. The issue is that if the ISL94208 is put to sleep (which removes the VCC power from the PIC) while the WKUP pin is still pulled high (like currently happens when charging is complete but the charger is obviously still plugged in), then ~200uA can be drawn from the cell providing the VBACK pin. This may imbalance cell 1 after a period of months on the charger. The solution is to not put the ISL94208 to sleep when charging is complete.

Note: There is already a #define flag to disable sleeping when charge is complete, for other reasons I can't recall. However, then the PIC stays in the IDLE state and the current draw of the LED + PIC is enough that the battery will slowly discharge, hit the threshold, start charging again, and repeat. Thus, the battery cells would be cycled (and worn) slowly but constantly while just sitting on the charger, which isn't ideal obviously.

So, I think the solution is to leave the ISL94208 awake, have the PIC turn off the LEDs and go in to (PIC) sleep power mode, and then use the interrupt-on-change function of the PIC to wake it back up again when the charger is unplugged. Since I have serious trust issues, I'd probably just have the PIC do a full reset on wakeup so everything is definitely in a known state. Care may need to be taken with the existing watchdog timer setup which has some interactions with the sleep power mode from my brief skim of the PIC datasheet. After all of this, I'd ideally like to measure the current draw on all of the cells while the PIC is sleeping to make sure the battery pack can stay on the charger effectively indefinitely without any cell slowly draining. If the cells are draining with the PIC asleep, there would be nothing to wake up the PIC and have it enable the charger again.

There is a bit more info on this in a previous post, but you may have already seen this: https://www.eevblog.com/forum/projects/fu-dyson-bms-an-(unofficial)-firmware-upgrade-for-dyson-v6v7-vacuum-bms/msg4185037/#msg4185037

[robca]

Thanks again for the pointer to the description of the slow battery drain issue.

I read thru the thread, but somehow I didn't pay enough attention to that specific message, which I'm saving now for the future (once I understand the circuit and code better)

You've done an amazing job, thanks for your time and sharing it in an open source format

[rulof]

hello. I'm quite new to this. please tell me how can I make the temperature error reset when the charger is connected? as in the original firmware, after cooling, it starts charging itself.

[tinfever]

hello. I'm quite new to this. please tell me how can I make the temperature error reset when the charger is connected? as in the original firmware, after cooling, it starts charging itself.

The reason I implemented it that way, if I recall correctly, was that I didn't want it to be possible for an error to occur without the user knowing. If somehow there was an error that self corrected while the battery was on the charger, it would just resume charging and the user would never know.

Of course, I do understand where you are coming from. If you are using the battery hard, it might be within the safe discharge temperature limits, but too hot for the charging temperature limits, so if you immediately place it on the charger, you'll get that error.

I suppose an ideal solution would be to handle that case by allowing the battery to stay in the charging state, but not actually enable charging until the temperature has cooled down, and show the user a flashing yellow light or something. Possibly with a timeout of an hour or two so it isn't possible for the battery to stay in that state forever until the cells are depleted.

For now, here is a workaround:

If you replace line 641 in main.c, which is currently:

Code: [Select]

&& ((detect == NONE) || (full_discharge_trigger_error && detect == CHARGER))
with this instead:

Code: [Select]

&& detect != TRIGGER
that should allow the BMS to exit the error state while still on the charger. Of course, it will immediately go to the idle state, then the charging state, detect the temp as still being too high, and then go back in to the error state. It will do this loop for as long as the temp is too high for charging. However, once the temp is okay, it should start charging. I haven't tested any of this though.

I've attached a compiled .hex with this change if you want to try it. Again, I haven't done any testing so use it at your own risk.

If this doesn't take care of the issue, I'll need a lot more info about what you are doing when the error occurs, the exact error code, the reason you initially installed the firmware, etc.

[KalleMp]

Safety first.

I am glad the Fabulous-Universal-Dyson firmware upgrade is safety conscious.

Should it work too well it may attract attention and be GIVEN a bad reputation.

Call for Stopping Use of Battery Packs Manufactured by Shenzhen Ollop Technology Co., Ltd. Found in Rechargeable Vacuum Cleaners in Online Shopping Malls
https://www.meti.go.jp/english/press/2019/0809_001.html

[tinfever]

Fabulous-Universal-Dyson firmware upgrade

  I like that

[rulof]

Thank you so much. I will check how it will work and write the result.

Initially I have a V7, blinked red 32 times.
I charged each battery and flashed your firmware. Started working normally, running at a maximum of 4 minutes.

[rulof]

Checked, it works.  After cooling down, it starts charging itself, but it can again show an error in temperature, and so on a couple of times.
Of course, it would be ideal to add a timer after detecting a temperature error. about 40 minutes.
But you can use it like that.

[tinfever]

Thinking about it a bit, I wonder if the reason your pack is getting so hot is because the cells have aged and the ESR has increased in them. That might explain why you are the first person to run in to this. It would also tie in what you said about the battery running for about 4 minutes, probably either because the aged cells have reduced capacity, or just because the temperature limit is being hit due to high ESR.

[rulof]

Thinking about it a bit, I wonder if the reason your pack is getting so hot is because the cells have aged and the ESR has increased in them. That might explain why you are the first person to run in to this. It would also tie in what you said about the battery running for about 4 minutes, probably either because the aged cells have reduced capacity, or just because the temperature limit is being hit due to high ESR.

I totally agree.
But it works on the minimum mode for 26 minutes. This is more than enough.
I will change the voltage and temperature a little, I want to test how it will work.

[rulof]

Hello, I appreciate your effort tinfever and other collaborators. Thank you all very much.

I got an 32 red light flash on my V6 (battery label SV09, BMS board version is 188002). I opened battery and manually charged each cell to 4.2V. Then I flashed your custom FW successfully. It worked. But when I try to run with fully charged V6 at Max setting, after 2-3 min later I get an 3 Blue flash as low battery. After a couple min later I tried to run again, and about 1 min alter I get an 3 blue led flash again. But when I try to charge V6 in station, 1 blue, 1 Yellow (unbalance cell I mean) and after those 8 red flash. That mean charging over current. I wait  a minute to try again but every time I got an same 8 red flash. Is this normal. Or a bug on FW. Maybe 2.5ms is too short to read over current situation.

I solved 8 Red flash issue. I added series resistor to charge port for reducing charge current. When I add 1.2ohm resistor it solved charge over current error. When I measured charge current, I get a max 800mA. Not even Close to 1.4A limit. So I ,ncrease to sense time from 2.5ms to 5ms in isl94208.c file (tinfever firmware). It solved now.

Tell me more. I'm reading the firmware, but I can't figure out how to change the value by 5 m s?

[rulof]

Do I understand correctly?

to solve error 8, you need to change line 44

ISL_Write_Register(Set of chargers, 0b01001100);

in the isl94208.c file ?

[vidhome]

Hello Teenfever!
Thank you for the excellent work on the BMS Dyson firmware!
I have a 61462 SV03 board (it says so on the box). Worked fine, decided to check the balancing of the elements, opened and did not notice how damaged (shifted) resistor R27, then the Dyson firmware blocked and began to blink red 32 times. Changing the errors in the EEPROM did not give anything. I flashed your firmware, the LEDs are working, green blinks 6 times, blue, when the button is pressed, the voltage on the contacts is there.
The unbalance of the elements is 900 mv (18 times yellow), when installed on charging, green lights up immediately.
When I connect the vacuum cleaner and pull the trigger, I get 16 red blinks.
ISL_Write_Register(Discharge Set, 0b00010100);
ISL_RegData[Status] &= 0b11111011; - I tried your recommendations did not help!
EEPROM dump in the application.
Decryption
{
"Firmware": "Tinfever FU-Dyson-BMS V1",
"Total_Runtime_Seconds": 6.048,
"Faults": [
{
"index": 0,
"error_meaning": [
"ISL_BROWN_OUT"
],
"detect_mode": "Trigger",
"timestamp": 6.048
}
]
}
It is clear that this is ISL_BROWN_OUT.

Is this the verdict of ISL94208? Or is there hope?

[rulof]

Hello Teenfever!
Thank you for the excellent work on the BMS Dyson firmware!
I have a 61462 SV03 board (it says so on the box). Worked fine, decided to check the balancing of the elements, opened and did not notice how damaged (shifted) resistor R27, then the Dyson firmware blocked and began to blink red 32 times. Changing the errors in the EEPROM did not give anything. I flashed your firmware, the LEDs are working, green blinks 6 times, blue, when the button is pressed, the voltage on the contacts is there.
The unbalance of the elements is 900 mv (18 times yellow), when installed on charging, green lights up immediately.
When I connect the vacuum cleaner and pull the trigger, I get 16 red blinks.
ISL_Write_Register(Discharge Set, 0b00010100);
ISL_RegData[Status] &= 0b11111011; - I tried your recommendations did not help!
EEPROM dump in the application.
Decryption
{
"Firmware": "Tinfever FU-Dyson-BMS V1",
"Total_Runtime_Seconds": 6.048,
"Faults": [
{
"index": 0,
"error_meaning": [
"ISL_BROWN_OUT"
],
"detect_mode": "Trigger",
"timestamp": 6.048
}
]
}
It is clear that this is ISL_BROWN_OUT.

Is this the verdict of ISL94208? Or is there hope?

and each cell was charged separately?

[vidhome]

Yes, I recharged them a little

[erguro1973]

Hi! 

First of all my deep congratulations for all of the hard job that you did here, specially tinfever 

I know it's a little "off-topic"  but I post here because I think it could be interesting,  yesterday I opened a old DC35 battery, It´s also a 6 x 18650 battery but with a different BMS MCU

- Part number at battery case 17083-22 12
- Part number at BMS board   17522 01-05

I can confirm that the MCU in this BMS board is the ATTINY44-20MU 20-QFN-EP
After reading datasheet I connected my USBasp pogrammer to:

Pin 16  MOSI
Pin 20  MISO
Pin 13  RSET
Pin 1     SCK
Pin 8    GND
Pin 9     VCC (+5V)



I succesfully downloaded Flash + Eeprom but I don´t have enough knowledge in dissassembly these files to do something interesting as tinfever did

If someone it´s interested I can upload here

Best regards

[Momy]

Yes, I recharged them a little

Hi,

Same problem (SV03 battery).

[nikifena]

Hi guys. I missed somehow this topic, but I'm going to share with you my experience with those Dyson batteries. Mine was V6 if I'm not wrong.
I had Dyson vacuum cleaner with a bad battery, and then I brought a replacement. Soon I realized that the problem is with the firmware. It detects unbalanced batteries and stop working. Then it writes the error in the PIC internal eeprom. So, I connected the working battery to the pickit3 and lucky enough, the eeprom portion of the firmware was unprotected. I simply downloaded it and uploaded ONLY it to a non-working battery. Then the non-working just starts working.
I found that the eeprom is updated regularly after turning on/off cycles. Unfortunately, you know, the battery dies when the balancing is away from the original specs... A good solution of course was to change all cells.

Anyway, here is a working Eeprom. Keep in mind that you MUST program only the EEPROM part and skip the main code from programming!

[tamtamsh]

My Dyson V6 got a red flash error. It flashed 10 times red light. I detached the battery from the vacuum, it flashed blue and green which means the PCB was not locked. So I thought the motor had some errors, I bought a 2nd hand motor, it didn't work either. I have no way out, so I burned the author's firmware. It looks look, but we when I attached the battery to vacuum and pressed the trigger, it got 16 flashes of red light, the machine didn't work either. 16 red light means there is hard short circuit. I don't know how to get it resovled. Please give me your expertise advice. Thanks.