• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 155 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.

MSPM0G3507: PMBus reading failure

Crane Shao
Intellectual 1000 points

Part Number: MSPM0G3507

Hello,

I am using the PMBus middleware from the SDK v2.04.00.06 from here C:\ti\mspm0_sdk_2_04_00_06\examples\nortos\LP_MSPM0G3507\pmbus\pmbus_controller\ticlang

Here are the results from all the tests:

    SEND_BYTE_TEST:       sent 0x03, 0xC7, ACK, then both lines go back high, return ok
    RECEIVE_BYTE_TEST:   receive 0x55, 0x77, NACK, return error
    WRITE_BYTE_TEST:      sent 0x20, then both lines go back high, return error
    READ_BYTE_TEST:       sent 0x20, then both lines go back high, return error
    WRITE_WORD_TEST:   sent 0x42, then both lines go back high, return error
    READ_WORD_TEST:    sent 0x42, then both lines go back high, return error
    BLOCK_READ_TEST:    sent 0x99, receive 0x02, both lines go low (seemingly driven by master), return error
    BLOCK_READ_TEST1:  sent 0x9A, receive 0x12, both lines go low (seemingly driven by master), return error

What might go wrong with this example? Any attention needs to be paid to use this example on a particular device?

Thanks!

Crane

  • 0
    TI__Genius 13985 points

    Hi Crane,

    I'm using a SDK version 2.10.0.04 in my environment and test the example, no issue found from my side.

    Is it possible for you to upgrade the SDK to latest version? I think we only need to connect I2C SCL and SDA together for controller and target example, and keep them pulled up for testing the example. 

  • 0 in reply to Pengfei Xie
    Intellectual 1000 points

    Thanks for your reply.

    I think it is unlikely that the version 2.04.00.06 doesn't work but 2.10.0.04 works. But anyway, I will update my version and try.

    At the same time, I would like to confirm if the below issue when using the generic I2C library could be caused by not using the PMBus specific library? As the PMBus library is static library, I couldn't verify the differences between the generic APIs and PMBus APIs.

    Reading bytes and words are fine, but reading blocks have the below issue:

    1. byte counts are always correct.

    2. except reading a two-byte block for MFR ID, for all other block readings, gets all data bytes as 0xFF, which are not as specified in the spec;

    3. for one 18-byte block, gets first 9 data bytes whose values are the same as specified in the spec, but the remaining 9 bytes all 0xFF, which are not as specified in the spec;

    4. gets the PEC when there is an extra byte at the end, whose value is correct according to the slave address+W, byte count and byte values;

    Thanks!

    Crane

  • 0 in reply to Crane Shao
    Intellectual 1000 points

    The result with V2.10.0.04 is exactly the same. 

    And confirm the error comes from the reading API, not from checking the data buffer for received data. Extending timeout from 10ms to 100ms doesn't change the results.

    I am wondering what the PMBus device tested with this example is? I am using BCM6135 Vicor. Is it possible that the difference between the devices causes this issue?

    By the way, I am able to read correctly from most commands by using the generic I2C library while just some block reading not correct. Trying to use PMBus-specific library to see if it can read them also correct, but the result is even worse than generic I2C library. Wondering if the PMBus-specific library works generically for all PMBus devices.

    Thanks!

    Crane

  • 0 in reply to Crane Shao
    Intellectual 1000 points

    As the command for testing Reading byte/word are not available for this device, I suppose the example is designed for a specific device, not general for any device. After changing the available commands and remove the check of the received data, reading byte/word works fine.

    For block reading, it fails after reading the byte count and byte count shows correct on the waveform. From the waveform, the SCL is hold low by the master and the next clock for the first data byte is not generated at all. The SDA is hold low by the slave. Considering the device is able to respond with byte counts and following data from the test using generic I2C library, most likely the situation is caused by the master. So the question is how the PMBus reading API handles this after receiving the byte count. 

    As the APIs are from a static library and there is no any relevant configuration provided, anyone have any information about how the PMBus APIs are designed for block reading?

    Thanks!

    Crane

  • 0 in reply to Crane Shao
    Intellectual 1000 points

    It is the clock issue. Changing the clock from 40M to 32M addressed this issue.