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.

BQ40Z60: BQ40Z60: Flash Records

Part Number: BQ40Z60
Other Parts Discussed in Thread: BQSTUDIO

Dear
Faced a problem when programming BQ40Z60. We want programming BQ40Z60 for Mass Production without EV2300. We write through our microcontroller. The file with the data is formed as you advised ("BQ40Z60:BQ40Z60 What data is recorded at 0010x0000...").

We used recommendations from the TRM "11.1.63 0x4000-0x5FFF Data Flash Access()". Writing for 16 bits, then we wait for a response from BQ40Z60 with a checksum check. But often we do not get any answer. The time-out was increased to 5 seconds. The recording passes, but with errors (some bits are not true).
We can not understand how to record correctly. If there is no answer, do I have to write from the previous byte or start over from the beginning (0х4000)?
At the same time, if BQ40Z60 has already been written via EV2300, it is updated through our microcontroller without problems (the recording goes without interruptions and stops). The problem with the initial recording and configuration.

The record is produced Operating Status [SEC1=0, SEC0=1] (the default setting-device is shipped from TI in this mode (full access?))
Is there an error here?
To translate into SEC1 = 1 SEC0 = 0 it is obtained only by preliminarily "Sealed" SEC1 = 1 SEC0 = 1. And then you can translate immediately into SEC1 = 1 NUC0 = 0 (This according to Table 11-2 .Security Modes - full access?!). But with this, there are difficulties with the further re-recording of the software.
We are a bit confused.
I can send a video of how the record is made (with stops) and the state of the bits after the recording (because of errors they are different).
If possible, tell me how to correctly record, what time-outs. If possible, then a small piece of code (anat@monitor-ltd.ru) so that we understand what our mistake was and correctly recorded our initial settings and thresholds.

