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.

BQ78350: NACK's

Part Number: BQ78350
Other Parts Discussed in Thread: BQ76920,

Hello;  As per my previous inquiry, I get random NACK's when reading the 78350. However, I can then repeat the request and eventually, successfully read. My guess - for which I'm seeking confirmation - is that, since my "pings" are asynchronous with the ALERT from the 920, if the 350 is busy communicating with and/or processing data from the 920, it is not able to communicate with its host in parallel (??).  Can you confirm that the 350 is not running with an RTOS which would permit multi-tasking, but is just a "main loop" F/W architecture?

If so, that would explain the random NACK's

Thanks

  • Hi Jeffrey,

    The BQ78350 will have trouble with continuous reads because it does get busy communicating with the BQ76920. I believe it is just using a main loop F/W architecture. 

    Best regards,

    Matt

  • Hello;

    How does a host synchronize with the 78350 to know when it is ready to accept SMBus commands? As per the SMBus spec, a slave must always ACK its address, but if/when the 78350 is busy, it appears not to.

    My intention was/is to use the 920's ALERT signal to interrupt my host and commence reading of the 78350, but since the 78350 will be busy interacting with the 920 at that point, I'm unclear as to when I should start the SMBus transactions??? What I'm thinking is to use the method commonly employed in EE drivers where the host issues read transactions to see if the slave is ready, since during EE writes it won't ACK its address....but again, SMBus slaves are required to do so....so?

    Thanks

  • Hi Jeffrey,

    I think as long as you don't continuously read the SMBus, there should not be issues with the BQ78350 being able to service the BQ76920 and respond to the SMBus. You should be careful with routing the ALERT pin to the host - this pin can also be used as an input for an external secondary protector to force high, so it is very sensitive to noise. Many users place a filter cap on this pin in addition to the pull-down resistor (see TI Reference designs for examples).

    Also, the ALERT pin goes high any time a new ADC measurement becomes available, so using it as an interrupt to the host will result in a large number of transactions.

    Best regards,

    Matt

  • Hi Matt; That may very well be the problem on the EVM. I note that the cap is DNP, and since the system is surrounded by a noisy scope, stm32 EVM, and more, that behavior may be being triggered by noise. But it recovered (so far) after...je ne sais quoi 

    I sync'd to the falling edge to reduce NACK's and it helped a bit. Regardless, the 350 replies after a retry. I've uploaded the crazy behavior for future reference