-
PIC: Attempting to dump firmware on PIC16LF1847 from Dyson Battery
Posted by tinfever on 21 Dec, 2021 01:09 -
I'm trying to read the configuration bits to confirm the firmware is read protected, or dump the firmware if not protected, from a PIC16LF1847. The PIC is on the battery management PCB from a Dyson V7 battery pack that has gone into permanent lockout due to unbalanced battery cell voltages. This was started in this thread: https://www.eevblog.com/forum/reviews/dyson-v7-trigger-cordless-vacuum-teardown-of-battery-pack/25/
I'm fairly sure I've correctly identified the necessary pins on the board to connect to the PicKit 3 (clone) I have, I'm able to have MPLABX successfully recognize the PIC, and it says it is reading the memory with no error messages. However, after reading it, nothing appears to change. It also appears to be reading the configuration bits but again, nothing appears to change when I read it.
Could someone help me figure out what I'm missing here? I feel like I should either get some sort of message saying "I'm sorry, Dave. I'm afraid I can't read the memory because it's locked." or otherwise I should be able to read the memory successfully. This combination of no error and also no data is very confusing.
Also, if I leave the VPP line disconnected, I get a message about an invalid device ID (0x0), but then I also get different configuration bits read back that actually do show the read protection bits being set.
I'm linking a .gif animation of my entire workflow, and attaching a few screenshots, the probably empty .hex export after a supposedly successful read, and the PCB photos I've taken with some of my annotations.
Thank you!
-
Your HEX file is all ones. The PIC is either dead, erased, or there is a connection problem. May be the problem is that ICSPDAT is stuck high because of some sort of interference.
-
Read protected pics won't drop any error when reading, will simply send nothing, like it's doing.
If the pic is recognized, the connection is ok.
-
Read protected pics won't drop any error when reading, will simply send nothing, like it's doing.
If the pic is recogniced, the connection is ok.
If it is read protected, is it possible to at least read the config bits to confirm that it is protected? -
Code protected chips should return all zeros (DS 4.3.1). Do you have a spare chip to verify you can read/write a non-protected chip? You might also try reading User ID (DS 4.5).
If all else fails and you are convinced everything is connected and working properly, erase the PIC. Read (target is blank), then program some nonsense and read again. That won't get you the firmware, but it will confirm you are doing it right. -
Code protected chips should return all zeros (DS 4.3.1). Do you have a spare chip to verify you can read/write a non-protected chip? You might also try reading User ID (DS 4.5).
If all else fails and you are convinced everything is connected and working properly, erase the PIC. Read (target is blank), then program some nonsense and read again. That won't get you the firmware, but it will confirm you are doing it right.
I don't have a spare chip unfortunately. That's a good idea look at the user ID. I just tried reading them and while the default in a new project is 0x3FFF for all four, after reading the device memory, I do see different values. I'm guessing this is a clear indicator the PIC is protected since it is returning nothing except for the user ID data? I guess I'll have to decide if I want to dig even deeper and try to use the scope and logic analyzer to see what's actually being sent and compare it with how the ICSP protocol is supposed to work, or just try to erase it like you suggested.
Before read:
After read:
-
It certainly looks like a user ID, which is readable despite code or eeprom protection.
I agree that is consistent with the chip being protected.
When you say it returns "nothing" from program memory, are you seeing 0's or 1's (as stated in your original post)? The Microchip statement I referenced (DS 4.3.1) about protected chips returning all zeros may be ambiguous. Perhaps it means all 0x3FFF. That's what I see when reading blank program memory. I have never tried to read a hex file from a blank chip, so I don't know what to expect when that is done. -
If it is read protected, is it possible to at least read the config bits to confirm that it is protected?
As far as I know, yes.
Use Mplab IPE instead IDE!
Click on Settings...Advanced mode. The default password is "microchip".
Now you can enable Window...Target memory views...Configuration Bits
Click on Read and you'll see everything. Check the Code protection bits (CP).
You can switch anytime to Program memory view using the Memory selection field at the bottom.
Newer tools are getting so damn complicated without needing so.
I miss older ones, everything was simple and organized in a single window...
I've just tested it with a 18F1330 I had in my junk drawer. When protected it reads all 0s.
PIC16LF1847 has only one CP bit.
-
It certainly looks like a user ID, which is readable despite code or eeprom protection.
I agree that is consistent with the chip being protected.
When you say it returns "nothing" from program memory, are you seeing 0's or 1's (as stated in your original post)? The Microchip statement I referenced (DS 4.3.1) about protected chips returning all zeros may be ambiguous. Perhaps it means all 0x3FFF. That's what I see when reading blank program memory. I have never tried to read a hex file from a blank chip, so I don't know what to expect when that is done.
I'm seeing 1's, or all 0x3FFF values to be precise. I don't know if that's because when the IDE/IPE receives no data it just leaves the default 0x3FFF values or if it means something else.If it is read protected, is it possible to at least read the config bits to confirm that it is protected?
As far as I know, yes.
Use Mplab IPE instead IDE!
Click on Settings...Advanced mode. The default password is "microchip".
Now you can enable Window...Target memory views...Configuration Bits
Click on Read and you'll see everything. Check the Code protection bits (CP).
You can switch anytime to Program memory view using the Memory selection field at the bottom.
...
I've tested in both the IDE and IPE with the same result. That is, the default values shown in the configuration bits window after opening the IPE do not change after reading the PIC.
I'm wondering if there is something else amiss here, especially since when I disconnect the Vpp line and attempt a read, after bypassing the warning of 0x0 being an invalid device ID I actually do see different configuration bits (with the protection showing bits enabled). It's going to be a bit hard to work on this for the next week but I'm going to probe out more of the circuit to make sure nothing else is on the pins used for the ICSP and I'll see what the logic analyzer shows is actually happening. I also need to read more on how exactly the ICSP works in the first place. -
I'm seeing 1's, or all 0x3FFF values to be precise. I don't know if that's because when the IDE/IPE receives no data it just leaves the default 0x3FFF values or if it means something else.
That's what you get when the PIC is blank (erased). Of course there may be errors too. But if you can read the device id (and it is correct?) and user id, then the connection is probably Ok.
If you disconnect Vpp you shouldn't be able to read anything. Noise perhaps, or PIC driving some signals.
You can also try HVP (uses 9V on Vpp, sometimes called dual voltage) and LVP (sometimes called single voltage) mode when reading and see if you get the same result. -
If you remove VPP, Pic doesn't enter programming state, will ignore anything sent by the programmer.
LVP is a programming mode that must be enabled in the config bits.
Yet waiting for the config bits picture, stop losing time with other stuff.
If CP is set, game over, only way will be some hacky stuff if existing at all. -
LVP is a programming mode that must be enabled in the config bits.
Actually, LVP is the default for obvious reasons. -
You're right
.
I remember several issues back in the day, can't tell you what, but I always disabled it!
Checking the programming manual, the default values for config1/config2 are 3FFFh/3713h.
(LVP enabled) The default user IDs are also there.
-
I'm trying to read the configuration bits to confirm the firmware is read protected...
Hello tinfever,
I just found your trail of work over the Dyson battery error. I have a similar V6 battery that would be great to just clear the error and reuse the BMS, because after balancing the cells and testing the capacity of the pack, it's around 75% of the original.
The main purpose is to make work the ISL94208IRZ, right? If this IC can at least charge the pack just by itself, without the PIC actually working, would be good.
From what I read today over the internet there is no way to read a protected PIC, you can just erase-it but forget about reading-it while it's locked.
If you can you just erase the PIC and load another PIC code, maybe from a similar BMS ( they say the main use of ISL94208 is for tools ) so it may be out there another implementation of this thing.
I can think, in extremis, just changing the dyson loaded PIC with a brand new one, if the original cannot be erased ( it may be hard to replace, since this is such a fine pitch IC) and program-it with some working load.
Maybe someone has a similar working PIC code for ISL94208 to use for the PIC in this Dyson pack.
As a backup solution I ordered the V6 compatible BMS they sell on Ali and will arrive somewhere in January, the one good thing about-it is that it fits exactly the pins of the original battery pack. Probably they use this BMS in all this aftermarket V6 battery packs out there, but the cells in those battery are not as good as the dyson ones. The compatible BMS looks like it has also the PICkit header ( in the picture from Ali site). We'll see that in January.
Maybe with just the PicKit set we can erase the PIC and then load some working load to allow the pack to charge and discharge. Forget about the balancing or any other fancy monitoring scheme that is implemented by dyson.
What do you think? -
The ISL94208 is complex battery management IC, you have to load several registers at power-on that defines its working conditions.
The datasheet is available, also the micro code programming manual.
This guy made something with it, but deleted the github repo:
https://robingingras.com/2019/09/04/battery-bank-prototype-1/
Perhabs you can send him a message asking for the code! -
Check if data EEPROM is also protected (it is controlled by a separate config bit), the lockup flag should be stored there most probably.
-
The ISL94208 is complex battery management IC, you have to load several registers at power-on that defines its working conditions.
Hello, this is great, thank you for your answer, it's amazing someone actually used the same IC battery manager as Dyson to create a new design. Never would think about that, what a coincidence.
The datasheet is available, also the micro code programming manual.
This guy made something with it, but deleted the github repo:
https://robingingras.com/2019/09/04/battery-bank-prototype-1/
Perhabs you can send him a message asking for the code!
If the Dyson PIC can be just erased and loaded with something else and save the battery then this would be great!
I contacted Robin and asked him if he wishes to contribute to this battery salvage project. Since he's familiar with the instructions to be put into the ISL94208 battery manager, maybe he can share some of his code.
His github is at: https://github.com/archnemesis?tab=repositories I do not see his old project from 2019 there.
Thanks
-
From what I read today over the internet there is no way to read a protected PIC, you can just erase-it but forget about reading-it while it's locked.
There is, you can either pay $$$ to "MCU break" service or try to do it yourself. This isn't a high security device so maybe power glitching may work. But it may be easier and cheaper to just write your own firmware. -
The ISL94208 is complex battery management IC, you have to load several registers at power-on that defines its working conditions.
Hello, this is great, thank you for your answer, it's amazing someone actually used the same IC battery manager as Dyson to create a new design. Never would think about that, what a coincidence.
The datasheet is available, also the micro code programming manual.
This guy made something with it, but deleted the github repo:
https://robingingras.com/2019/09/04/battery-bank-prototype-1/
Perhabs you can send him a message asking for the code!
If the Dyson PIC can be just erased and loaded with something else and save the battery then this would be great!
I contacted Robin and asked him if he wishes to contribute to this battery salvage project. Since he's familiar with the instructions to be put into the ISL94208 battery manager, maybe he can share some of his code.
His github is at: https://github.com/archnemesis?tab=repositories I do not see his old project from 2019 there.
Thanks
I think if you just want to use the battery pack without some of the protections like undervoltage (over-discharge) protection or overvoltage (over-charge) protection, it'd be easy have a simple program on the PIC that says "if button is pressed, tell ISL94208 to turn on discharge MOSFET". However, I'd really like to have all the usual protections like so I can use the normal charger (which is just 26V 750mA if I remember) and not worry about discharging the battery too far.
Using the code from another ISL94208 project is an interesting idea. It'd be interesting to see how complex the code required really is. Perhaps I'm naive but it seems like it might not need to be much more than:
loop {
Check_voltage_of_all_battery_cells
If cells are out of balance by more than 100mV: enable balancing switches on ISL94208
If max cell voltage is greater than 4.2V: disable charging MOSFET (probably needs hysteresis)
While switch is pressed and min. cell voltage is greater than 2.7V: enable discharge MOSFET
}
Then just add some LED indicator light control, and figure out the power-on sequencing and control of the ISL94208 and PIC. The PIC runs off of the 3.3V regulator controlled by the ISL IC and I haven't figured out what part of the circuit controls the wake up of the ISL IC. Could add a lockout function with the magnet sensor / reed switch for safety. I think the ISL IC handles short circuit protection and over current protection but that may need some configuration. The ISL94208 is controlled over I2C.
I'm not able to work on this a ton for the next week or so due to the holidays but I'll report back with what I find. -
For some reason I had made the repo private, I have now unlocked it. I can't remember if I found the ISL94208 library somewhere on the internet, or if I wrote it myself, been so busy with other projects. I hope you find it useful.
I've never used PIC microcontrollers and I don't really know much about them, so I can't help you there.
https://github.com/archnemesis/BatteryPack_ISL94208_6S/blob/master/lib/ISL94208/src/ISL94208.cpp -
I think if you just want to use the battery pack without some of the protections like undervoltage (over-discharge) protection or overvoltage (over-charge) protection, it'd be easy have a simple program on the PIC that says "if button is pressed, tell ISL94208 to turn on discharge MOSFET". However, I'd really like to have all the usual protections like so I can use the normal charger (which is just 26V 750mA if I remember) and not worry about discharging the battery too far.
Using the code from another ISL94208 project is an interesting idea. It'd be interesting to see how complex the code required really is. Perhaps I'm naive but it seems like it might not need to be much more than:
Hello tinfever,
Archnemesis was kind enough to share the code he used 2 years ago for his battery project, it's here:
https://github.com/archnemesis/BatteryPack_ISL94208_6S/tree/master/lib/ISL94208/src
I am not capable to figure out how that .cpp file can be converted/modified into PIC code since I am not familiar with both controller architectures.
It would be great if you have the skills to use-it to make a working PIC load. If you can explain as god as you kindly did until now, I will be happy to learn myself.
It looks it has many routines, including balancing.
Then, if you succeed to erase the PIC and load a new code, I will be happy to get my own PICkit and try do the same. I am sure many people would love the outcome of this project.
( and the makers of PICkits also..
Regards and happy holydays!
-
I think if you just want to use the battery pack without some of the protections like undervoltage (over-discharge) protection or overvoltage (over-charge) protection, it'd be easy have a simple program on the PIC that says "if button is pressed, tell ISL94208 to turn on discharge MOSFET". However, I'd really like to have all the usual protections like so I can use the normal charger (which is just 26V 750mA if I remember) and not worry about discharging the battery too far.
Using the code from another ISL94208 project is an interesting idea. It'd be interesting to see how complex the code required really is. Perhaps I'm naive but it seems like it might not need to be much more than:
Hello tinfever,
Archnemesis was kind enough to share the code he used 2 years ago for his battery project, it's here:
https://github.com/archnemesis/BatteryPack_ISL94208_6S/tree/master/lib/ISL94208/src
I am not capable to figure out how that .cpp file can be converted/modified into PIC code since I am not familiar with both controller architectures.
It would be great if you have the skills to use-it to make a working PIC load. If you can explain as god as you kindly did until now, I will be happy to learn myself.
It looks it has many routines, including balancing.
Then, if you succeed to erase the PIC and load a new code, I will be happy to get my own PICkit and try do the same. I am sure many people would love the outcome of this project.
( and the makers of PICkits also..
Regards and happy holydays!
You need to find a C++ compiler that will target your chip. -
That code can be converted to standard C with little work, 90% is just replacing :: with _, ex:
ISL94208::sleep
ISL94208_sleep
Actually you only need to work on the hardware interfacing functions: writeRegister and readRegister, which mean "write to i2c, read from i2C".
Pic hardware is really simple, but before doing so you should reverse engineer the schematic, don't play with batteries like that, protection systems must be preserved. -
Thank you rstofer for your suggestion, it makes sense.
I think if you just want to use the battery pack without some of the protections like undervoltage (over-discharge) protection or overvoltage (over-charge) protection, it'd be easy have a simple program on the PIC that says "if button is pressed, tell ISL94208 to turn on discharge MOSFET". However, I'd really like to have all the usual protections like so I can use the normal charger (which is just 26V 750mA if I remember) and not worry about discharging the battery too far.
Using the code from another ISL94208 project is an interesting idea. It'd be interesting to see how complex the code required really is. Perhaps I'm naive but it seems like it might not need to be much more than:
Hello tinfever,
..................
Regards and happy holydays!
You need to find a C++ compiler that will target your chip.
Meanwhile, I was targeting the Home Depot recycling box and I just found another V6 battery with still good working BMS.
I rather do a live "beating heart" transplant of the BMS in another battery with good verified cells. I did similar cell change with laptop battery, it's needed to keep the same constant voltage on the BMS pins while changing the cells with the new ones.
Like DavidAlfa kindly mentioned " don't play with batteries like that, protection systems must be preserved." , I believe re-compiling and reverse engineering the schematic to check the correct I2C code it's too much for me.
Maybe tinfever can tackle this after the holidays hungover, since he played already with the PicKit and he seems somehow familiar with C programming.
Cheers -
Hello tinfever,
I received the Ali BMS and replaced-it in my V6 battery with seems to be good results, here : https://www.eevblog.com/forum/reviews/dyson-v7-trigger-cordless-vacuum-teardown-of-battery-pack/50/
Please keep us posted with any results on the attempts to re-write the Dyson BMS code.
I feel I might be able to find in the future a recycled battery somewhere so it will be interesting to try re-setting the red lights conditions.