Best regards

  • Hi,

    Your thread's been assigned to me. Please expect a response within 5 business days.
  • Hi Anatoly,

    Unfortunately we don't reveal the process of writing firmware (fw) in gauging mode in that manner. There is a programming mode as you can see from bqstuio's firmware tab. For manufacturing we offer other formats for programming. Since the bq40z60 has no fw updates, you only need to update dataflash (df). For this please use the dffs export format and the linked pdf here, www.ti.com/.../slua801.pdf for the procedure on how to interpret the format to update your device.
  • Hi Batt
    We have already received this response from you in a related topic. You understood me wrong.
    We will program only flash data memory in the "0x4000-0x5FFF" area.
    Data for programming is obtained from the bqStudio.
    But we can not update the BC data received from the BQ40Z60 through our microcontroller.
    Especially it is not clear how to switch the states of bits SEC1 to SEC0 ... (Look at my questions above )
  • Hi Anatoly,

    The procedure for transitioning between the security modes (FULL ACCESS vs UNSEALED vs SEALED) should follow the description shown in section 10.5 in the TRM. I haven't gotten confirmation, but I think the table 11-2 may have an error, I believe it should be 2'b01=FULLACCESS, 2'b10=UNSEALED, 2'b11=SEALED. I don't have an EVM myself, so cannot verify, am trying to get confirmation from a colleague on that.

    Can you send more info on exactly what SMBus sequences you are sending to write the data flash?

    Thanks,

    Terry
  • Hi Terry

    SM Bus sequences to write flash:

    0x44 0x12 0x00 0x40 <16 data bytes>

    0x44 0x12 0x10 0x40 <16 data bytes>

    0x44 0x12 0x20 0x40 <16 data bytes>

    …..

    0x44 0x12 0xF0 0x5F <16 data bytes>

  • We do not understand..
    If we write a small change in the flash, then everything is fine. If we write from the factory settings to ours or vice versa, there is always a write error (no response from BQ40Z60).
    Is there a dependence on the volume of changes?
     
    We tried to translate into mode "Unseal" and write data flash (2'b10=UNSEALED) (We first translate in to "Seal". Then in "Unseal"). I managed to rewrite once. After that, the BQ40Z60 is constantly switched to "Seal". And after the second attempt to rewrite (there was also a write error), it was not possible to deduce "Seal" commands (either directly or through the bqStudio).
  • Hi Terry
    We created two file (*.srec)
    One - with factory settings (original flash - original config).
    The second one with our settings (new flash - new config).
    We replaced data flash in these files (0x4000-0x5FFF)
    Received 2 new files (original flash - new config and new flash - original config) and recorded them using the bqStudio.
    BQ40Z60 did not work with any of the new firmware *.srec.
    It turns out that only to update data flash is not enough.
    What should we do?
    How to write only a flash, but to keep working? Or how to write all the data from a *srec file?
    I can send our file or other data that you need.
    Best regards
    Waiting for your reply
  • Hi Anatoly,

    Flashing an srec can be done using the firmware tab. If you have a new srec with all the settings we recommend using the bqstudio firmware tab to program the gauge. Just copying the df section from one srec to another is probably not valid. It may result in checksum errors invalidating the whole write.
  • Hi

    I understand what you're talking about. We took this into account.

    Recording of altered srec through the bqStudio is normal. But the BQ does not work properly (even just no reaction to the inclusion of the charge).

    We tried to understand this experiment whether to update only the date flash (0x4000-0x5FFF) (as you wrote earlier in another forum).

    Because if we update the factory settings the date flash through our microcontroller, we get an error. If we record first through the studio and then make small changes, then they are written through our microcontroller normally.

    The question is the same as how do we update the data in the microcircuit through our microcontroller for mass production? In what there can be an error? What else should I record and how?
  • Hi

    Recommendations from you will not be? How to update data flash without using the studio?

    Why does the error occur? Why does BQ40Z60 stop responding when changing a lot of data?

  • I will have to research more into your error. I haven't seen this happen with bqstudio and outside of bqstudio we have some tools for mass production but I'm not sure if they apply here. I will find out within the next 2 weeks and reply back.
  • Hi Anatoly,

    If you want to unseal the gauge to set SEC1, SEC0 to 01 from a sealed state of 10, then your unseal command bytes need to be send back to back within 5 seconds. Following this, you should send the full access command bytes back to back without interruption. Once this is done, you can start recording data following the instructions you refer to.

    However, be advised that once you send a reset command (0x41), or if you POR, the device will revert back to sealed mode.
  • Thank you.
    It's clear. All that you said is described in the TRF.
    The problem is that if SET1 and SEC0 to 01 are set, then we can not write the data to the flash. I have described this many times. And it is this question that interests "What is our error and how do we record these flash data?"
    At the same time, it seems that somehow it turned out to update the data if the bits are in the state 10. But we can not record something again (we naturally send commands and see that the bits are set to the required levels). We do not know what can we do.
    Try to help us and answer
    1. Exactly there is no need to update the entire firmware (only 0x4000-0x5FFFF)? (BqStudio writes a lot more bytes and then everything works. I wrote about our experiments too. Maybe we need to write everything from the *srec file?)
    2. What is our error and how do we record thesedata flash?
  • Anatoly,

    I'm not sure what your sequence is but somewhere in there you are probably sending a seal command accidentally. This causes your gauge to seal and then you cannot write anything. If you want to flash something reliably if you are having issues writing individual parameters, given that you are in production, you can easily write the whole srec.
  • Thank you very much for the answer.
    We sent the seal command by specially trying different options.
    How to write a message without a studio? Also as described TRM "11.1.63 0x4000-0x5FFF Data Flash Access ()" only at all addresses?
    Can you send recommendations for our programmer to my personal mail, if there are features (we have already killed more than one chip trying deferent options))?
  • Anatoly,

    I'm sorry that we don't have documents that explicitly inform you on the ROM mode commands. However, I suggest that if you have access to the bus, please sniff the SMBUS lines when you initiate programming with bqstudio. The commands at the start are the fw update commands.
  • Thanks for the advice)
    But it seems to me that this is not even completely legal, albeit with your permission. In addition, we can get an unpredictable result.
    How is recording done through the bqStudio? I would like to receive official recommendations, like the one described as recording a flash.
    Best regards,
    Anatoly
  • Hi Anatoly,

    Sniffing an open bus isn't going to open you to problems. What I was suggesting was, have bqstudio plugged in. Then turn off the dashboard, then turn on your line sniffing. Choose the fw file and then observe the first few commands. The initial commands sent prior to the start of the srec are what are the fw update mode commands are.
  • Hi Batt,
    thanks you for the advice. I do not understand why to apply to go in this way, when you can immediately give the correct information. Just a few lines from you and a long series of experiments and corrupted chips will end.
    The question now comes down to where we started. How to write a srec file? How is this implemented in bqStudio?
  • Hi Anatoly,

    I'm really sorry. All I can do is apologize to you for being unable to give you the commands due to company policy. I have brought this issue to the attention of management here just to highlight why I think this policy should be changed.

    In the meanwhile though, the workaround I suggested should help you. Please scan the bus. The data that puts the gauge into programmable mode can clearly be seen before the srec write starts.
  • Hi Batt
    Now we are registering our product and we will begin mass production at the beginning of the second quarter of 2019. But me and the lead programmer are still very surprised. You propose to use BQ40Z60 for mass production, but do not offer options for recording it except through BQStudio. It is much easier to insert the SD-card, click on the button and set the desired settings.
    You give create srec file, but do not give information on how to write it.
    And we would not need to write it, but changing only the data Flash does not work (I written about).
    I think the wrong approach when you need to look for workarounds.
    Put the question to the management why you cannot provide information on how to write the srec file.
    I really do not understand why this causes so much difficulty. And we can not solve the issue of recording for mass production since July.
    Thank you very much for your participation in solving our problem.
    Best regards,
    Anatoly
  • Hi Anatoly,

    I have put this question exactly as you said to the management. They are looking into it. I hope we can get to a way to help you. I will keep you updated if the policy changes and I can give you the instructions.
  • OK
    Thanks
    I will wait
    Best regards
  • Please accept my friend request.