MSPM0G3507: LP-MSPM0G3507: Issues with Using the PMBus API

Hi Oe J,

• Can you describe the issue?
  • When you stop the code are you hanging in a wait somewhere?
  • When you scope the lines are you seeing any clock signal?
• Are we the controller or target in this PMBus interaction?
  • What is the other device on the other end?
• Are the appropriate pull-ups provided?

Regards,
Luke

Hi Luke,

When you stop the code are you hanging in a wait somewhere?
There is an issue with `uint8_t transaction = (PMBus_Commands[commandId] & 0x0F);`, so we hardcoded it to `0x40`, and the following situation occurred.
When using the code PMB_MFR_REVISION (9B), the state obtained is SMBus_State_Controller_NACK, which then returns -1, resulting in a read failure.

When you scope the lines are you seeing any clock signal?
We are currently only printing messages and have not yet connected the oscilloscope. We also don't believe it's a signal issue, especially since using the above method with command 9C works successfully.

What is the other device on the other end?
We connected I2C0 and I2C1 on the same board.

Are the appropriate pull-ups provided?
Because the I2C is directly connected, we only use one set of pull-up resistors.

Hi Oe J,

Can you scope the communication lines?

There might be some clock stretching happening that is keeping the line when it shouldn't.

Regards,
Luke

Hi Luke,
Do you want the waveform diagram?
There is an issue with `uint8_t transaction = (PMBus_Commands[commandId] & 0x0F);`, so we hardcoded it to `0x40`,
Executing the 0x9B command with a PMBus block read results in an error, and the signal indeed is not sent out.
FC can be used normally.
 

Hi Oe J,

I am going to attempt to replicate this on my side and get back to you.

On the uint8_t transaction = (PMBus_Commands[commandId] & 0x0F);. The & bit-wise operation will only allow the lower nibble to pass whereas you're attempting to send 0x40, which only has data in the upper nibble.

Regards,
Luke

Hi Luke,

If this is not done, 9B, PMB_BLOCK_READ, after the transaction, will not match with PMB_BLOCK_READ in the switch case.
How can this be fixed?
Or am I using it incorrectly?

When we use this method to test, 9C(command) is able to function.

Hi oe j,

Looking at the pmbus.c file, the PMB_BLOCK_READ is getting defined as 0x40 (line 48), I think this is a typo and the block read should be set to 0x04.

If you look at the library all the read commands are on the lower nibble and the write commands are in the upper nibble. This way when doing the bit operations it will mask the appropriate command.

So the MFR_REVISION command will end up with an OR operation between 0x50 and 0x40 which results in 0x90 when this later gets masked you end with a PMB_RESERVED for the read which goes into the PMBUS return error.

I'll push to get this fixed in the next SDK release.

Regards,
Luke

Hi Luke,
So the issue with 0x9B is still not resolved. Even after adjusting the transaction, it still doesn't work.
Does it need to perform an initialization step?
Regards,
Joe

Hi Luke,
Here is the English translation of your text:

"After correcting the 0x40 error, it can operate. I would like to ask, what is the relationship between `sSMBusTarget.nwk.txBuffPtr[0] = 0x08;` and `sSMBusTarget.nwk.txLen = 9;`?"

case 0x9C://mfr version
sSMBusTarget.nwk.txBuffPtr[0] = 0x08;
sSMBusTarget.nwk.txBuffPtr[1] = 0x02;
sSMBusTarget.nwk.txBuffPtr[2] = 0x03;
sSMBusTarget.nwk.txBuffPtr[3] = 0x04;
sSMBusTarget.nwk.txBuffPtr[4] = 0x05;
sSMBusTarget.nwk.txBuffPtr[5] = 0x06;
sSMBusTarget.nwk.txBuffPtr[6] = 0x07;
sSMBusTarget.nwk.txBuffPtr[7] = 0x08;
sSMBusTarget.nwk.txBuffPtr[8] = 0x09;
sSMBusTarget.nwk.txLen = 9;
break;

This is what I entered during testing,

If you have one of the commands that has block read working, then the issue will be on the command implementation on the target (slave) side.