• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 2 answers
  • Subscribers 64 subscribers
  • Views 1445 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

BQ34Z651: Undocumented Data Flash Elements

David Wright33
Intellectual 805 points
Part Number: BQ34Z651

Hi There,

I am writing my own script to update the data flash on my BQ34Z651 devices and I have noticed that there are many regions of the data flash that are undocumented. 

So far I have discovered the following:

SubClass ID Offset range Description
unknown unknown Heater Control
36 4-5 unknown
59 24-25 unknown
59 32-39 Lifetime OT/OV information
60 4-6 Unknown
64 12-13 Unknown
65 0 Unknown
80 2-59 Unknown
80 62-76 Unknown
80 85-87 Unknown
80 90 Unknown
80 91-92 Is meant to be 'Sim Temperature Delta' but it is not there

I currently haven't looked past Subclass 80, but given my findings thus far I image in that there will be more issues there too.

These undocumented regions (where their location is known)  are certainly full of Data when I read from the data flash. I just have no idea what that data is or if it is safe to erase it.

Can anyone help me out?

Thanks,

David

  • 0
    TI__Genius 10830 points
    hi David,
    Most of our battery experts are out of the office today. We will look at your question on Monday.
  • 0 in reply to David Hien
    Intellectual 805 points
    Hi There,

    I was just wondering if someone has had a chance to look over this yet?

    Cheers,

    David
  • 0 in reply to David Wright33
    TI__Genius 14985 points
    Hi David,
    There are large segments of dataflash which are important, but are hidden/private because they are static and proprietary. You should not erase them, but they should be programmed as part of your golden flash image.
  • 0 in reply to dMax
    Intellectual 805 points

    Hi There,

    That is to be expected, and I can certainly do that.

    However the Heater Control and lifetime elements that I called out in my original question are defined as things I can edit/read (and I can through the bq evaluation software) but are not defined enough for me to actually be able to use them. Is it possible for you to refine those elements for me?

    Additionally, given that these things are missing from the data flash documentation I worry that some of the other missing elements may not be reserved/proprietary, and may in-fact be useful/important. Can you confirm that all of the sectors that I mentioned above are actually reserved/proprietary?

    Thanks,

    David

  • 0 in reply to David Wright33
    TI__Genius 14985 points
    Hi David,
    The subclass of the Heater Control is 39, whereas I can see in the TRM addendum it is marked as TBD.
    The reserved/proprietary items are important and you should write to them if you are trying to program the gauge. Many will be left at default, but some might be customized. You can program the default .senc and read the values, then compare with your golden .senc values, and only write to the ones which are different.
    Which other parameters are you missing information on?
  • 0 in reply to dMax
    Intellectual 805 points

    Hi There,

    Thanks for the heater control information!

    I am also wondering specifically about 'Life OT duration', 'Life OV Count' and 'Lifet OV Duration'. They are present in the Evaluation software but not in the documentation. Can you point me to a reference that covers their offsets, types and lengths?

    Additionally, given that the chemistry information is not contained within the documented sub-classes that if I only program the documented sub-classes I will be missing additional information that would be contained in a .ROM file. Is this correct?

    If so, can you provide me with a range of sub-classes that I should be reading from device A to program to device B in order to capture all of the information?

    Thanks,

    David

  • 0 in reply to David Wright33
    TI__Genius 14985 points
    These are in subclass 59 (Lifetime Data) and might help you:
    Lifetime Over Temperature Event Count, 30, Life OT Count, U2
    Lifetime Over Temperature Event Duration, 32, Life OT Duration, U2
    Lifetime Over Temperature Event Active, 34, Life OT Active, U1
    Lifetime Over Voltage Event Count, 35, Life OV Count, U2
    Lifetime Over Voltage Event Duration, 37, Life OV Duration, U2
    Lifetime Over Voltage Event Active, 39, Life OV Active, U1,
    You could also modify them in EVSW, then read out the raw data and see what changed to confirm the locations.

    To find out the other subclasses you need, program a chemID using EVSW and read out the raw data to see which subclasses changed.
  • 0 in reply to dMax
    Intellectual 805 points

    Hi There,

    That is great information, thanks!

    Reading out the full flash was basically what I was planning to do. Can you tell me what the maximum subclass ID is, the ID is a 16bit number so it would talk a very long time to read all possible numbers!

    Thanks,

    David

  • 0 in reply to David Wright33
    Intellectual 805 points

    HI Again,

    I have also just noticed that the values for CC gain and CC offset stored in the data flash do not match what I am expecting.

    CC Gain is listed as 5.334 in the evaluation software. Firstly, this is outside the 0.1-4.0 range of values listed in the TRM, and secondly, The value I read from the data flash is 0x81619BD4. Which I don't seem to be able to decode to a number even remotely resembling 5.334, or a number in the 0.1-4.0 range.

    CC Delta is also listed as 5.334 in the evaluation software. This is also outside the 29,826 to 1,193,046 range listed in the TRM, and I also cannot decode the flash value 0x940058A7 (not the same as above despite what the evaluation software says) to a number resembling 5.334 or any number in the specified range.

    These are the only two numbers that are defined as floats, so I am guessing there is some non-standard float conversion going on here. And that the Evaluation software does not actually reflect the data flash values...

    Can you give me any guidance on this?

    Thanks,

    David

  • 0 in reply to David Wright33
    TI__Genius 14985 points
    Hi David,

    CC Gain and CC Delta are F4 type, which is not IEEE. Search for F4 in SLUUAX0C and also refer to section A.11 for an example of converting to F4.

    I believe this is a list of all subclasses. Some are more than one block (32 bytes).
    0
    1
    2
    4
    16
    17
    18
    19
    20
    21
    32
    33
    34 two blocks
    36
    37
    38
    39
    48 three blocks
    49
    56
    57
    58
    59 two blocks
    60
    64
    65
    66
    67
    68
    80 three blocks but probably only the first one changes
    81
    82 two blocks but probably only the first one changes
    83 three blocks
    84 three blocks
    85
    86
    88
    89
    90
    91
    92
    93
    94
    95
    96 two blocks
    97
    104
    105
    106
    107
    112
  • 0 in reply to dMax
    Intellectual 805 points

    Hi There,

    Thank you for both those pieces of information.

    The algorithm presented will infinite loop through the second "tmpVal < 0.5" loop if the value to be converted is equal to zero. Is there a specific way in which zero should be encoded?

    Are you able to provide me with an example of a correctly encoded floating point number so I can check the encoding code that I have written?

    Thanks,

    David

  • 0 in reply to David Wright33
    TI__Genius 14985 points
    The entire app note doesn't apply to this gauge, but the floating point conversion example on page 12 of this doc might help:
    www.ti.com/.../slua640b.pdf

    I also found this info:
    The double is not IEEE compliant; it is in big endian order, with the exponent first.  The next 3 bytes are the mantissa with an implied first bit of 1, thus squeezing out one extra bit in the precision of the number.  However, note the MSB of the first byte of the mantissa is the sign bit.
     
    Here’s the ‘C’ code to take the 4 bytes and convert from the gauge's big endian to a double on a typical Intel based machine (little endian).
     
                uchar p[] = { 82, 20, 21, 22};       // hypothetical bytes with the starting float
    int s, e;
                double x;
                union int_byte {
                            UINT i;
                            UCHAR c[4];
                } d;
     
                e=*p++;                        // exponent
                s=(*p)&0x80;                 // sign of number
                d.c[3]=0;                       // because mantissa only has 3 bytes
                d.c[2]=(*p++)|0x80;        // flip the endianess
                d.c[1]=(*p++);
                d.c[0]=(*p++);
     
                x=d.i * pow(2,e-128-24);  // 128 because of implied sign of exponent and the 24 because of the implied 1 as the high bit in the mantissa
                if (s)
                            x=-x;                 // has the correctly signed value as a double in Intel (IEEE) format

    Here are some example pairs:
    Hex            Float
    00000000 1.46936793853e-39
    81800000 -1.0
    81000000 1.0
    8b1a522b 1234.56774902
    8e88f5ba -8765.43164062
    94452578 807511.5
    7f5e9624 0.434739232063
    977b2169 8229044.5
    7d063fa8 0.0655511021614
    9b2b2e2a 89747792.0
    7f3efd94 0.37302839756
    962f2f49 2870226.25
    9b2f7784 91995168.0
    906c32dc 60466.859375
    963b28db 3066422.75
    7e703f1e 0.234615772963
    873a005e 93.0007171631
    841683fb 9.40722179413
    8225884f 2.58644461632
    8b22d71e 1302.72241211
    93270dbd 342125.90625
    9c158969 156800656.0
    8847c72f 199.778060913
    893d0bbf 378.091766357
    9c72e870 254707456.0
  • 0 in reply to dMax
    Intellectual 805 points
    Hi There,

    Thanks for that, My code works!

    Did you have a chance to look into the representation of zero so as to avoid the infinite loop?

    Thanks,

    David
  • 0 in reply to David Wright33
    TI__Genius 14985 points
    Hi David,
    I don't think zero is ever a valid value for the floating point calibration values, but you could perhaps add an exception to make it slightly non-zero.
  • 0 in reply to dMax
    Intellectual 805 points

    Thanks for all your help, I think that is everything!