Posted on March 05, 2013 at 13:49
Yes, the PC sends the data as Master and the STM32 is the Slave.
I already figured out what is that zero byte, it is the data address (that I don't really need, but that seems to be necesary for the command).
But I still don't know why the device doesn't understand the transaction.
The command line I am using is:
i2cset -y 0 5 0 0x35
where i2cset is one of the linux i2c-tools
-y is to skip confirmation
0 is the i2c bus
5 is the address of the STM32 (it shifts the 0x0A to 0x05, I think it is because it doesn't count the read/write bit of the address)
0 is the data address -> that is the zero byte I didn't understand
0x35 is the data to write
After launching the command both lines SCL and SDA go down. And thelastevent = I2C_GetLastEvent(I2C1); in the interrupt routine gets continiusly
the value0x20044 (RxNE and STOPF bits set in SR1)
When I pause the execution SCL and SDA go high again.
Could it be a timing problem? maybe the STM32 is too fast?
The device I am using is the stm32f417
void I2C1_EV_IRQHandler(){
uint32_t lastevent;
lastevent = I2C_GetLastEvent(I2C1);
switch(lastevent){
case I2C_EVENT_SLAVE_RECEIVER_ADDRESS_MATCHED:
STM_EVAL_LEDToggle(LED1);
I2C_CleanADDR();
break;
case I2C_EVENT_SLAVE_BYTE_RECEIVED:
(void) I2C1->SR1;
received_data = I2C_ReceiveData(I2C1);
WRITE_flag = 1;
STM_EVAL_LEDToggle(LED2);
break;
case I2C_EVENT_SLAVE_STOP_DETECTED:
STM_EVAL_LEDToggle(LED3);
I2C_CleanSTOPF();
break;
default:
STM_EVAL_LEDToggle(LED4); // it gets here continiusly with lastevent = 0x20044
}
}
inline void I2C_CleanADDR(void)
{
while ((I2C1->SR1 & I2C_SR1_ADDR) == I2C_SR1_ADDR)
{
(void)I2C1->SR1;
(void)I2C1->SR2;
}
}
inline void I2C_CleanSTOPF(void)
{
while ((I2C1->SR1&I2C_SR1_STOPF) == I2C_SR1_STOPF)
{
(void)I2C1->SR1;
I2C1->CR1 |= 0x1;
}
}
#i2c-signal
