2018-03-19 11:39 AM
Hello,
I am reporting a hardware bug with the I2C peripheral in the newer STM32 families (STM32F7, STM32H7, STM32L0, STM32L4, and STM32L4+ familes) in I2C multi-master mode (including many SMBus host applications), and a few possible workarounds. The STM32F1, STM32F2, STM32F4, and STM32L1 families are unaffected because they have an older I2C peripheral with its own flaws (like not being able to acknowledge its own address if it lost arbitration during that address).
I reported it to ST's technical support Dec 19, 2017 and they have still not confirmed a final workaround, so
ST has confirmed today (Apr 5, 2018) this is a hardware bug and is in the process of updating the family errata sheets. I'm sharing with the community in the hopes of saving someone else the trouble I went through.Most people using the I2C will NOT be affected by this bug. It affects I2C multimaster mode, and in particular with DMA optimized transfers which is unfortunately the lowest power and most CPU efficient way of using the STM32. An example application would be an SMBus host.
The issue is that setting the START bit to request a new master transmission becomes latched into the hardware peripheral during a bus collision where itself is addressed and the peripheral changes to slave receiver to receive a message, and it cannot be aborted! Immediately after the STOP condition is detected, the I2C peripheral will try to send a START + address (which will likely be incorrect), even if the START bit is cleared by setting the ADDRCF bit.
There is no way to abort this transfer without resetting the peripheral.
See workarounds below.The reference manual for the STM32L4 series RM0394 on p.1037 and p.1071 indicates that setting the ADDRCF will clear the START bit that is pending. This does clear the START bit, but does NOT clear the pending START request in the hardware peripheral. The documentation needs to be updated to make that clear.
Steps to reproduce
I have attached a demo project that reproduces this bug, but here is a more verbose explanation:
Workarounds
There are four possible workarounds. If you're reading this far, you're probably affected by the bug and hoping for an easy fix. Good luck with that. Here are the workarounds I have discovered so far:
Demo Project to Reproduce
I have attached a project that can be run easily on a Nucleo development board if you feel like recreating this issue or characterizing your own firmware's susceptibility to this bug.
Nucleo Connections
I am using a Nucleo-64 board with a STM32L443RC swapped, and configured for MCO:
In order to connect the I2C1 and I2C2 ports together, the following jumpers must be added:
Connect logic analyzer to decode debug output on SPI:
Logic Analyzer Capture
See attached screenshot (001_Pending_START_ADDR.png) for an illustration of the problem.
Solved! Go to Solution.
2018-04-05 10:08 AM
The hardware bug was confirmed by ST today, so I am considering this thread answered.
2018-04-05 10:08 AM
The hardware bug was confirmed by ST today, so I am considering this thread answered.