• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 63 subscribers
  • Views 277 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.

BQ79600-Q1: Misinterpreting data in response frames, unclear behavior in comparisson to EVM Board

Ole Hillmann
Prodigy 10 points
Part Number: BQ79600-Q1
Other Parts Discussed in Thread: BQ79616-Q1

Tool/software:

We are currently developing a BMS with BQ796XX chips. We aim to use our own PCB, though we have found the single chips to behave differently from the EVM Kits.

While testing our program using the 79600-EVM Board and 79616-EVM Board the system functioned as described in the datasheet.

While testing our self developed system we found the chip to decript data differently in direct comparison to the EVM-Board.

After replacing the chip in our own board the new chip decripts different data from the same datastream, than both either chip did.

The recieved data is also not stable and changes bits every few seconds.Here are 3 different instences of this:

Possible signal quality issues have been ruled out so far, as seen in screenshots. Also rise and fall times are up to specification.We used the specification found in the application Note provided. We used the Application Note BQ79616-Q1 Daisy Chain Communications- figure 3.1 for reference as shown:

The sent data is as follows:

What is happening? Has anyone had this problem before? What data should we provide to make this clearer?

  • 0
    TI__Expert 7010 points

    Hi Ole,

    To confirm, using the EVM works but using your board would cause a problem where every few seconds, a returned frame does not have the correct bits?

    Also to confirm, switching the IC of BQ79600 on your board did not fix the problem?

    Questions I have are:

    What is the schematic of the BQ79600 board?

    What is the setup of your boards i.e. how many BQ79600/BQ79616s are used?  

    What does the fault summary read? What do registers 0x2301-0x2307 read when this issue happens?

    Regards,

    David

  • 0 in reply to David Ray
    Prodigy 10 points

    Hello David,

    Thank you for the fast reply.

    No, exchanging the BQ79600 did not solve the problem, it currently led to the chip reading back different, though still nonsensical data.

    We had the system running on the 600-EVM board and with anywhere from 1 to 3 616-EVM boards, however when exchanging the 600-EVM for the self developed board the system no longer responds proper data. During this we reduced the amount of Slaves to 1 tor reduce points of failure. however when changing back to the 600-EVM board the system responds again as expected.

    We have no reason to expect the second chip to be broken as it still decodes and sends at the proper time but responds wierd data on the rx pin.

    I hope the schematic can be accessed to be read, I did white out irrelevant parts. The white box in the filter part hides TVS-diodes that caused signal quality issues and were therefor removed early on in testing.

    We are currently unclear if the fault registers are being read correctly, ill get back to you with those. So far the chips behavior has been as expected except the data it outputs doesnt seem to contain the read bits

  • 0 in reply to Ole Hillmann
    TI__Expert 7010 points

    Hi Ole,

    The schematic appears to be fine as the daisy chain has the recommend components. The CVDD pin has 100nF on your board instead of the datasheet's 220nF but I do not believe that this would cause the issue. To fully confirm that this is not an IC issue, could you unsolder the EVM's BQ79600 and replace it with the BQ79600 that the issue was observed on? And then test the EVM to see if the issue appears.

    Regards,

    David

  • 0 in reply to David Ray
    Prodigy 10 points

    Hi David,

    We seem to have found the issue - DVDD was bypassed by 220p instead of the needed 220n

    During the past months of troubleshooting no one has caught that, but it seems that made the voltage rail too unstable to put out useful data

    We were highly against desoldering the chip from the EVM Board, as we are on a deadline and didnt want to kill the one board, that we knew worked. Thankfully we caught the problem now.

    Thank you for your help though, we very much appreciate such fast help.