Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State TI Thinks Resolved
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 121 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

BQ27Z561-R2: BQ27Z561-R2 FW Change of Production Line

RYOSUKE ARAKI
Prodigy 90 points
Part Number: BQ27Z561-R2
Other Parts Discussed in Thread: BQSTUDIO

Tool/software:

We want to change the firmware in ROM mode for BQ27Z561-R2. (R1=>R2)
Is there a TRM for ROM mode?

The TRM (SLUUC54C) for BQ27Z561-R2 only has this image and text.

A. I am looking for special information on communicating in ROM mode via I2C without using BQSTUDIO.

B. I failed to send a command in ROM mode. Since then, it has not returned to FW mode. Is there any way to fix this?

C. The clock operating frequency of the BQ27Z561-R2 TRM (SLUSE22B) is set to MAX 100 in "7.18 I2C Timing-100kHz", but is there any information on the minimum value (test results or track record)?

Thank you.

  • 0
    TI__Mastermind 27976 points

    Hello Ryosuke,

    Let me send you some resources to reference.

    First, let me send you the gauge communication document that should explain how to program FW files onto the gauge without BQStudio: https://www.ti.com/lit/an/slua801/slua801.pdf

    Second, let me send you this e2e post about exiting from ROM mode: https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1288151/bq34z100-g1-how-to-exit-rom-mode

    C. You can reference the I2C standard for minimum values.

    Regards,

    Adrian

  • 0 in reply to Adrian
    Prodigy 90 points

    Hello Adrian,


    There's not enough information in "slua801.pdf". That's why I think there are many similar threads on E2E.
    As for A, I'll put it on hold for now.

    Regarding B, I have figured out the problem, so I would like to know if there is a solution.


    Line 19 of the attached file. "W: 16 05 12 00 00 ....."
    When 12 was sent, the cross stretch caused a bit of misalignment, resulting in an abnormal transmission and a write error.
    It has remained in that state. Our CPU not supports cross stretch.
    B-1 Are there any other solutions aside from the Link we discussed the other day?
    B-2 What is an effective method if cross stretch is not supported?
    B-3 I think it may be related to the above solution, but "FLASH_BUSY_WAIT in I2C Configuration." I would like an explanation for this.(SLUU45C P.65)


    Best Regards

  • 0 in reply to RYOSUKE ARAKI
    TI__Mastermind 27976 points

    Hello Ryosuke,

    Are you able to send a digital logic capture of this communication failure? I am trying to understand if the device was successfully sent to ROM mode to begin with.

    The MCU you are using should be able to support clock stretching.

    I believe that FLASH_BUSY_WAIT bit is only applicable in FW mode, but essentially this bit allows the gauge to clock stretch.

    Regards,

    Adrian

  • 0 in reply to Adrian
    Prodigy 90 points

    Hello Adrian,

    It's a shame that clock stretching is only available in FW mode.
    I'm not sure if I can prepare an image of the logic analyzer.

    However, it is in ROM mode.
    If you ask me if it's working properly, I don't know.

    When I access it with BQSTUDIO, it isn't recognized.
    This is correct if it is in ROM mode.
    When I send "16 08 11" with "AdvanceComm" in that state, I get a response,
    so it's clear that a FuelGauge in ROM mode is connected.

    Best Regards

  • 0 in reply to RYOSUKE ARAKI
    TI__Mastermind 27976 points

    Hello Ryosuke,

    Yes, if this gauge is responding to address 0x16 then it should be in ROM mode. Seeing what's happening with a logic analyzer will help me root cause the issue.

    Regards,

    Adrian

  • 0 in reply to Adrian
    Prodigy 90 points

    Hello Adrian,

    The correct format was 0B(w),05(w),12(w),00(w).
    One bit was corrupted along the way, so it became 0B(w),05(w),12(w),00(r).
    Clock stretching?
    As a result, the software determined that there was an abnormality and stopped writing the program halfway through.


    First, I would like to know how to recover from this state.

    I've looked at various threads but I can't find a solution.
    After rebooting, there is a response of 16(0B).


    Next, how to avoid this problem.

    Best Regards

  • 0 in reply to RYOSUKE ARAKI
    TI__Mastermind 27976 points

    Hello Ryosuke,

    This could have all stemmed from a timing issue. I would recommend using BQStudio and sniffing the comm lines and then compare it to your host MCU to see if the timing is the same.

    Regards,

    Adrian

  • 0 in reply to Adrian
    Prodigy 90 points

    Hello Adrian,

    This doesn't happen with BQSTUDIO & EVM2400.

    First, I'd like to know how to recover from this state.

    Is it a problem to use ROM mode on an MCU that does not support clock stretching?

    I don't know much about programming, but is it possible to fix this by modifying the programming program?

    The program seems to have been based on "SLUA801".

    Best Regards

  • 0 in reply to RYOSUKE ARAKI
    TI__Mastermind 27976 points

    Hello Ryosuke,

    Yes, we always recommend using an MCU that has the ability to clock stretch when using our gauges, no matter whether the gauge is in FW or ROM mode. This is a setting or functionality of the MCU so you will need to refer to that. 

    Regards,

    Adrian

  • 0 in reply to Adrian
    Prodigy 90 points

    Hello Adrian,

    "We always recommend using an MCU that has the ability to clock stretch when using our gauges, no matter whether the gauge is in FW or ROM mode."

    That's something that we, as a manufacturer, need to strongly educate our customers about. That's what I think.

    And we also need to establish a reliable method of recovery from ROM mode.

    This is a problem that goes beyond the level that E2E engineers can handle.

    So it's wrong to ask engineers to do it.

    I came to the conclusion that anything that doesn't recover from ROM mode should be discarded.

    Best Regards