This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BQ20Z65-R1: Successfull learning cycles, but a bit confused about Update Status and sealing

Part Number: BQ20Z65-R1
Other Parts Discussed in Thread: BQ20Z65, BQEVSW, BQ20Z80

Hello,

First, I apologise if this question has been posted already, I did do an extensive search but couldn't find a similar question being posted elsewhere.

I'm using the BQ20Z65 in a 4P4S battery, got it calibrated without the cells connected, this went flawless, eventually the cells got connected and used the BQeasy button in BGEVSW to get the right chemical ID in there (2012 for Panasonic NCR18650B, I tested this and this ChemID is indeed present) and then started the learning cycles as described in one of the many application reports. This also without problems.

Using my phone to time the whole operation, I could also see everything worked out well, UpdateStatus changed to the values it should get and so on. I know the learning cycles can be done automatically but that means I have to put a lot of trust in my setup and though I'm not stupid, I'd rather keep an eye on a charging and depleting battery).

By now, the learning cycles have completed, Qmax values are now correct, the 'At rate time to ....' timers are incredibly precise (I had a somewhat 40 second difference between the time reported in BQEVSW and the timer on my phone over a 324 minute period), UpdateStatus is now 0x0E, meaning cell-balancing is activated, so the golden image is ready to be made. The screenprint you see here is made during a learning cycle.

What I don't completely understand yet is the Update-status: with 0x06, the datasheet mentions this as ' QMAX and Ra table have been updated and Impedance Track algorithm and lifetime data updating is enabled.'
0x0E says: 'QMAX has been updated with FC set and qualified OCV in discharge and charge.
'

But when I look at slua355B, step 8 describes '8. Repeat steps 4 through 7 to achieve maximum impedance table accuracy. Verify that DF.Gas Gauging.State.Update Status reads 06. If not, repeat the cycle. Its normal value should be 06.'
Though I know slua355B uses the BQ20Z80, I'm a bit confused. Because the golden image sets Update Status to 0x02 for production: does this mean that cell-balancing will be turned off or that I have to initiate the IT-algorithm as well for any new pack?
If 0x0E just indicates cell balancing has been activated for the rest of the parts' life, that's fine, I'm just a bit in the dark here.



About sealing: the batteries I have are my own and do not connect to a smart charger (though I wish they would) or smart device that communicates the remaining charge. So sealing for my parts isn't all that necessary. Is it a risk to not do so?


If everything above is right, 0x02 is fine for Update Status, then I'm there.

Just let me say that this is complex, but all the application reports out there really help you get a long. Once I got going, this by far is one of the most remarkable pieces of technology I have ever worked with.

