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-R1: Trouble reading SBS ManufacturerAccess() commands with sizes "2+1" or "4+1" in datasheet

Part Number: BQ78350-R1
Other Parts Discussed in Thread: BQSTUDIO

Hi,

I'm interfacing with a BQ78350-R1 with 1.04 firmware and having difficulty getting sensible readings from the manufacturer access list.

My code reads all unsigned int registers with no problems, it also reads the serial number register (0x1C) which is stored as a 2-byte hex.

The problem I'm having is when reading registers 0x50 to 0x57 which are stored as 4+1or 2+1 hex bytes.  Could someone explain to me what the "+1" means? 

For example, register 0x51 - SafetyStatus should return the contents of ManufacturerAccess() 0x0051 and they are all zeros when I use bqstudio which is what they should be.

When I request 0x51 from my microcontroller, I should receive 0x00 0x00 0x00 0x00 but I'm getting 0x04 0x00 0x00 0x00 in that order.

Should I be requesting 5 bytes and discarding the first?

Also, yes I have Full Access.

Thank you

  • I think I've solved the issue by reading 5 bytes total and ignoring the first.

    Section 17.2 of the technical reference manual (sluubd3e.pdf) says:

    "SMBus Read Block of command 0x23: The first two bytes of the return block will be the data length and the next bytes will be the data of the command."

    This doesn't make any sense to me. I tried discarding the first two bytes which also did not give expected results.

    Is this a mistake in the documentation or am I still doing something wrong?

    Thanks

  • Hi Ben,

    Please check 17.2 of the BQ78350-R1 TRM carefully.  Some block commands will return the command followed by the length and the data.  Others may return only the length and data.  The maximum block length is 32 which fits in 1 byte.  

    If you have BQStudio you can look at the Advanced Comm SMB tool for the data returned by commands.  With your micro a logic analyzer, scope, or other protocol analyzer can be a useful tool.

    The TRM certainly can be confusing.  I will check with the experts to see if a change should be prepared for a future revision.

  • Thanks for the response, however that doesn't tell me how the 2+1 and 4+1 is supposed to read.

    I believe it is the length like you say:

    When I request a "4+1" register I get 0x04 0x00 0x00 0x00 0x00

    And When I request a "2+1" register I get 0x02 0x00 0x00

    Wouldn't "1+4" make more sense if the length is sent first?  The next paragraph about bytes being sent Little Endian would be a REALLY good spot to drop some hints about the length bytes.

    I would recommend the sentence about the first two bytes returned being the block length be checked for accuracy and maybe a note or table explaining the data format types.  We all know what the standard "unsigned int" and "hex" means in the commands table, but when you start formatting length as "11+1", please provide explanation so that when I'm troubleshooting code, I can rule out as many assumptions as possible.

    Also, when you dive further into section 17 of the TRM, it starts listing some Types as "U2", "I2", "H2" with no key.  Yes, I know it's pretty obvious to most what they are, but then you get into 17.34 and the Type is "H2+S24" or "H20+1" which you start having to make assumptions what the documentation is trying to say.

    Very confusing to someone new to SMBUS.

    For example 18.2 under "Data Flash Access and Format" is extremely clear about data types, lengths and the byte sequence but it only covers the formats in Data Flash and no examples with lengths included in the response.  This is needed for section 17 :-)

    The Advanced Comm SMB tool with scope is a great suggestion, thanks!

  • Hi Ben,

    The 4+1 notation indicates the indicates the number of data bytes and the +1 will remind you that there is the length byte. I agree it is confusing.  There is a layering of specifications.  The BQ78350-R1 is designed following the SBS standard (http://sbs-forum.org ) which is based on SMBus (http://smbus.org ). No specification wants to duplicate the detail of the base specification, it makes for a lot of reading.

    It seems you have made progress.  Thanks for the feedback on the technical reference manual, I will pass these suggestions on for consideration in future revisions.