cancel
Showing results for 
Search instead for 
Did you mean: 

How to configure and use the STM32Cube SMBUS/PMBUS stack?

mcoc7n
Associate II

Hello,

I'm using the STM32L475RC as a SMBUS/PMBUS Client and generated the Code with CubeMX.

As smbus/pmbus stack I use the X-CUBE-SMBUS Expansion Package (AN4502).

I've read and studied the examples that come with the package and tried to configure the

stack correctly. However, the stack does not work properly.

For testing the stack I use the tool pmbus_peek.

For example one problem is reading block data. Listing the device capabilities looks like

Inventory Data:

 Manufacturer:        6Company Inc., based on our own Software, ST STM32L475

 Model:              ,Software for our hardware (pmbus, cortex-m4��v

 Revision:             w/20200504:1155, hw/our-h(pmbus, cortex-m4��v

 Built at:             6Company Inc., based on our own Software, ST STM32L475

The original data in the code is

#define MFR_ID "Company Inc., based on our own Software, ST STM32L475R"

#define MFR_MODEL "Software for our hardware (pmbus, cortex-m4)"

#define MFR_REVISION "fw/20200504:1155, hw/our-hw"

It looks like the first byte always corresponds to the number of data bytes in the block, accordingly to the requirements in the smbus specification. Followed by the data bytes.

I think there is something misconfigured.

Does anybody have an idea?

In the appendix of this article you will find a small example that should illustrate the problem.

The example is created with CubeMX.

6 REPLIES 6
Bob S
Principal

You are writing past the end of the stack context's buffer.

return_string:
 
  memset(&pStackContext->Buffer[1], 0, sizeof(pStackContext->Buffer)-1);
  strncpy((char*)(PMBUS_DATA+1), str, tmp);

The memset() line correctly uses the size of the pStackContext->Buffer, but your strncpy uses the string's length, not the buffer's length. And note that the ST SMBUS library only allocates 40 bytes for its buffer. For block read/write messages this gives you the length byte plus 39 characters max. See STACK_NBYTE_SIZE.

Second issue - you are mixing references to pStackContect->Buffer with refereneces to *piobuf (which are hidden in that hiddeous maintenance headache called the PMBUS_DATA macro. So, either use PMBUS_DATA+1 in the memset instead of pStackContext->Buffer[1], and change sizeof(pStackContect->Buffer)-1 to STACK_NBYTE_SIZE-2. Or use pStackContext->Buffer everywhere and ignore the PMBUS_DATA macro (which hides what you are really doing).

mcoc7n
Associate II
And note that the ST SMBUS library only allocates 40 bytes for its buffer. For block read/write messages this gives you the length byte plus 39 characters max. See STACK_NBYTE_SIZE.

The default value of STACK_NBYTE_SIZE is 40 bytes. But I've set STACK_NBYTE_SIZE to 64 bytes so that there should be enough space in the buffer.

Second issue - you are mixing references to pStackContect->Buffer with refereneces to *piobuf (which are hidden in that hiddeous maintenance headache called the PMBUS_DATA macro.

You're right with the mixed references. I've fixed this but there is no change in the behavior. Still the same issues.

In the appendix of this article you will find the fixed example.

Bob S
Principal

Looks reasonable at a quick glance. Have you looked at the stack context structure after you have stored your string there and validated the buffer contents? Trace through the code and see what the PM/SMBus stack does with the buffer while sending. You may have to log data to a buffer instead of breakpointing or adding printf() calls in the interrupt code. Setting a breakpoint will stall the SMBus longer than the 35ms "abort" timeout. Or - do you have a way to monitor the actual I2C bus signals (logic analyzer with I2C decoding?).

mcoc7n
Associate II

Now I've done some more testing and I've monitored the I2C bus signals with an logic analyzer.

The results are in the appendix of this message. You can read the file with the software provided by the manufacurer of the logic analyzer (link is in the zip file).

Bob S
Principal

I'm not going to download and install software just to look at your data. How about some screen shots of the display showing the "interesting" parts. Like one of the messages. Does the data on the I2C bus look like what you would expect? I.e. address/write, command code, restart, address/read, byte count, the data bytes (for SMBus Block Read, which is how the PMBus strings are sent).

Ffasf.1
Associate

I also want to configure the device with my Pc. I have read some guidance article regarding this but need some solution.