Stm32 I2C difficulties

I2C bus is widely used in all embedded systems and is an industrial-level bus. However, because stm32 is a 32-bit MCU, it is doomed that its I2C hardware interface will be powerful, but it will also be difficult to control, unlike 8-bit machines, such as avr8-bit Twi (actually fully compliant with I2C standards) so easy to use. the following are some of my experiences in programming stm32 I2C hardware interfaces.

If you select stm32, it means that the requirements of your project are complex. Using embedded OS and a large number of programming models using interrupt + DMA are inevitable, if you use stm32 in your project, and you use analog I2C, it indicates two points: one is a waste of stm32; the other is that if your project is very complex, you will find that at the end of the project development, it seems that the stm32 is not much faster than the 8-bit machine, why !! But this is not a problem with stm32, but you are not using the kernel most effectively.

Many of my friends are always "somewhere" when programming on the I2C interface of stm32 (you will find this problem common at Google ), some friends will use software to simulate I2C at this moment, and then they will soon find that they can communicate well with I2C devices (but the machines may still appear randomly ), these friends yelled at stm32's I2C hardware interface as a "Cup" (haha, sometimes I suddenly want to scold, But I know, the reason for 99.999% is that I am not familiar with the stm32 hardware interface, or I am not raising the length of stm32 I2C, but always catch his short hair .).

Of course, stm32 I2C hardware interfaces are not well designed. For example, the following is what I have summarized from the latest errata sheet of stm32, recommended program model for design defects of stm32 I2C interface and how to avoid these defects:

(1) Raise I2C interrupt priority to the highest

(2) encapsulate the sending and receiving of more than two bytes into a function that uses DMA for sending and receiving, the function that receives and sends one byte to an I2C device is separately encapsulated into a polling function.

(3) when addressing an I2C device, check whether the I2C bus is busy. If busy, wait for the specified time, if it is still busy, it means that the I2C bus is down (because 99.9% is because our I2C communication timing is not very strict with the I2C protocol, or the encapsulated I2C communication module does not contain the Defense Code (error recovery Code). In this case, we need to call a dedicated device to notify all devices on the I2C bus, let them end their current internal work and get ready again (it's raining, it's time to accept your clothes ). The fun slice of my I2C module is as follows:

This function must be used on the startup module of the main MCU, because when the I2C bus acts as the MCU of the master, the SDA and SCL may combine timing combinations that match the I2C specification, for example, a start condition causes I2C bus to be immediately there (because when the main MCU really needs to issue a start condition, it is found that I2C bus is in the bus state, according to the start condition instructions in the stm32 manual, a starting condition will make the I2C bus in the busy state. The basic usage of i2c2_free_buf fun below:

(Note: i2c2_free_bus fun should be placed in the thread rather than in the position, which will trigger and enter a hardware error processing vector interrupt)

Tip: From stm32 manual:
I2C. sr1.bit 0-bit (SB)-start bit (master mode)
-Set when a start condition generated.
-Cleared by software by reading the SR1 register followed by writing the Dr register, or by hardware when PE = 0.

(4) do not let I2C work at a 400 kHz frequency, lower than or use a fast-mode (99.999% kHz) frequency. This is a real hardware bug (probability) of stm32 I2C ), but it can also be avoided by programming.

(5) programming the bit nostretch = 0 in the i2c_cr1 register. This also avoids a small bug (2) designed by stm32 I2C hardware. 9. Section 5)

(6) The working mode of most MCU hardware I2C interfaces is interrupt (high-end MCU will use DMA) + state machine; therefore, the concept of state machine programming should be familiar

(7) The hardware interface of stm32 I2C is responsible for implementing the I2C bus protocol, while we (embedded programming developers) Start the state machine through the combination of I2C control registers and I2C event signs, then let the state machine automatically work according to the events that are combined by I2C SR1 and Sr2, and notify the read/write functions written by us by means of flag or semaphores after the sending or receiving is complete, the operation has been completed, or an error has occurred in the operation, such as the most common af error (the device did not pull down the SDA to respond to the master on the 9th bit .)

(8) function allocation of I2C SR1 and Sr2 (this is an easy to ignore)

From the I2C register map in the stm32 manual, we can see that the SR1 of I2C mainly reflects the most basic identifier of I2C communication. to clear a specific Identifier of SR1, you can directly clear it, while I2C Sr2 is secondary SR1, which generally reflects the current working status of I2C, such as busy, host mode or slave mode. An important programming model for Sr2 is that when you want to clear some specified flag bits of SR1, such as ADDR, read SR1 first and then read Sr2, the ADDR with the specified position will be cleared.

(9) When operating the slave device, the master must first hold his hand with him. This is a good defensive programming model: