• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 63 subscribers
  • Views 1007 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Unable to communicate with BQ40Z60 using AlternateManufacturerAccess()

Ildefonso Aspera
Prodigy 30 points
Other Parts Discussed in Thread: MSP430G2553, BQ40Z60

Hi,

I 've designed a PCB which has a BQ40Z60 and I'm having problems trying to communicate with it from a MSP430G2553 using AlternateManufacturerAccess().

When sending SBS Command 0x57, ManufacturingStatus, I get 0x0002 as data(I assume it is correct).

When sending MAC 0x0057, ManufacturingStatus(), using ManufacturerAccess() and ManufacturerData(), I get a ACK to each byte of SMBus block write and I get 0x0002 as data .

When sending MAC 0x0057, ManufacturingStatus(), using AlternateManufacturerAccess(), I get a NACK as a response to the first byte of SMBus block write. So I don't transmit the second byte of the command and I get 0x5704 and 0x0000 as data(which isn't correct, should be 0x0057 0x0002)
I also tried to send the command in big endian (which obviously doesn't work) and I got exactly the same situation as before.

If I try to send another command, 0x0006, (Chemical ID()) as in the example in page 106 of SLUUA04, I get:

Using ManufacturerAccess(), I receive ACK's for the data sent (0x0006) and 0x1002 as data received, which I suppose is correct.

Using AlternateManufacturerAccess() I receive ACK's  for the data sent (0x0006) and as data received 0x0604 and 0x1000 (should be 0x0006 and 0x1002?)

Furthermore, if I write the command with ManufacturerAccess()  and read the data with AlternateManufacturerAccess(), the response is the same, 0x0604 0x1000.

If I do the opposite, write the command with AlternateManufacturerAccess()  and read the data with ManufacturerData(), I get 0x1002 (although I suspect the output buffer doesn't get correctly updated).

Trying with other MAC's, such as 0x0050 (SafetyAlert), 0x0051 (SafetyStatus) or 0x0064 (Lifetime Data Block 5) gives me the same result of 0x0057, a NACK.

If I understood correctly (page 106 of SLUUA04) in order to get data from the BQ40Z60 using AlternateManufacturerAccess(), I have to send a SMBus block write with command 0x44 and MAC. Then I have to send a SMBus block read with command 0x44 and read the data.

So, having said all this, do you know what am I doing wrong?

Thanks, 

Ildefonso

  • 0
    Prodigy 30 points

    I think this scope shots could help.

    They are named in the same order as the last post, that is:

    1 - SBS Command 0x57
    2 - MAC 0x0057 using ManufacturerAccess() and ManufacturerData()
    3 - MAC 0x0057 using AlternateManufacturerAccess()
    4 - MAC 0x0006 using ManufacturerAccess() and ManufacturerData()
    5 - MAC 0x0006 using AlternateManufacturerAccess()
    6 - MAC 0x0006 using ManufacturerAccess() and AlternateManufacturerAccess()
    7 - MAC 0x0006 using AlternateManufacturerAccess() and ManufacturerData()


    Altough these images show a lot of coupling between data and clock, I also tried with a 470 pF capacitor on data line, which removed the spikes, but the result was the same.

    Thanks,

    Ildefonso

    images.zip

  • 0 in reply to Ildefonso Aspera
    TI__Prodigy 620 points

    Let’s start with addressing your first statement:


    When sending SBS Command 0x57, ManufacturingStatus, I get 0x0002 as data(I assume it is correct).

    According to section 11.1.43 (page 123) of SLUUA04C, the 2 bytes of data that you have returned to you is 0000000000000010 seem to be erroneous. Are you sure that this is what you receive? As bit 1 of the block being high cannot be valid, as in the table shown in 11.1.43, this bit is reserved; you should be reading a response ranging from 0000011111111000 – 0000000000001000 (0x07F8 – 0x0008) no?


    BR,

    Camran Ahmed

  • 0 in reply to Ahmed Camran
    Prodigy 30 points

    I'm pretty sure thats what I receive. I've checked the transmission again right now and I've attached an image with the data from the oscilloscope. It can be translated as:

    Start

    0x16 (from master)
    ACK (from slave)

    0x57 (from master)
    ACK (from slave)

    Repeated start

    0x17 (from master)
    ACK (from slave)

    0x02 (from slave)
    ACK (from master)

    0x00 (from slave)
    NACK (from master)

    Stop

    It has the same structure as the first example shown in page 2 in "SMBus made simple", which can be found here, so the transmission seems correct.

    Thus, the LSB is 0x02 and the MSB is 0x00.

    Regards,
    Ildefonso