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.

BQ28Z610 - Golden file and programming without EV2300

Other Parts Discussed in Thread: BQ28Z610, BQSTUDIO, EV2400, BQPRODUCTION, BQ34Z100-G1

Hi TI Community,

I am preparing to perform learning cycle for 1s4p configuration of UR18500F cells (Chem ID = 0107), but I have some questions.

  1. I know exact model of cells, but configuration is 1s4p not 1s1p. Is it required to perform ChemID identification in rel-dis-rel process too (before learning cycle)?
  2. Which file is default "Golden Image" for bq28z610, .srec or .gg or maybe .gg.csv?
  3. Is there any chance to flash bq28z610 with .srec or .gg file using microcontroller (i.e. stored as byte array in uC flash) or only possible way is to use EV2300?
  4. In my opinion .gg file is a simple hex dump, so I can write it to Data Flash memory. Does it contain information about chemistry?


Thank You
Maciej Jeleń

  • Since you know the chem id already, you just need to program the chem id, and then change design capacity to reflect a 4p configuration. No need for a rel-dis -rel. You however, have to perform a learning cycle so the gauge learns the resistance and total chemical capacity of the entire pack.

    Your golden file which you extract after learning should be your srec given it contains the chemistry data. the gg files do not contain the complete chem id data. You can flash your IC using your host but you will have to write code to do this. If this is not a high volume project, i suggest sticking to bqstudio.

    I hope this helps
    thanks
    Onyx
  • Thanks for quick response!

    However I will try to flash .srec to bq. Is there any document describing that process or in your opinion will be helpful? In this thread: e2e.ti.com/.../446520 Justin Erfan informed that TI is working on material like that.

    Maciej
  • Hi Maciej

    Click on the firmware tab of bqstudio, click the browse button on that window and go to where you saved the srec. Check the execute after programming check box and then hit the program button. This will flash the srec on the device.

    To read the srec, browse to where you want to save the file and then click the read srec from device.

    thanks

    Onyx

  • Hi Onyx,

    Sorry, but I did not describe my question clearly.
    You described .srec programming using bqStudio and EV2300/EV2400 interface (it is even a video tutorial, describing this process) but I meant .srec programming by standalone microcontroller soldered on same PCB with bq. Is there any document describing this particular problem or similar (I have found slua541, but it contains information about bq275xx series gas gauges)?
    I recorded .srec file uploading with logic analyzer. I see same bytes in .srec and in stored waveform, but I would like to know packet structure and are there any start and stop conditions (if it is not a company secret of course). Because of that I pasted link to this discussion e2e.ti.com/.../446520

    Once again sorry for confusion.

    Thank You
    Maciej Jeleń

  • Ah ok. The srec is a standard motorolla format, so you would program it on the gauge like you would any other srec file. There currently isn't any documentation for that.

    thanks
    Onyx
  • Thanks a lot!
    Maciej
  • I am actually trying to figure out how to do production programming as well, as I don't see an easy way to command BQ studio from another program. I would also prefer to program the device via the host MCU on our boards. Is it as easy as writing the contents of the SREC file via I2C writes? Is there a base/starting address? What is the protocol? Thanks!
  • Ah ha, I think SLUA391 was what I needed. So the Chem ID LUT, calibration values, and configuration are all contained in dataflash correct? So using the MCU to read out the dataflash via alt mfg access I2C commands, saving that, and then writing it into another unit should work?
  • Hi Cory,
    yes they are contained in the data flash, so except you do a dump of the entire data flash and then write on another device you will be unable to correctly program another device using the method you describe. that is why you need to use either the srec or flash stream method for programming.

    thanks
    Onyx
  • I am a bit confused with what you mean... I am saying that I would complete the learning cycle, read out the dataflash via the controlling MCU over I2C and save that flash image to external storage of some sort (USB flash, SD card, etc) then during production, load the golden image from external storage and write to the BQ using the MCU. That would not work? 

    What do you mean by srec or flash stream?

    Thanks,

    Cory

  • the srec is a dump of the instruction and data flash of the gauge which will be stored in your usb and can be written via i2c to the guage.

    thanks
    Onyx
  • Is there a document which enumerates the ROM commands available to program the .srec?  I understand that the file format for .srec is an old Motorola format; however, I cannot find documentation for what commands are available once the part is placed into ROM mode.

  • Hi Jason,

    The ROM commands are proprietary and that isn't something we share unfortunately. We do have the tool bqproduction for programming multiple units of the device though and i believe we provide can provide the SDK for bqproduction. Pls reach out to your local FAE to facilitate this if that is something you need as we will need NDA to be allowed to give out the SDK.

    thanks
    Onyx
  • Hi Onyx,

    Thank you.  I will talk to our FAE.  We did have an NDA but it has expired.

    -Jason

  • SIR, i need to change my chem id in bq34z100-g1.can you send the i2c sequence command for chem id change.
  • Arun,
    You will need program the chem id using either bqstudio, then extract an srec or you will have to program your srec that already has the desired chem id in it. The chem id is proprietary data and we can't share the registers they are located in. Sharing the i2c sequence command will expose that.

    thanks
    Onyx