• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 62 subscribers
  • Views 567 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: device is not responding to read request

David Slack
Prodigy 10 points
Part Number: BQ79600-Q1

Hi,

We are using the BQ79600 as a bridge unit to take readings from a BQ79718 board which is connected in the daisy chain.  We are using the TMS570LC43x microprocessor to control the bridge via SPI interface.  Generally this is all working fine, but at times we are not receiving the expected response BQ79600 device.

We are using the SPI_RDY line to determine when we can transmit or receive data on the SPI bus.  We are periodically requesting readings from the BQ79718 board but the amount of data we are reading is quite small (about 36 bytes max, 2 bytes min).  

I have some detailed scope traces of the transactions on showing a successful transfer and a 2nd image showing that the SPI_RDY line has remained low.

Successful transaction image 

Successful Data Transfer :-)

With reference to the image above:

Packet 115 shows the command request to read 6 bytes from address 0x05B8.

You can see the SPI_Rdy line goes low part of the way through the request being sent.  The Red trace shows activity on the daisy chain bus, and it can be seen that after the first 7 characters were passed on the daisy chain bus, a further 12 bytes are seen which correspond with the response from the device sending back its data to the bridge.  30.18us later the SPI_RDY line is raised which we were polling to determine when the data was ready.

This transaction is successful for about 80% of all data transfers but I have identified that sometimes while polling the SPI_RDY line we hit our maximum timeout as shown in the image below.

Un-Successful transaction image

un-successful data transfer :-(

With reference to the image above:

Packet 123 shows the command request to read 6 bytes from address 0x05B8.

You can see the SPI_Rdy line goes low part of the way through the request being sent.  The Red trace shows the transmission of the data onto the bus but there is no response from the intended target on the bus.  The SPI_Rdy line remains low and there is no further traffic on the bus for at about 200ms after which my software performs a "Comm Clear" (Section 7.3.2.1.2.1.2 of the BQ79600-Q1) action is performed.  After this the original request is re-sent and the device responds correctly.

Summary, it seems that for some reason the request to read data from the BQ79718 device numbered "01" on the bus has not been interpreted or responded to correctly.

Please can you advise me as to what might be causing this and how it can be fixed.

Regards,
David

  • 0
    TI__Prodigy 740 points

    Hi David,

    We need to monitor the SPI_RDY line to check when to start the SPI transaction, SPI_RDY can go low while the transaction is in progress. 

    If you want more information regarding SPI_RDY, kindly refer 7.3.2.1.2.2 section of the BQ79600 datasheet.

    Regarding the issue about no response from BQ79600 for read request, how frequently are you seeing this issue. Please monitor the COMH / COML lines between BQ79600 and BQ79718 to see if BQ79600 is receiving the data from BQ79618 ( for the read request ). If you don't see the response data on COMH / COML and the issue is frequent, please check the isolation between BQ79600 and BQ79718.

    You seems to be doing right by doing comm clear and re initiating the read request, please refer 7.3.2.1.2.2.2. for steps to read/write using SPI.

    If you have further questions, please let us know.

    Thanks,

    Ravi

  • 0 in reply to Ravichandra Sereddy Thipperudra Reddy
    Prodigy 10 points

    Thanks for the reply,

    The scope trace in Red was showing the COMH or COML line and you can see that the 6 bytes to read the data were there but there were no further data on the bus which should have been the BQ79718 passing the requested data back.

    My software is currently running on the original BQ dev boards and as such the isolation should be OK.  I have tried on 2 different BQ boards.  

    The issue is frequent and it is more pronounced when smaller requests are bring made ( 6 bytes) as opposed to my main read which is 36 bytes which Is not failing at all.

    Doing the Comm Clear does seem to resolve the issue but it is wasting about 2.5ms of processing time.

    Regards,

    David

  • 0 in reply to David Slack
    Prodigy 10 points

    I have carried out some additional tests to try and rule out any SPI timing issues and nothing made any difference.

    I have actually found that if a write command is sent prior to a "Read" command being sent then the device seems to respond correctly without the SPI_RDY line getting stuck low.

    So just prior to sending any "Read" request commands, I now write 0x00 to a ReadOnly register PARTID (0x0500) as a Stack Write Command and this now makes all my read requests successful.

    The over head of sending the additional write command is only 30.71us, which is better than having to accommodate an SPI_Rdy Timeout and then perform a Comms_Clear to recover from the situation.

    I'm interested if anyone has any ideas of a more solid solution to this issue.

  • 0 in reply to David Slack
    TI__Prodigy 740 points

    Hi David,

    Apologies for the delayed response. From the screen shot you previously shared, I see the time difference between the previous transaction (56.09 ms ) and failed read transaction ( 56.1 ms )  is less, can you please try adding the delay, you can refer 'Timing requirements' ( t8 ) in BQ79600 datasheet.

    Thanks,

    Ravi

  • 0 in reply to Ravichandra Sereddy Thipperudra Reddy
    Prodigy 10 points

    Ravi,

    I believe the t8 delay is just the indicated maximum rate at which the SPI_Rdy line should be polled.  Quote from the manual, "MCU shall check SPI_RDY pin at least every t8 (max service interval). t8 = 1ms".

    I have added a delay of 1.6ms between the last good transfer and the request for the next read command as you suggested and it does not improve the issue.  See new screen shot which shows the SPI_Rdy line going low and remaining low, which my software eventually sees as a timeout and performs a Comm_Clear.

    Regards,

    David