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:
{
"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.