• State Resolved
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 63 subscribers
  • Views 96 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

BQ28Z620: Relax_smooth_ok function is disappeared

Kailun Liu
Intellectual 1396 points
Part Number: BQ28Z620
Other Parts Discussed in Thread: BQ27Z561,

Tool/software:

Hi Team,

In BQ27Z561, gauge support [RELAX_JUMP_OK] and [RELAX_SMOOTH_OK] to support RSOC change in relax mode smoothly or jump.

However,

I found in BQ28Z620, [RELAX_SMOOTH_OK] is disappear in TRM.

At the meantime, Smooth relax time still exit in TRM.

Could you share what is the status of this function? Thanks! 

  • 0
    TI__Genius 17181 points

    Hello Kailun,

    These 2 gauges have two different firmware and their own designs. As of right now, there is not any word of adding [RELAX_SMOOTH_OK] to the BQ28z620.

    Regards,

    Nick Richards

  • 0 in reply to Nick Richards
    TI__Intellectual 1396 points

    Thanks Nick,

    So there is no Relax_smooth function in BQ28Z620, and currently the register bit of Smooth relax time in TRM is invalid? What is the consideration?

    Another question,

    If [RELAX_JUMP_OK]=0, [SYNC_AT_OCV]=1, will RSOC jump while OCV taken?

  • 0 in reply to Kailun Liu
    TI__Genius 17181 points

    Hello Kailun,

    After checking the firmware code, Smooth relax time parameter is still being used within the code, which makes me believe that the RELAX_SMOOTH_OK feature is enabled by default by the gauge without the option for the user to disable it. 

    Kailun Liu said:
    If [RELAX_JUMP_OK]=0, [SYNC_AT_OCV]=1, will RSOC jump while OCV taken?

    This should not allow RSOC to jump when the OCV is taken.

    Regards,

    Nick Richards

  • 0 in reply to Nick Richards
    TI__Intellectual 1396 points

    Thanks Nick,

    Could you double check the Relax_smooth_ok function? Since our customer test to find if they set relax_jum_ok=0, the RSOC would not change anymore, which is conflict with your saying. 

  • 0 in reply to Kailun Liu
    TI__Genius 17181 points

    Hello,

    Today's a national holiday. We will get back to you tomorrow.

    Regards,

    TI Apps Team

  • 0 in reply to Nick Richards
    TI__Genius 17181 points

    Hey Kailun,

    I am confused how that conflicts what I said. If Relax_smooth_ok is enabled, then RSOC will not jump. Also, if then relax_jum_ok=0 then RSOC will not jump and hold constant during relax. 

    Kailun Liu said:
    the RSOC would not change anymore,

    Can you clarify what you mean by this. When you say "would not change" I read into that as "would not jump", but those settings prevent jumps. Providing a log file so I can quantitatively see what is happening will also be helpful.

    Regards,

    Nick Richards

  • 0 in reply to Nick Richards
    TI__Intellectual 1396 points

    Hi Nick, 

    Relax_jump_ok=1 → Allow RSOC jump during relax.

    Relax_smooth_ok=1→Allow RSOC smoothly change during relax.

    Is my understanding correct？

    If the relax_smooth_ok is enabled by default. RSOC should be allowed to change during relax.

    However, customer finding that once the relax_jump_ok=0, the RSOC is locked during relax.

  • 0 in reply to Kailun Liu
    TI__Genius 17181 points

    Hello Kailun,

    Your understanding is correct. 

    The relax_jump_ok feature takes priority over the Relax_smooth_ok feature for this gauge, so I would expect if relax_jump_ok = 0, then RSOC should be locked. The relax_smooth_ok is enabled by default but does not take priority over relax_jump_ok feature.

    Regards,

    Nick Richards

  • 0 in reply to Nick Richards
    TI__Intellectual 1396 points

    Thanks Nick! 

    If the relax_jump_ok feature takes priority over the Relax_smooth_ok, I think we could remove Relax_smooth_ok from the FW directly.

    Relax_jump_ok=1, RSOC allowed to jump.

    Relax_jump_ok=0, RSOC locked.

    There would be not condition that Relax_smooth_ok could take effect.

  • +1 in reply to Kailun Liu
    TI__Genius 17181 points

    Hello Kailun,

    Thank you for the input, I will relay this to the firmware team.

    Regards,

    Nick Richards