• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 63 subscribers
  • Views 350 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.

BQ35100: Locked in ROM mode

Paolo Giazzi
Prodigy 20 points
Part Number: BQ35100
Other Parts Discussed in Thread: EV2400, BQSTUDIO

Tool/software:

I have adopted this part for a project and I'm working on a custom board. After reading a lot of documentation and spending some time on TI forums I'm now facing the customization trying to transfer the golden image to the BQ35100 on the custom board.

I've been working with the BQ35100 evaluation module (connected to the PC thru the EV2400) and BQ Studio. I exported the golden image after setting up the EVM and ran into some issues. I found out late some posts on the forums about similar issues but unfortunately none helped me to solve my issues.

1. I'm referring to "SLUA801 Gauge Communication" to transfer the golden image to the BQ35100. I found out issues coming from the fact that the generated golden image has long data transfers while BQ Studio splits them in shorter transfers. Posts in the forum showed this issue, but I couldn't find a way to generate the golden image with shortes data trasfers. How can this be done? Function gauge_execute_fs() in SLUA801 assumes 32 bytes maximum, while the generated golden image has over 100 bytes.

2. Not knowing about the above limitation I ended up with the BQ35100 stuck in ROM mode (the infamous undocumented 0x16 I2C address...). I tried different ways to get out of it. I tried the suggested sequence ("Execute Flash Code") below, but with no luck, the IC goes on replying to 0x16 address:

W: 16 00 0F
W: 16 64 0F 00

The BQ35100 on the custom board can't be connected to the EV2400, so I can't use it to reflash the IC (unless we solder some wires on the board, something that I'm considering...). How can have the BQ35100 going back to regular mode? Any reset command from ROM mode?

3. How to avoid this in production? We can't use the EV2400 on the custom board.

Thank you for your help.

  • 0
    TI__Mastermind 26015 points

    Hi,

    1) I suggest using BQstudio to generate the golden image in the golden image tab, then flashing this image via i2c on to the device.

    2) (+) BQ34Z100-G1: How to exit ROM mode - Power management forum - Power management - TI E2E support forums

    3) I would verify that your flashing process is correct before going to production.

    Regards,

    Evan

  • 0 in reply to Diego
    Prodigy 20 points

    Hi Evan, thank you for your reply.

    1. As I wrote in my post: I exported the golden image after setting up the EVM. I did as suggested, but because of the transfer size limitation I don't know how the generate a golden image with transfers shorter than 32 bytes.

    2. As I wrote in my post: The BQ35100 on the custom board can't be connected to the EV2400. So I can't use the method suggested (SMBus). Is there any way to exit from ROM mode sending commands to I2C without using BQStudio?

    3. Done that. Problem is that this was done after I found out the issues coming for example by sending more than 32 bytes (not pointed out in  "SLUA801 Gauge Communication") so I have some IC's stuck in ROM mode.

    Regards,

    Paolo

  • 0 in reply to Paolo Giazzi
    TI__Mastermind 26015 points

    Hi,

    1) This is not possible.

    2) The same process can be followed with an external MCU, rather than BQstudio and the EV2400.

    Regards,

    Evan

  • 0 in reply to Diego
    Prodigy 20 points

    Thank you, Evan.

    I'm checking if we're able to send the 0x08 command on I2C simulating the SMBus, then.

    Regards,

    Paolo

  • 0
    Prodigy 20 points

    To the advantage to who has the same issue, this is the pseudo-code that worked for me.

    // Check if BQ35100 is in ROM mode
    i2c_read(address 0x16, register 0x00, 1 byte)

    if (no reply) {
      // Simulate SMBus command 0x08
      i2c_write(address 0x16, register 0x08, 0x11)

      // Execute flash code
      i2c_write(address 0x16, register 0x00, 0x0f)
      i2c_write(address 0x16, register 0x64, 0x0f 0x00)

      delay(4000 ms)
    }

    // Communicate with address 0xaa from now on
    ...

    I hope this will help.

    EDIT - A delay of few millisecons might be necessary between I2C writes.