In the actual application, will encounter the host computer to a single-chip computer to send data, this time need to configure a microcontroller for the slave device, ready to accept data
Turn on event and cache interrupts when using hardware I²c
I2c_itconfig (SLAVER_I2C, I2C_IT_EVT | I2c_it_buf, ENABLE);
Then accept the data in the Interrupt service function
voidSlaver_i2c_ev_irq_handler (void){ Switch(I2c_getlastevent (SLAVER_I2C)) {//ev1:addr=1, cleared by reading SR1 followed by reading SR2 Casei2c_event_slave_receiver_address_matched: {is_data=0; Break; } //ev2:rxne=1, cleared by reading DR register Casei2c_event_slave_byte_received: {if(Is_data = =0) {Is_data=1; Reg_addr=I2c_receivedata (SLAVER_I2C); } Else{is_data=0; Reg_data=I2c_receivedata (SLAVER_I2C); } Break; } //ev4:stopf=1, cleared by reading SR1 Register followed by writing to the CR1 register Casei2c_event_slave_stop_detected: {i2c_cmd (SLAVER_I2C, ENABLE); if(Reg_addr = =0x22) && (Reg_data = =0x47)) Led_d4_toggle; Break; } }}
This code is very simple, processing EV1, EV2 and EV4 can
The logic Analyzer is as follows
This experiment is the goal of this series of STM32-i²c experiments, because the work item requires me to go to the transplant to optimize the previous project, the project needs to configure the I²c slave device. But the original engineer has left the project, the company has no other position with the engineer can ask, had to step-by-step debugging. In the beginning, I did the verification on the Development Board to get the following waveform
When I wrote this blog, the bug was removed and the bug was restored by modifying the I²c interrupt configuration
I2c_itconfig (SLAVER_I2C, i2c_it_evt, ENABLE);
that removes I2c_it_bug.
It's foolish to look at the mistake now, but the whole process of solving the bug is very painful.
1, I write code to the most streamlined, remove useless redundant code, in the beginning of STM32 I²c not very understanding, I simply think that the i²c interrupt divided into the event interrupt and error interrupt, BUF interrupt do not know what to do, it is useless
2, the above experiment is modeled after the actual use of the transmission register address and data to do, but in the past has been to write a data, that is the simplest way to test, the test, the first time the waveform is normal, the second will appear above the lock dead, and if the debug mode is turned on, then accept the data has been normal. Do not know what this causes, resulting in debugging is very difficult
3, I still have a piece of NUCLEO64 Development Board, but the microcontroller model is stm32f303re, and its standard library provides sample engineering code using CPAL, which can not be used to verify whether it is the F1 series hard core i²c itself bug, Online there are STM32 hard core i²c has bugs, many engineers like to use the soft core i²c, just the Wildfire Development Board routine is also a soft core implementation
STM32 accepting data from a pattern