• State
  • Locked Locked
  • Replies 13 replies
  • Subscribers 64 subscribers
  • Views 379 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.

BQ40Z80: BMS field reject - no access to memory - eeprom erased?

Frank Boeh83
Intellectual 585 points
Part Number: BQ40Z80
Other Parts Discussed in Thread: EV2400, BQSTUDIO

Tool/software:

Hi there,

we are getting an increased number of BMS module field rejects. Circuit board is intact (populating a new BQ40Z80 chip results in needle bed test PASS). Soldering the chip from a failed board to a new board -> problem persists. Soldering the bad chip to the TI EVM module -> the part is not auto detected but the EVM can partially access the chip - all single-byte commands work except 0x00. Also ManufacturerBlockAccess fails. Current consumption is normal.

I have written code that runs all read commands and dumps their responses (all data is hex), from both a good chip (programmed as per our needle bed tester) and a bad chip.

I see lots of 0xFF in the responses from the bad chip. This makes me suspect that the configuration EEPROM has lost its data (or got bulk erased?).

In order to verify that the chip has not seen electrical damage otherwise, is there a way to factory-reset the memory? That way I could run it across the needle bed tester. In the state in which it is right now, it does not allow access. Or is it possible to UNSEAL it in this state?

The client has stopped battery assembly at this point, so I am in urgent need of hints towards a solution of this problem.

Regards Frank

dump from good chip:

cmd=00 n=02 res= 87 81
cmd=01 n=02 res= 2C 01
cmd=02 n=02 res= 0A 00
cmd=03 n=02 res= 81 60
cmd=04 n=02 res= 00 00
cmd=05 n=02 res= FF FF
cmd=06 n=02 res= FF FF
cmd=07 n=02 res= 01 00
cmd=08 n=02 res= 87 0B
cmd=09 n=02 res= DC 41
cmd=0A n=02 res= 00 00
cmd=0B n=02 res= 00 00
cmd=0C n=02 res= 64 00
cmd=0D n=02 res= 00 00
cmd=0E n=02 res= 00 00
cmd=0F n=02 res= 00 00
cmd=10 n=02 res= 7E 0E
cmd=11 n=02 res= FF FF
cmd=12 n=02 res= FF FF
cmd=13 n=02 res= FF FF
cmd=14 n=02 res= 00 00
cmd=15 n=02 res= 00 00
cmd=16 n=02 res= C7 02
cmd=17 n=02 res= 00 00
cmd=18 n=02 res= 30 11
cmd=19 n=02 res= 40 38
cmd=1A n=02 res= 31 00
cmd=1B n=02 res= 00 00
cmd=1C n=02 res= 01 00
cmd=20 n=12 res= 11 54 65 78 61 73 20 49 6E 73 74 72 75 6D 65 6E 74 73
cmd=21 n=08 res= 07 62 71 34 30 7A 38 30
cmd=22 n=05 res= 04 4C 49 4F 4E
cmd=23 n=21 res= 20 93 31 C5 65 00 00 00 00 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 7A 78 79 30 31 32 33 34 35
cmd=3C n=02 res= 00 00
cmd=3D n=02 res= 06 0B
cmd=3E n=02 res= FC 0A
cmd=3F n=02 res= FC 0A
cmd=46 n=02 res= 00 00
cmd=47 n=02 res= 00 00
cmd=48 n=02 res= 00 00
cmd=49 n=02 res= 00 00
cmd=4A n=02 res= 96 00
cmd=4B n=02 res= AF 00
cmd=4F n=02 res= 58 00
cmd=50 n=05 res= 04 00 00 00 00
cmd=51 n=05 res= 04 00 00 00 00
cmd=52 n=05 res= 04 00 00 00 00
cmd=53 n=05 res= 04 00 00 00 00
cmd=54 n=05 res= 04 87 81 00 04
cmd=55 n=04 res= 03 08 02 00
cmd=56 n=04 res= 03 D0 04 00
cmd=57 n=03 res= 02 10 00
cmd=58 n=16 res= 15 00 33 00 00 82 03 77 07 07 00 00 0C E0 00 00 30 70 FF 42 53 FF
cmd=59 n=02 res= 98 EF
cmd=5A n=02 res= 98 EF
cmd=5B n=02 res= 00 00
cmd=5C n=02 res= 00 00
cmd=5D n=02 res= 08 52
cmd=5E n=02 res= 30 F8
cmd=5F n=02 res= 30 F8
cmd=60 n=02 res= 00 00
cmd=61 n=1A res= 19 00 00 00 00 00 00 00 00 80 7F 00 80 7F 80 00 00 00 00 00 00 00 00 00 00 00
cmd=62 n=11 res= 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cmd=63 n=21 res= 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cmd=64 n=21 res= 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cmd=70 n=21 res= 20 93 31 C5 65 00 00 00 00 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 7A 78 79 30 31 32 33 34 35
cmd=71 n=21 res= 20 F8 0A EF 0A F6 0A FC 0A 48 43 0F 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cmd=72 n=11 res= 10 78 0B 87 0B A3 0B 00 00 00 00 87 0B 78 0B 87 0B
cmd=73 n=21 res= 20 99 FE 0E FD 7E 0E 42 20 7E 0E 42 20 87 0B 86 0B E8 03 E8 03 E8 03 E8 03 00 00 00 00 00 00 00 00
cmd=74 n=21 res= 20 00 00 00 00 00 00 02 00 00 00 00 40 00 40 00 40 00 40 00 00 00 00 00 00 D0 04 D0 04 D0 04 D0 04
cmd=75 n=21 res= 20 30 11 30 11 30 11 30 11 00 00 00 00 00 00 00 00 00 00 00 00 64 00 E8 03 00 40 00 40 00 40 00 40
cmd=76 n=1F res= 1E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cmd=77 n=05 res= 04 0E 0F 2E 22
cmd=78 n=09 res= 08 99 FE 0E FD 7E 0E 42 20
cmd=7A n=21 res= 20 01 23 45 67 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 7A 78 79 30 31 32 33 34 35
cmd=7B n=13 res= 12 FC 0A 00 00 00 00 06 0B 00 00 00 00 00 00 00 00 00 00
cmd=7C n=1F res= 1E E8 03 00 00 00 40 D0 04 30 11 00 00 00 40 00 E8 03 00 00 00 40 D0 04 30 11 00 00 00 40 00
cmd=7D n=10 res= 0F 00 00 00 00 00 00 00 00 30 11 00 00 00 00 00
cmd=80 n=21 res= 20 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 7A 78 79 30 31 32 33 34 35
cmd=81 n=21 res= 20 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 7A 78 79 30 31 32 33 34 35
cmd=82 n=05 res= 04 00 00 00 00

