BQ4050: Fails to Respond to Many ManufacturerBlockAccess Commands

1) I'm using an STM32 NUCLEO board with Mbed. I have the EV2400 and have done some experimentation with bqStudio.

2) Not yet. I checked bus operation with a scope but don't yet have a logic analyzer.

Returning the command on MfrBlockAccess does not indicate success. Often I receive the command echoed back but then all zeros. In the case I gave above, the data returned by 0x44 0x54 0x00 is not valid interpreted in either big or little endian order. The device security status bits are in an invalid state.

I am now receiving data back from the device that is all 0. For some commands I will receive repeating values like 0x23 23 23 23 or 0xdb db db db. I think there is a problem in the I2C engine of the device.

For DAStatus1 or DAStatus2 via MfrBlockAccess, I receive the command echoed back but all further bytes are zero.

< 44 71 00
> 71 00 00 00 00 00 00 00 .. 00

I implement this in Mbed with:

data[0] = 0x44; data[1] = 0x71; data[2] = 0x00;
i2c.write(addr, data, 3, true);
i2c.read( addr, data, 33);

If I read DAStatus1 normally I get the proper result:

data[0] = 0x71; data[1] = 0x00; data[2] = 0x00;
i2c.write(addr, data, 1, true);
i2c.read( addr, data, 33);

> 20 14 10 14 10 15 10 13 10 3e 40 43 40 00 00 .. 00

Which corresponds to cell voltages. The many zeros represent lack of discharge.

The original thing that delayed me was that the bq4050 needs messages to be framed properly with start/stop bits. This is the true you see in i2c.write, it leaves the frame unterminated. I know you can't support arbitrary libraries but a concrete description in terms of  I2C bus operations would be helpful should you lack a way to go forward.

SId,

I would need to see the logic analyzer to really understand what might be going on. I can comment SMB and I2C are not identical in the rules. As you say please check to make sure you are sending the proper Start/Stop. 

to address your above SMB does not return the length becuase block reads are always 32 bytes. 

SMB is a well spec'ed standard. You can find lots or resources online SMB V1.1. 

Thanks,

Eric Vos

Very well, I will be back in a few days with a bus capture. I have an analyzer on order.

You should not be so dismissive. I am observing extremely aberrant behavior with these repeated reads of junk, zeros, or patterns, especially in light of the normal commands working just fine. The same code I use to talk to the bq4050 has no issues with many other devices. Something is different about the bq4050. It would be more honest of you to say you don't know of any errata or that TI does not keep any guidance on implementation details. I don't mean to sound unpleasant, but I seriously have done my due diligence here and was hoping TI had more information.

If you pick 10 I2C/SMBus devices at random it's almost a sure bet they will not be able to coexist on a bus due to differences in their I2C engines and how they implement or do not implement protocol features like clock stretching. Your statement that SMBus is a well specified standard is irrelevant, I have no assurance that the bq4050 reliably implements the standard. In fact it is very likely there is some error with the I2C engine, though it may not be the main issue I am encountering. I've used another product where "issues" were recognized with the driver and the fix was to clock SCL ~10 times to restart the interface. On error, I saw behavior similar to what I am seeing now -- all zeros or repeated 0x23.

Back in a few. 

Sid,

I am not being dismissive in the slightest. 

However, this device has literally millions and millions in the field and the SMB engine has gone through an extensive validation process. I do not doubt you are having an issue, but without actual data I cannot speculate as to the root cause. maybe things come to mind

1) signal quality

2) Device is having a reset condition occur

3) Something in your host driver code. 

4) Communication speed

5) not reading correct 32 bytes

6) repeated starts in wrong place

7) bus high time is causing the engine to clear

There are literally too many reasons to count and speculating would waste my time and yours. I am sorry you feel like i am being dismissive of the issue, and i can assure you that is not the case. 

What I do know is when I test the command using the TI provided tools I do not see an issue on my end. My suggestion to use the EV2400 and bqStudio to read/write the command is me trying to get solid footing in knowing where to debug. 

Thanks,

Eric Vos

Vos, thanks for understanding. I've gotten some captures for us to look at.

Above being read of OperationStatus, returning as expected.

Above being failure of MfrBlockRead for the same command, 44 54 00. The STM provided SMBus HAL fails the same way. I'm digging deeper but this looks like device-directed behavior. Despite the NAK the device echos back 54 00. The number changes based on the command I attempt.