Thanks in advance.

  • Update status of 0x0E means that the learning is complete. Now you will need to make a "golden image". The "golden image" is where we want Update Status to be 0x02. After this "golden image" is programmed to a new pack, then send the IT enable and any other enable commands that you want. We recommend that you check the status bits to make sure everything is as expected before repeating this procedure in production.

    We recommend that you seal the device. This ensures that any glitches on communication line do not accidentally send a data flash write command that may change settings.

  • Thanks. So it behaves like I expected ;)

    I'll take the sealing-recommendation and do it.

    Now I only have to figure out why trying to create (and at the same time, update, as bqeasy does) the golden image not only creates communication errors every time, but also (and maybe because of those communication errors) resets Cfg A, B ánd C back to it's default settings, resets update status to 2 (like we want to), but sets Qmax to 144%. Because that surpasses the Max Error limit, it requests a condition cycle which I can only start by SMbus-command intervention. I now think about forgetting the learning cycles as done via bqeasy, but sending the IT-command myself and starting to charge and discharge the thing again. I tried the autocycle-function, but could not get it to work (the Help-function is 'odd' to say the least when it comes to which pins I need to use to enable the charger or load (setup with relaxation times).

    Thanks so far.

  • Fiddled with the thing again... not with the result I wanted.


    So let me get this straight: I think I now fully sense what I need to do/achieve:


    To recap:
    - The learning cycles complete perfectly, times are accurate and both Absolute and Relative SoC make sense.
    - Update Status eventually changes to 0E after 3 cycles when starting fresh.
    Update Status gets there in something like 1,5 cycles as MaxError has changed to 144% AGAIN, and Update Status to 02, this after my silly attempt to write back the altered .gg file (Update Status changed to 02) I exported after succesful cycling with Update Status at 0E.

    - At reaching Update Status 0E I first need to extract the dataflash to a .gg file.
    - I can then seal the device as this part has finished learning. The .gg file I exported is opened to change Update Status to 02, which is then loaded into a new target.
    With that target, I can do whatever I want and (ofcourse) start Impedance Tracking to get it to learn it's new cells (because obviously no cell will be an exact match)

    I'm sorry if I'm coming on a bit foolish here, but this last step is a bit troublesome to me. I would be gratefull for a last push in the right direction.

    Thanks in advance.

  • Hello Menno,

    After update status 0x0E, change the update status to 0x2, write cycle count to 1 and then extract the *.dfi file or *.rom file. The *.gg file does not contain all the information.

    In production

    1. Program *.dfi or *.rom

    2. Calibrate

    3. Attach cells

    4. Send IT Enable command and any other enable commands as required

    5. Send Seal command

    Do not send the seal command to any pack until it is ready to ship.

  • First: When I try to change the Update Status to 02 in bqEVSW myself, I get a 'Runtime error '13': type mismatch' . The fuel gauge reads zero, so that can't be the issue.

    That's why I thought I had to reload the .gg file with Update Status set back to 02 into the device, which not really had the desired result to say the least Upside down

    So, just for my understanding, as this last step proves to be harder than I thought:
    - As I have a golden image already, I can skip creating (another) one (though it's probably a good idea in my case to do so one more time to make sure I got everything right)


    - The .gg file is basically not needed?


    - I need to open bqEVSW, go to the bqEASY tab, click the 'load/read DFI or ROM file' button and then 'select DFI-file manually' browse for '_0650_0105_GOLDEN.DFI' file as this has been created by the program and program this into the bq20z65, whether it's the one I have now, or another one.

    - Then I calibrate the part (I'm afraid there's no way around that though I already calibrated the part via 'Calibrate' in the bqEVSW myself), attach the cells and enable IT. I expect I need to cycle it like I would cycle the first pack before I seal it?

    Thanks so much already. I've come so far by now it would be a pity if this last step would be the hurdle that makes me fall.

  • Hello Menno,

    Program the DFI file and check if update status value is 0x02. If yes, then you are good to go. If not, it will need to be set to 0x02.

    The golden image is good enough if all cells have tight manufacturing tolerance. Otherwise accuracy will be a little worse until the first learning cycle happens in system.

  • Yes! It really seems I've got this thing going in the right direction now.
    1. I got the golden .dfi file, programmed it into the device (which went flawless to my surprise, considering the errors I got in creating the golden file), update status in that file is 02 like we want. MaxError is still at 144% though, but as learning cycles before this (with update status at 02 as well but then because of my action to write back an altered .gg file) changed this quickly to 0E and updating MaxError to a normal value, I expect this to change. Otherwise I'll go over creating a new golden image, just to be sure.

    2. Calibration went okay.

    3. Cells were re-attached (as calibration with cells attached is not recommended)


    4. Just sent 0021 to Manufacturer Acces to enable IT. It's now charging and I'll report back on the status.

    Thank you again! Have a nice weekend!

  • Hello. Sorry that it took me so long to respond to this, but I got incredibly ill from my second covid-shot and have not been at the chips for the last 3,5 weeks or so.

    To make a long story short: It's working! It's working! Thank you so much for your help.
    I most likely destroyed one BQ chip in trying to solder back a connection (which caused a short on the pack-output) or had a FET fail on me, as after the short and resetting and trying again with the same PCB, everything seemed to go flawless. But placing the battery on the device it needs to power, immediately got the display LEDs lighted, with the fifth flashing like it was charging and the devices turning on and off again within 2 seconds (And then retrying). It reported a charge FET-failure. Retrying the whole operation with a different PCB went exactly as it should. The battery is now fully functional, balances perfectly and powers the device!

    Thanks again!

  • Hello Menno,

    You are welcome! Good to know that everything is working. Take care.