• State TI Thinks Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 4 answers
  • Subscribers 64 subscribers
  • Views 965 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.

Original question:

BQ35100: Access the unsealed mode

BQ35100: Access the unsealed mode

Fulvio Troiani
Prodigy 70 points
Part Number: BQ35100
Other Parts Discussed in Thread: BQSTUDIO

Hello,

I am experiencing the very same problem:

I power the BQ35100 and read the Control Status, I get 0x2080.
Initialisation in complete so I send 00.14.04, and after 20 ms I send 00.72.36.
After 20 ms more, I ask for the Control Status and get 0x2080, again.

I2C bus clock frequency is 100 kHz.

I checked the communication with the scope and I saw nothing abnormal. Ack, Start, Restart and Stop are where they are expected to be.

What am I missing?

Thank you very much,

Fulvio

  • 0
    TI__Genius 10370 points

    Fulvio,

    The 0x0414 and 0x3672 need to be complete independent writes. If you are not issues a stop signal it will not work. 

    I suggest using bqStudio and clicking the 'unseal" button on the right and scope capture it to compare against what your system is sending. 

    Thanks,

    Eric Vos

  • 0 in reply to Vos
    Prodigy 70 points

    Thanks Eric,

    yes, the STOP markers are there.

    Precisely, what I am sending is:

    Master: START, 0xAA
    BQ35100: ACK
    Master: 0x00
    BQ35100: ACK
    Master: 0x14
    BQ35100: ACK
    Master: 0x04
    BQ35100: ACK
    Master: STOP

    And then the same for the second key:

    Master: START, 0xAA
    BQ35100: ACK
    Master: 0x00
    BQ35100: ACK
    Master: 0x72
    BQ35100: ACK
    Master: 0x36
    BQ35100: ACK
    Master: STOP

    Is that correct?

    Tahnk you,

    Fulvio

  • 0 in reply to Fulvio Troiani
    Prodigy 70 points

    Should I switch to SEALED mode first?

    I.e. FULL ACCESS --> SEALED --> UNSEALED

    Kind regards,

    Fulvio

  • 0 in reply to Fulvio Troiani
    TI__Mastermind 24870 points

    Yes, sealed.

    Then go unseal and then full access.

  • 0
    Intellectual 710 points

    Hi,

    I have the same issue of yours.
    I'm in SEALED mode (control status = 0x6080) so I send the unseal keys (0x1404 and 0x7236) but nothing happens. I think this is a timing issue, indeed in debbugging mode it works perfectly. I tried many delay between the two writes but I'm still stuck here. 
    Maybe this can help you ... and together we could solve the problem.

    best regards,
    Vincenzo

  • 0 in reply to Vincenzo Cristiano
    Prodigy 70 points

    Hi Vincenzo,

    in my case it was just that the allowed state transitions are not documented anywhere, so I had to discover it by myself that I had to move from FULL ACCESS to SEALED before to get into USEALED.

    I used just 20 milliseconds delay between the two keys and it worked.

    Regards,

    Fulvio

  • 0 in reply to Fulvio Troiani
    Intellectual 710 points

    Hi Fulvio,

    thank you for your quick reply!

    I tried with 20 milliseconds delay but did work neither. I tried a WHOLE SECOND delay beween two writes and  it works fine. Honestly, I don't know why but maybe this request another topic on forum.

    Regards,
    Vincenzo 

  • 0 in reply to Vincenzo Cristiano
    TI__Genius 10370 points

    Both,

    When the gauge receives an Unseal or Full Access attempt it will force a 4 second lockout. Sending the Seal command does not trigger the lockout. 

    In addition, the gauge must be sealed to go to unsealed and unsealed to go to full access. 

    Thanks,

    Eric Vos

  • 0 in reply to Vos
    Intellectual 710 points

    Thank you Eric,

    is there any Documentation with DF access timing or something concerning this lockout ? I'm looking in TRM without success. 

    Regards,


    Vincenzo

  • 0 in reply to Vincenzo Cristiano
    Prodigy 70 points

    Looks weird...

    Me too, I found such situation.

    The device comes out of the power-on reset in SEALED, then I do some other thing, then switch to UNSEALED (and it's OK), then try to switch in FULL ACCESS but it does not work. The sequence is:

    • Power on
    • Do something
    • Get Control Status --> 0x6080
    • Send UNSEAL KEY #1 (0x3E, 0x14, 0x04)
    • Wait 100 ms
    • Send UNSEAL KEY #2 (0x3E, 0x72, 0x36)
    • Get Control Status --> 0x4080 GOOD!
    • Wait 10 seconds
    • Send FULL ACCESS KEY #1 (0x3E, 0xFF, 0xFF)
    • Wait 100 ms
    • Send FULL ACCESS KEY #2 (0x3E, 0xFF, 0xFF)
    • Wait 5 seconds
    • Get Control Status --> 0x4080 Why????

    I did the same in other situations, now the code is merged with other operations and it does not work. I do not see the reason why, given the above Control Register's values.

  • 0 in reply to Fulvio Troiani
    Intellectual 710 points

    Hi Fulvio,

    I tried several timing between this "access" operation over DataFlash. Now, I have this behaviour:



    • UNSEALED

      • write(0x00,0x14,0x04)
      • WAIT 1 SECOND
      • write(0x00,0x72,0x36)
      • WAIT4 SECONDS for LOCKOUT as  said

    • FULL ACCESS
      • write(0x00,0xFF,0xFF)
      • WAIT 1 SECOND
      • write(0x00,0xFF,0xFF)
      • WAIT4 SECONDS for LOCKOUT as Eric said

    After each operation I found 0x4080 and 0x2080, respectively.
    So, for me it works GOOD

    I also tried to remove the 1 SECOND delay between the two unseal key writes without success.

    Regards,
    Vincenzo.

  • 0 in reply to Vincenzo Cristiano
    TI__Mastermind 24870 points

    I've reached out to the AE to help here.

  • 0 in reply to Kang Kang
    TI__Genius 10370 points

    Fulvio/Vincenzo,

    As i read this thread back I do not see any remaining open questions. The latest one from Vincenzo says it is working well. Are there still open questions about this topic? 

    Thanks,

    Eric Vos

  • 0 in reply to Vos
    Prodigy 70 points

    Hello Eric,

    well... actually no.

    Anyway, we finally decided to do a laboratory calibration by means of the Battery Management Studio so I don't need to write calibration firmware by hand anymore. So the problem is skipped, not solved.

    There are many technical documents, but why cannot a piece of information like this attached be found anywhere?

    I mean, it took me three working days to discover that by myself, after searching for nonexistent problems on I2C interface and protocol...

    By the way, also the Battery Management Studio and TI's website download are not working too. I'll open another thread for that.

    Kind regards,

    Fulvio

  • 0 in reply to Fulvio Troiani
    TI__Mastermind 24870 points

    Hello Fulvio,

    Can you check ti.com, it should be on there for bqStudio.