dump from bad chip:

cmd=00 n=02 res= 01 61
cmd=01 n=02 res= FF FF
cmd=02 n=02 res= FF FF
cmd=03 n=02 res= FF FF
cmd=04 n=02 res= 00 00
cmd=05 n=02 res= 00 00
cmd=06 n=02 res= 00 00
cmd=07 n=02 res= 00 00
cmd=08 n=02 res= 72 0B
cmd=09 n=02 res= FF FF
cmd=0A n=02 res= 00 00
cmd=0B n=02 res= 00 00
cmd=0C n=02 res= FF 00
cmd=0D n=02 res= 00 00
cmd=0E n=02 res= 00 00
cmd=0F n=02 res= 00 00
cmd=10 n=02 res= FF FF
cmd=11 n=02 res= 00 00
cmd=12 n=02 res= 00 00
cmd=13 n=02 res= 00 00
cmd=14 n=02 res= 00 00
cmd=15 n=02 res= 00 00
cmd=16 n=02 res= 47 00
cmd=17 n=02 res= FF FF
cmd=18 n=02 res= FF FF
cmd=19 n=02 res= FF FF
cmd=1A n=02 res= FF FF
cmd=1B n=02 res= FF FF
cmd=1C n=02 res= FF FF
cmd=20 n=16 res= FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
cmd=21 n=16 res= FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
cmd=22 n=06 res= FF FF FF FF FF FF
cmd=23 n=21 res= 40 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
cmd=3C n=02 res= 00 00
cmd=3D n=02 res= 00 00
cmd=3E n=02 res= 00 00
cmd=3F n=02 res= 00 00
cmd=46 n=02 res= 00 00
cmd=47 n=02 res= 00 00
cmd=48 n=02 res= 00 00
cmd=49 n=02 res= 00 00
cmd=4A n=02 res= FF FF
cmd=4B n=02 res= FF FF
cmd=4F n=02 res= 00 00
cmd=50 n=05 res= 04 00 00 00 00
cmd=51 n=05 res= 04 00 00 00 00
cmd=52 n=05 res= 04 FF FF FF FF
cmd=53 n=05 res= 04 FF FF FF FF
cmd=54 n=05 res= 04 01 61 40 01
cmd=55 n=04 res= 03 00 00 00
cmd=56 n=04 res= 03 00 00 00
cmd=57 n=03 res= 02 F8 03
cmd=58 n=16 res= 15 00 30 00 00 02 C0 77 07 03 80 00 09 E0 00 00 30 FF FF FF FF FF
cmd=59 n=02 res= 00 00
cmd=5A n=02 res= 00 00
cmd=5B n=02 res= FF FF
cmd=5C n=02 res= FF FF
cmd=5D n=02 res= FF FF
cmd=5E n=02 res= 00 00
cmd=5F n=02 res= 00 00
cmd=60 n=02 res= FF FF
cmd=61 n=1A res= 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cmd=62 n=11 res= 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cmd=63 n=21 res= 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cmd=64 n=21 res= 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cmd=70 n=21 res= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cmd=71 n=21 res= 20 00 00 00 00 00 00 00 00 E2 75 C6 64 80 FF 80 FF 80 FF 80 FF 00 00 00 00 00 00 00 00 02 00 00 00
cmd=72 n=11 res= 10 FE FF FB FF FB FF 00 00 00 00 72 0B FE FF 00 00
cmd=73 n=21 res= 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cmd=74 n=21 res= 20 00 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cmd=75 n=21 res= 20 FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cmd=76 n=1F res= 1E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cmd=77 n=05 res= 04 00 00 00 00
cmd=78 n=09 res= 08 00 00 00 00 00 00 00 00
cmd=7A n=21 res= 40 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
cmd=7B n=13 res= 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cmd=7C n=1F res= 1E 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00
cmd=7D n=10 res= 0F 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00
cmd=80 n=21 res= 40 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
cmd=81 n=21 res= 40 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
cmd=82 n=05 res= 04 00 00 00 00

  • 0
    TI__Mastermind 37761 points

    Hello,

    We are currently looking into this, we will get back with you soon.

    Regards,

    Nick

  • 0 in reply to Frank Boeh83
    TI__Mastermind 28470 points

    Hi Frank,

    Is the current communication being done using an MCU host? If so, have bqStudio and EV2400 been tried to communicate?

    If possible, can you please use a scope to observe the behavior of the TS1 pin of the device? If there is a pulsing of 1s intervals, the device is currently in normal mode. For reference, sleep mode will change this pulsing to 4s.

    The constant FFs in the read out could potentially be from a corrupted data flash. If you are able to receive the .srec from one of the bad devices, can you please share it?

    Regards,

    Anthony

  • 0 in reply to Anthony
    Intellectual 585 points

    the communication is done using an own solution that includes an onboard I2C adapter (STLINK-V3MODS). Communicating with the BMS chip is done from a desktop PC that talks through this adapter, using a Visual C++ application. I can disclose the code of that if it helps.

    TS1 pulses with about 2Hz:

    Bqstudio / EV2400 is partly able to communicate - no audio detection of device type. When I select manually, then it shows a partially populated screen. The ManufacturerBlockAccess commands don't get responded. ManufacturerAccess also the other 8-bit commands get responded. That's why I did what I did - I noticed this and then implemented read functions for each and every one of them. Bqstudio just uses a few of them and mostly relies on ManufacturerBlockAccess. For the same reason I cannot read a .srec file. What I posted above is all that I can get from the device.

    What I need help with is - what can cause the memory to be erased in the field (the I2C lines are unconnected then)? What can be done to mitigate this? For example - we do not SEAL the devices. Will doing that enable some kind of data integrity checking, for example.

  • 0 in reply to Frank Boeh83
    TI__Mastermind 28470 points

    Hi Frank,

    Frank Boeh83 said:
    Bqstudio / EV2400 is partly able to communicate - no audio detection of device type. When I select manually, then it shows a partially populated screen. The ManufacturerBlockAccess commands don't get responded. ManufacturerAccess also the other 8-bit commands get responded. That's why I did what I did - I noticed this and then implemented read functions for each and every one of them. Bqstudio just uses a few of them and mostly relies on ManufacturerBlockAccess. For the same reason I cannot read a .srec file. What I posted above is all that I can get from the device.

    Just to confirm the setup when bqStudio is being used, when a new IC is soldered to the board is bqStudio able to recognize the device and communicate correctly with it?

    Frank Boeh83 said:
    What I need help with is - what can cause the memory to be erased in the field (the I2C lines are unconnected then)? What can be done to mitigate this?

    If the gauge is unsealed during application, this would allow for the data flash memory to be altered, which could be leading to the issue being seen. Can you please go more into depth about why the gauge is being left unsealed?

    Regards,

    Anthony

  • 0 in reply to Anthony
    Intellectual 585 points

    Yes, BqStudio works well with the original chip that was on it before the swap, and it now works well again.

    What I observe makes sense, when we assume that the entire config memory got overwritten with 0xFF (as the data dumps suggests - for example all strings that are fetched from that are all 0xFF). This means that the SEAL bits would be all one, and also the UNSEAL and FULL_ACCESS keys are all 0xFFFF. In that state, the device cannot even tell between UNSEAL and FULL_ACCESS, so no wonder why I cannot get access. Does that make sense?

    The question for me is, what can cause this?

    Yes, not sealing the device allows to alter the flash memory, but what mechanism can you think of? The BMS is inside the battery enclosure, and it is not reasonable to assume that a customer is doing this actively.

    Is it possible that the device 'sees' a command via I2C that causes this, for example through EMI?

    The gauge was left unsealed because we did not see a need for this, and that way we can easier diagnose field returns.

    We can of course add a SEAL command at the end of the test sequence, but I would want to first understand that this will likely solve this issue. At the moment I cannot spot the causal link.

  • 0 in reply to Frank Boeh83
    TI__Mastermind 28470 points

    Hi Frank,

    If the gauge is in an unsealed state, then I believe it is possible to change the seal keys, which would make sense for the situation above.

    In the application, are the communication lines for the bq40z80 shared with any other devices other than the MCU? Based on what was discussed earlier, I do not believe the programming file is corrupted since it is able to work for the other devices.

    Regards,

    Anthony

  • 0 in reply to Anthony
    Intellectual 585 points

    no, in the application the communication lines are completely unconnected, nothing connected to them also no pull-ups. We just have test pads and maybe 12mm of traces. Can this also be a problem? Is it ok to leave them floating?

    The programming works generally, also with the bad chips, as all of the modules will see a final QA check after having assembled the battery packs, and all of them were PASS. The bad chips definitely fail in the field through customer usage.

    The programming is done through custom code, is it possible that we do not adhere to the timing requirements when writing the data? We do make a 100ms pause after each call to ManufacturerBlockAccess (32 bytes of data). We reset the device multiple times in the process. Anything else that we need to consider (except sealing) that can improve the reliability?

  • 0 in reply to Frank Boeh83
    TI__Mastermind 28470 points

    Hi Frank,

    Frank Boeh83 said:
    no, in the application the communication lines are completely unconnected, nothing connected to them also no pull-ups. We just have test pads and maybe 12mm of traces. Can this also be a problem? Is it ok to leave them floating?

    So in application, there is no communication occurring with the device and a host?

    Frank Boeh83 said:
    The programming is done through custom code, is it possible that we do not adhere to the timing requirements when writing the data? We do make a 100ms pause after each call to ManufacturerBlockAccess (32 bytes of data). We reset the device multiple times in the process. Anything else that we need to consider (except sealing) that can improve the reliability?

    As long as the timing requirements for the SMBus specs are being met, I believe the programming should be fine. Is there any ESD preventative components attached to the communication lines of the device since they are left unconnected?

    Regards,

    Anthony 

  • 0 in reply to Anthony
    Intellectual 585 points
    Anthony said:
    So in application, there is no communication occurring with the device and a host?

    no! Nothing connected at all at the I2C lines.

    Anthony said:
    As long as the timing requirements for the SMBus specs are being met, I believe the programming should be fine. Is there any ESD preventative components attached to the communication lines of the device since they are left unconnected?

    No.The device datasheet states 2kV HBM for each pin and we have done extensive ESD testing on the solution, with 0 failures.

  • 0 in reply to Frank Boeh83
    TI__Mastermind 28470 points

    Hi Frank,

    Understood, thank you for the clarification.

    When trying to unseal the device, has it been tried with the 0xFFFF keys to try and see if this was the value it was changed to along side meeting the 4s timing between sending each command?

    Regards,

    Anthony

  • 0 in reply to Anthony
    Intellectual 585 points

    Hi Anthony,

    I had tried that, but am not sure about the timing that you mention. Can you please write down the sequence of commands and their timing, that I should try?

    Regards Frank

  • 0 in reply to Frank Boeh83
    TI__Mastermind 28470 points

    Hi Frank,

    I believe the description from the TRM below does a good job detailing this. I wanted to confirm that each word of the key for unseal and full access unseal are being sent within the 4s window of each other.

    Regards,

    Anthony