Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some notes from successful re-programming #24

Open
NeilMarley opened this issue Feb 25, 2023 · 5 comments
Open

Some notes from successful re-programming #24

NeilMarley opened this issue Feb 25, 2023 · 5 comments

Comments

@NeilMarley
Copy link

NeilMarley commented Feb 25, 2023

Hi, first of all many thanks to you & other contributors to this project - it has proved invaluable for my own project of salvaging a number of these battery packs to repurpose (primarily as e-bike power packs). For fun - see my current batch below:

3 x 61462
1 x 228499
2 x 188002
1 x 180207.

All reprogrammed with the new firmware & working perfectly.

IMG_0503

A few notes from my experiences which may help others:

  1. I did initially manage to brick a few BMS boards (the ISL94208 chip) while re-programming the firmware with PicKit3. It's clear that the BMS circuitry isn't designed for an external application of VDD, particularly while in sleep mode. I've since found that the most safe and reliable method is to not connect VDD from the PicKit at all, and also to not wake-up the battery pack. The programming works fine & reliably with only VPP from the PicKit.

  2. I altered the MAX_CHARGE_CELL_VOLTAGE_mV setting to 4100 in the interests of extending cell life but initially this caused a cycling error by interacting with PACK_CHARGE_NOT_COMPLETE_THRESH_mV which was also set at 4100. It might be worth a side-note that the latter should be lower than the former with a bit of margin for charging voltage rises?

  3. On occasion a reprogrammed board would work fine functionally but the LED blinking patterns were really slow. It could usually be fixed by reprogramming again. I have noticed that the slow condition has the PIC Config bits set at 3FFF 3703 while the working version is 3FFC 3703.
    I think this is a PicKit application bug which sometimes sets the operating frequency config of the PIC back to default even when re-loading the same HEX file.

@tinfever
Copy link
Owner

tinfever commented Feb 26, 2023

That's awesome! I'm glad to hear you've had so much success!

On your notes:

  1. That's a very interesting finding. I broke a few of the ISL94208 chips as well during development but usually didn't know why. It was almost always a short circuit to GND on the 3V3 regulator control pins of the IC. Leaving VDD disconnected entirely, not waking up the pack, and just using VPP is interesting. I've never tried that but I'm kind of surprised it worked since why else would Microchip recommend connecting VDD for programming?

I think I may have mentioned at some point, somewhere, that I don't recommend having the PicKit supply VDD and I was suggesting people wake up the battery pack instead for VDD. Leaving VDD disconnected makes perfect sense in either case, as long as the programmer doesn't complain about being unable to detect it. I'm going to add a note in the instructions about that. Then I'll pin a comment on the YouTube video and update the EEVBlog forum post to refer anyone to the GitHub page for the latest information.

I wonder if VPP is forward biasing the internal ESD protection diodes to VCC inside the PIC and that is how it is getting powered? Then again, PICs can use high voltage programming so that would be dumb.

  1. That's a good point. Without digging in to it again, PACK_CHARGE_NOT_COMPLETE_THRESH_mV could probably always be set to like 100mV below MAX_CHARGE_CELL_VOLTAGE_mV automatically. Or just add a note like you said haha

  2. Good catch. I haven't run in to that personally but someone else saw similar symptoms using a third party programmer and eventually determined it was the config bits like you saw. Although for them it was a software setting error vs an application bug.

@NeilMarley
Copy link
Author

No problem, it's the least I could do given the efforts of others on this....

  1. Looking at the schematics it's probably no real surprise that providing VDD to the ISL94208 Reg input pin while it's in sleep mode pops some internal transistor. & as you say, the result is a short from VCell 6 to Gnd so I've also had a few Cell 6 go 0v or reverse biased? It prob would be ok to power the Pic from the battery pack but relies on either the VDD tick-box being off in PicKit or the VDD wire not being connected - the latter is more idiot-proof (advice from a proven idiot)?

  2. I did a few programming cycles on this & with the same BMS always connected & doing a few re-flashes - around 1 in 5-10 changed the config bits. It might just be my set-up but it was repeatable....

Regards

@NeilMarley
Copy link
Author

Oh, & I should have said - this isn't really an issue being raised - feel free to clear :-)

@KerOzenn44
Copy link

Hello,

I successfully programm a 188002 ! Thanks ! However :

  • I don't have the expected "Red-Green-Blue flashes - Looks fancy..." While pulling trigger :
    The red is missing ! Not a big deal I guess.
  • I have the version 1 of the firmware, the only I found. Is there other one ?

Regards

@torsoreaper
Copy link

Wanted to add my experience. I have a Dyson V7 battery and can confirm I was able to flash without VDD and without waking the battery.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants