BQ79600EVM: SPI_RDY does not get high after a read frame

Due to severe weather that has disrupted power and telecommunications in the Dallas area, responses will be delayed until at least tomorrow. 

Sorry for the inconvenience.

Lukas,

What are sending before this read command? Also, register 0x343 is an internal register used to synchronize the DLL and will not provide any useful information.

Regards,

Ben

Hey Ben, this is Part of the Auto-Addressing Procedure, we are following the instructions of the Software Design Reference. We also tested the software on our self-developed hardware in the mean time where this doesnt seem to be an issue, because there the spi_rdy Pin goes high. Therefore i think this has to be hardware related.
Our Send Order is:

BQ_SendFrame(BQ_STACK_WRITE, 1, 0, 0x2030, 0xFF);

BQ_SendFrame(BQ_STACK_WRITE, 1, 0, OTP_ECC_DATAIN1, 0);

BQ_SendFrame(BQ_STACK_WRITE, 1, 0, OTP_ECC_DATAIN2, 0);

BQ_SendFrame(BQ_STACK_WRITE, 1, 0, OTP_ECC_DATAIN3, 0);

BQ_SendFrame(BQ_STACK_WRITE, 1, 0, OTP_ECC_DATAIN4, 0);

BQ_SendFrame(BQ_STACK_WRITE, 1, 0, OTP_ECC_DATAIN5, 0);

BQ_SendFrame(BQ_STACK_WRITE, 1, 0, OTP_ECC_DATAIN6, 0);

BQ_SendFrame(BQ_STACK_WRITE, 1, 0, OTP_ECC_DATAIN7, 0);

BQ_SendFrame(BQ_STACK_WRITE, 1, 0, OTP_ECC_DATAIN8, 0);

BQ_SendFrame(BQ_BROADCAST_WRITE, 1, 0, CONTROL1, 1);

for(int i = 0; i <= BQ_NBR_OF_DEVICES; i++){

BQ_SendFrame(BQ_BROADCAST_WRITE, 1, 0, DIR0_ADDR, i);

}

BQ_SendFrame(BQ_BROADCAST_WRITE, 1, 0, COMM_CTRL, 2);

BQ_SendFrame(BQ_SINGLE_DEVICE_WRITE, 1, BQ_NBR_OF_DEVICES, COMM_CTRL,3 );

int8_t buffer[BQ_NBR_OF_DEVICES + 1];

BQ_ReciveFrame(BQ_STACK_READ, 0, OTP_ECC_DATAIN1, 0, buffer);

BQ_ReciveFrame(BQ_STACK_READ, 0, OTP_ECC_DATAIN2, 0, buffer);

BQ_ReciveFrame(BQ_STACK_READ, 0, OTP_ECC_DATAIN3, 0, buffer);

BQ_ReciveFrame(BQ_STACK_READ, 0, OTP_ECC_DATAIN4, 0, buffer);

BQ_ReciveFrame(BQ_STACK_READ, 0, OTP_ECC_DATAIN5, 0, buffer);

BQ_ReciveFrame(BQ_STACK_READ, 0, OTP_ECC_DATAIN6, 0, buffer);

BQ_ReciveFrame(BQ_STACK_READ, 0, OTP_ECC_DATAIN7, 0, buffer);

BQ_ReciveFrame(BQ_STACK_READ, 0, OTP_ECC_DATAIN8, 0, buffer);

BQ_ReciveFrame(BQ_SINGLE_DEVICE_READ, 0, 0x2001, 0, buffer);

Regards, 

Lukas

Lukas,

What are the two hardware setups that you used? Which one worked and which one failed? Can you send the entire logic analyzer log (you can attach it to the response with the insert button below the text box)?

Regards,

Ben

Ben, 
We have a self developed PCB with an STM32F407VGT6 on which the SPI_RDY Pin does what it should, but MISO/SOMI is constantly high. On the other hand we have an BQ79600-EVM030 on which we have the described issue with the SPI_RDY Pin that goes down when we send a Read Frame

As i am facing issues with uploading the files i uploaded them to Google Drive here

The EVAL file is as you might imagine the file from the evaluation board and the master file is the one of our PCB

I hope this helps understanding our problems.

Regards,

Lukas

Ben,

I updated the script according to your comments, but i still dont get any answers. I have uploaded another logic analyzer file to my drive. Maybe you see any other issue with it, that could resolve my issues. In it i have marked the commented areas with a marker

Regards,

Lukas

Ben,

i fixed your feedback and annotated the channels for you in another logic analyzer file, and in this you can clearly see that as soon as i hit the first read command the spi rdy is pulled down and stays there for an unknown reason.
I hope you have some ideas why that could be.
Thank you in advance

Regards,

Lukas

Lukas,

Can you perform a single device read from device zero and device one and see if there is some other communication failure?

Regards,

Ben

Dear Ben,

i have performed the single device read for device 0 and device 1 and uploaded it to the drive.

Regards,

Lukas

Lukas,

In the log you sent me we can clearly see the single device read to the bridge device (device 0) working as expected:

The SPI_RDY line is pulled low when it receives the INIT byte of a read command and after some time the SPI_RDY line is pulled high when the bridge device indicates it is ready to send the response frame. 

However, once SPI_RDY is high, the BQ79600 expects nCS to be pulled down and clocks to be sent for it to send the response. When the single read is tried again for device 1, this is done:

But for some reason it isn't done for device 0. 

Additionally, the read command to device 1 will not work until after auto-addressing. Please send the clocks after you read from device 0 and change the device 1 read until after you attempt auto-addressing.

Regards,

Ben