{"id":4299,"date":"2020-12-16T06:17:42","date_gmt":"2020-12-16T06:17:42","guid":{"rendered":"http:\/\/fastbitlab.com\/?p=4299"},"modified":"2023-09-06T16:00:21","modified_gmt":"2023-09-06T10:30:21","slug":"stm32-i2c-lecture-28-exercise-testing","status":"publish","type":"post","link":"https:\/\/fastbitlab.com\/blog\/stm32-i2c-lecture-28-exercise-testing\/","title":{"rendered":"STM32 I2C Lecture 28 -Exercise: Testing"},"content":{"rendered":"
\n
\n
\n
\n

 <\/p>\n<\/div>\n

\n

Exercise: Testing<\/span><\/h1>\n
\n
\n
\n

 <\/p>\n

<\/div>\n

 <\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n<\/div>\n

The I2C trace in Figure 1 is not good because it has some problems. There is a glitch (Figure 2) after every packet transaction. <\/span><\/p>\n

\"Testing
Figure 1. I2C trace for the master to slave communication.<\/span><\/figcaption><\/figure>\n

 <\/p>\n

\"Testing
Figure 2. Glitch after every packet transaction.<\/span><\/figcaption><\/figure>\n

 <\/p>\n

The byte transmission ends at the 8th clock cycle, and 8-bits are transferred. After the 8th clock cycle, there is an ACK. But look at Figure 2. After the ACK, there is a small glitch, which is not good. The glitch is not affecting our expected behavior because the data is being received properly from the slave. Even though the data reception is fine, the glitch should not occur. <\/span><\/p>\n

Now investigate the reason that causes the glitch to occur. This glitch is happening after every byte transfer, which means the SDA line is pulled to high, and then it is released, and the duration is approximately 125 nanoseconds.<\/span><\/p>\n

 <\/p>\n

Steps to investigate the reason for glitch:<\/b><\/span><\/p>\n