STM32G4: I2C in SMBus mode Supports DMA?

[TwelveSquared]

STM32G474CE: Is it possible to use I2C2 in SMBus 2-wire mode with DMA? Asking because CubeMX (with STM32CubeFW_G4 1.4.0) does not show the "DMA Settings" tab if I2C2 is set to "SMBus-two-wire-interface." Bug in CubeG4 or hardware limitation?

[TwelveSquared]

Ping... does anyone know the answer to this question?

[Khouloud ZEMMELI]

Hello @TwelveSquared​ ,

Thank you for raising the question and sorry for the delay,

In fact, this's not an issue, SMBus mode does not support DMA not only for G4, but for the other series too.

For that reason, you cannot configure it through CubeMX.

Thanks for your contribution,

Khouloud

[TwelveSquared]

Hello @Khouloud ZEMMELI​  Thank you for your response. Perhaps the Datasheet or Reference Manual could be made more clear on this point.

[Bob S]

Is there a specific reason you want to be able to use DMA with SMBus?

I do not think it is a limitation of the hardware. It is more an issue with the SMBus code *AND* the SMBus spec. Unlike normal I2C transfers, SMBus requires the receiving device to make decisions on how to response as each byte is received (well, as the first couple of bytes are received). That does not lend itself to using DMA. I guess it would be possible to use interrupts up through the "command" byte and the possible restart/repeated address byte and then DMA for the data portion. But data portions can be variable length, so, again, perhaps DMA is more complicated than interrupt (do-able, but more complicated).

SMBus is "slow" compared to the G4's possible clock rates. So interrupts shouldn't over-burden the CPU. I've got designed with 2 ea I2C ports and 2 ea SMBus ports on a G474 running at 96MHz with no performance issues.

[TwelveSquared]

Hi @Bob S​ , thanks for your response. That is quite helpful. I am currently designing a board where the MCU will be talking to some ICs via SMBus because that is the interface offered by those ICs, and I am rather a SMBus n00b right now, so I'm having a crash course right now. Your question/explanation has made it clear why DMA is not applicable here. Thanks for that! I'll go ahead and use the interrupts instead. Just to answer your question, the reason I wanted to use DMA is simply that I do as much as possible with DMA. Not only does it take burden away from the CPU but I've also found that on many different MCUs from various vendors, various errata related to communication peripherals are not applicable when using DMA. Not saying there are any such errata on the G474 but that's one more thing in favor of DMA when available. Thanks for your input.

[Singh.Harjit]

Just looked at the reference manual for the STM32G474, RM0440 Rev 6 I2C section, I think DMA should work with SMBus. The transmit/receive block seems to generate a DMA request for transmit or receive and it doesn't seem to be qualified by I2C or SMBus - or at least I couldn't find it.

If you look at section 41.4.17 on page 1909, it say:

For instances supporting SMBus: the PEC transfer is managed with NBYTES counter.

Refer to SMBus slave transmitter on page 1900 and SMBus master transmitter on

page 1903.

Page 1910 says:

If SMBus is supported (see Section 41.3: I2C implementation): the PEC transfer is

managed with the NBYTES counter. Refer to SMBus Slave receiver on page 1901 and

SMBus master receiver on page 1905.

[TwelveSquared]

Hello @Singh.Harjit​ , thanks for your reply.

I saw that exact same section of the Reference Manual, but I think it is written in a confusing way. From my interpretation, it is not saying that these I2C support DMA in SMBus mode; rather it is only saying that I2C IP blocks that happen to have SMBus support have this PEC/NBYTES, as opposed to I2C IP blocks that don't have SMBus support; in other words, I think they are not saying that DMA works with SMBus, rather, they are only making a statement about IP blocks that have the SMBus IP incorporated in them. I don't know if my interpretation is correct here. It's confusing. Maybe a ST employee with more knowledge can help us understand.