TMS320F280049C: How to verify using the PI-Commander GUI with a PMBus target example (LAUNCHXL-F280049C - TMS320f280049c)

Hi EunKyu,

Are any of the four bytes received? 

EunKyu Son said:

In fact, as shown in the figure below, when you set a 9-byte packet in handle_block_read.c, it is copied normally to the ekson_buffer and ekson_bytes variables in pmbus_stack_handler_target_read_wait_for_eom.c.

Why is this set to 9-bytes, if the need is to read 4-bytes? 

In addition, you are handling commands properly, so that the current command is being set before doing a block read. Are the other files such as pmbus_stack_config updated to match your desired settings?

Best Regards,

Aishwarya

Both 4 bytes and 9 bytes did not function properly.
When sending 0x9A, 0x9B, and 0x99 from PI-Commander, I checked the order in the handler using the code below, and

PMBusStack_targetIdleStateHandler, PMBusStack_targetReadBlockStateHandler, PMBusStack_targetReadWaitForEOMStateHandler The sequence of the three functions proceeded in the order of the numbers in the section labeled “ekson sequence.”

switch(PMBusStackObject_getNextState(handle))
{
case PMBUS_STACK_STATE_IDLE: // sequence execute: 1(start),2,4,7,9,12,14
PMBusStack_targetIdleStateHandler(handle);
break;
case PMBUS_STACK_STATE_RECEIVE_BYTE_WAIT_FOR_EOM: // none
PMBusStack_targetReceiveByteWaitForEOMStateHandler(handle);
break;
case PMBUS_STACK_STATE_READ_BLOCK: // sequence execute: 6,11,16(end)
PMBusStack_targetReadBlockStateHandler(handle);
break;
case PMBUS_STACK_STATE_READ_WAIT_FOR_EOM: // sequence execute: 3,5,10,13,15
PMBusStack_targetReadWaitForEOMStateHandler(handle);
break;
....

I checked the contents of the PMBusStack_targetReadWaitForEOMStateHandler function.
The following contents were found in the PMBusStack_targetReadWaitForEOMStateHandler function.
if(((status & PMBUS_PMBSTS_EOM) != 0U) && ((status & PMBUS_PMBSTS_NACK) != 0U))
I forced the addition of PMBus_putTargetData(base, buffer, nBytes, true); inside the if statement to force the transmission of the desired data. As a result, PI-Commander received the expected data in response. (Only 4 bytes or less is possible)

The question is that I set a breakpoint right before the PMBus_putTargetData() function, but 256 bytes of 0xff values are sent beforehand. I am wondering what the problem is.

What is the issue? Since I cannot use the library example as is, I am requesting assistance.

Is this example not compatible with pi-commander?
I would like to know how to use it with pi-commander.

Alternatively, I need an example that can communicate with pmbus gui.

The part that transmits the value 0xff as 256 bytes is estimated to be the underlined part in the figure below.
If you comment out that part, 256 bytes will not be transmitted, but instead, the command data received from PI-Commander in the IDLE state will not be displayed.
This problem seems to be related to the 'quick command' part at the beginning.

EunKyu,

Thanks for providing the information. We’ll look into this further.

We do not have any specific examples to interface with pi commander, but this example should be able to be modified for different use cases.

Best Regards,

Aishwarya

Thank you for reviewing my question.

If PMBus communication is possible, the firmware can reach the completion stage, but the porting is not yet complete, causing issues with the project production schedule.

I would like to monitor the PMBus Target example (or via I2C) using PI-Commander in a manner similar to the LM5066EVK.

Additionally, when using the PMBus (I2C 2-wire) example, 256 bytes of data are not coming in as 0xff but instead are mixed with unknown random data.

It is necessary to confirm whether this issue is due to compatibility between the monitoring program and the example, or if the example is being used incorrectly.

Additionally, there is a peculiar issue. When you enter a fake value into the fast command handler and ensure that the block write does not exceed 4 bytes, meaningful values are displayed in the PI-Commander log window as shown in the figure below. However, if the block write exceeds 4 bytes, meaningless 0xff values are transmitted.

1. I do not understand why meaningless values are sent when data exceeding 4 bytes is transmitted in the handler function within handle_block_read.c. (The data must be 4 bytes or less.)
2. I do not understand why the handler function within handle_quick_command.c should send meaningless data.

Add dummy data to quick command

Add block read response sequence for block write command (<4bytes)

The sample code used so far is attached below.

f28004x_pmbus_target_example.zip

Hi EunKyu,

Apologies for the delay, we are still looking into this and will get back to you shortly.

Best Regards,

Aishwarya

EunKyu,

EunKyu Son said:

I would like to monitor the PMBus Target example (or via I2C) using PI-Commander in a manner similar to the LM5066EVK.

Let me connect you with the LM5066 EVK support team for further support on this as they can better help on how to use the device. 

I've looped in our SW expert regarding the other two issues. 

Best Regards,

Aishwarya