Hi Alan, Cameron,
We are currently using the TMS320F28027 device for some of our designs but are stuck on a few points when it comes to requiring this device to act as a PMBus slave device. We had thought the F238027 I2C module's Free Data Format mode would allow us to circumvent some of these issues but have found that it is a known problem that this feature does not operate as expected.
There are two main problems we face:
- Firstly, that we cannot find a work around to allow the device to answer to more than one address (aside from the general broadcast address). The PMBus specification requires that a slave device answer on it's own address, but also on an SMBus Alert Response address (0Ch), the SMBus Device Default Address (61h) used by the SMBus Address Resolution Protocol and recently also on the ZONE_READ (28h) and ZONE_WRITE (55h) addresses.
We have looked at few other options within the TI portfolio to overcome this issue and see that some of the MSP430 devices offer either multiple address functionality, or a serial peripheral simple enough that it does not automatically. Also of benefit on some of these devices is that the newer one's have internal FRAM which is of interest for other aspects of our design. The method used to allow multiple addresses, that is an address mask register, is not completely ideal as reading and checking addresses that are irrelevant but that still fit a mask that allows the aforementioned addresses introduces some overhead.
- Secondly data arbitration (i.e. arbitration that continues past the address) is needed. For example, the SMBus Alert Response (SMBus v3.0 Appendix A.2) protocol requires not only that all slaves that are alerting should respond to the SMBus Alert Response address with their own address, but that they should all do so during the same bus data bytes and that the slave who's address actually wins data arbitration should release it's ALERT line.
It's this last portion that causes the issue as it means the slave device needs to be able to ascertain if the data it has sent is the data that actually appeared on the bus. For this we currently hope to design some external circuitry that may allow data arbitration - but only in exchange for more GPIO pins, external interrupt pins and added code overhead.
Does TI currently have any implementation or workaround that avoids these issues?
If not, are there any planned future products that will overcome them?
Many thanks, Toby.
