• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 3 answers
  • Subscribers 62 subscribers
  • Views 656 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

UCD3138064: Question about the pmbus_idle_handler() , whate means a read request?

user4768560
Intellectual 375 points
Part Number: UCD3138064
Other Parts Discussed in Thread: UCD3138

Why does the program comment say that "one byte, data ready, not EOM and/or PEC_VALID, for some reason, don't use data request all this means a read request" ?

if the master send a commond to read the UCD3138(slave mode), the DATA REQUEST flag will not be set to 1 ?  why the pmbus_read_block_handler use the If statement to decide whether to transmit_bytes？

Can you explain these? 

With best regards

  • 0
    TI__Genius 17090 points

    In the first code snippet, Data Request isn't set yet.  In this case, we know it's a read because there is 1 byte in RD_BYTE_COUNT, but no EOM, meaning no stop bit.

    The only thing which could cause this is a repeated start, which makes the PMBus hardware set the RD_BYTE_COUNT but not the EOM bit.  So we assume that it is a read.  So we start writing to the TXBUF before we really have to.  So in this case, we probably won't even see a DATA_REQUEST.  This is a shortcut.  If you want, you can try to look first for a data ready and a repeated start, and no EOM, and then add another state which checks for data request.  We deliberately kept the PMBus code short and sweet, but that may not be the best approach for you, especially if you want rigorous fault detection and handling.   

    The second snippet is different, because it's in the block read function.  Here the write part of the read is already done, so there is no more data coming from the master.  All the data is being sent by the UCD to the master.  So when the last byte from RX_BUF is ACKed by the master, the PMBus hardware on the UCD will set the data request bit. 

  • 0 in reply to Ian Bower
    Intellectual 375 points

    Thanks for your help!

    Do you mean that the master sents a series of data like the following figure.but do not send data after a write command, and the Acked is automatically finished by the hardware on the UCD(slave mode). then the master directly sent the start signal and Device Addr Rd ,waiting for the A? for this i have a question :when the polling the pmbus state,the if condition can only be 1+PMBST_BYTE0_DATA_READY ,not be  1+PMBST_BYTE0_DATA_READY+PMBST_BYTE0_DATA_REQUEST? because the Device Addr Rd will make the PMBST_BYTE0_DATA_REQUEST bit set to 1 ,the acked after the commond has done automatically. the PMBST_BYTE0_DATA_READY is set .

    what's wrong ?can you explain it in detail ? Looking forward to your reply ,sincerely!

    (pmbus_status_half_word_0_value & (PMBST_HALF0_CHECK_BITS + PMBST_BYTE0_RD_BYTE_COUNT)) ==
    (1 + PMBST_BYTE0_DATA_READY )

    With best regards.

  • 0 in reply to user4768560
    TI__Genius 17090 points

    I'm not sure what your question is.  You ask about the master not sending data after a write command, but you show a Process Call where the master does send 2 bytes of data, and then a repeated start. 

    Our standard old PMBus code does not support a process call.  In normal situations, you will get a data ready and a 2 instead of a 1 in rd_byte_count. 

    Some of the new EVM codes do support process calls.  I know that the PFC code does.  You can find it here:

    I believe it also supports cases where you get DATA_REQUEST along with DATA READY.  This doesn't happen in normal operation, but certain faults on the PMBus can make it happen with some codes. 

    If this doesn't answer your questions, please give me a more detailed sequence of what exactly you are asking about. 

  • 0 in reply to Ian Bower
    Intellectual 375 points

    Thanks for your reply！

    Is your situation as shown in the figure below? I also want to ask, after the host issued a write command, wait for the slave to answer, the slave (UCD) response is automatically completed by the hardware? Then the host issues a read request and waits for the slave to answer. The answer is automatically answered by the slave. (Is the gray A in the picture answered automatically from the machine?)

          Is the read data instruction of the smbus tools provided by TI official using the instruction sequence shown above?I want to use stm32 as host to communicate with slave UCD3138, so I want to understand how this is achieved. Thank you for your guidance.

    with best regards.

  • 0 in reply to user4768560
    TI__Genius 17090 points

    Yes, the UCD3138 with our program responds to the standard PMBus messages, and our adapter uses the standard PMBus format.  I wouldn't describe the response as automatic, because the program is also involved, not just the hardware.  But if you count the program as well, then you could call it automatically.