I2C implementation for STM32

[barthess]

Please, post your code here.
What synchronization mechanism you use for mutual exclusion?

ADD:
Hmm... looks like interrupt in the middle of i2cMasterStop() function cause
this hang up. I have add some locks in driver code. Try to update code
of branch.

Offtopic: where you bought that amazing sensors?

[zyp]

Update didn't change anything.

I posted relevant parts of my code here.
I'm not using any synchronization mechanisms yet, I'm only starting a single read in the main thread so there is no chance of collision.

(As for the sensors, I have one of these.)

[barthess]

Where your system locks up? Look with debugger.
Are you use some sleep cycles in main loop?
Insert breakpoint inside i2c_lld_master_stop() and run program. Are your program reach this function at all?
Try to set "CH_USE_NESTED_LOCKS TRUE" in chconf.h

[zyp]

If I had a debugger, I'd done that already, but I'm still waiting for the JTAG-interface I ordered. I'm just uploading through the serial bootloader at the moment.

CH_USE_NESTED_LOCKS made no difference.

Main loop is just:

Code: Select all

while (1) {
  chThdSleepMilliseconds(1000);
}

From what I can see by turning on and off LEDs at strategic places, the error callback is called after the receive instead of the normal callback.

Can you explain what might trigger the error callback? How do you recover from such a situation?

[barthess]

In error callback program jump from error interrupt handler. To investigate, what is wrong - you must look at status register SR1.

Code: Select all

  int status = 0;
  status = i2cp->id_i2c->SR1;

But I do not know how to do that without JTAG.

[zyp]

I found the problem.

In order to generate the Stop/Re-Start condition, software must set the STOP/START bit just after reading the second last data byte (after the second last RxNE event).

(Doc ID 13902 Rev 11, page 711)

I modified i2c_lld_rxbyte to set the STOP bit at the same time as un-setting the ACK bit, and removed the call to i2cMasterStop from my callback.

Code: Select all

--- a/os/hal/platforms/STM32/i2c_lld.c
+++ b/os/hal/platforms/STM32/i2c_lld.c
@@ -89,7 +89,7 @@ inline bool_t i2c_lld_rxbyte(I2CDriver *i2cp) {
     _rxbuf[_rxbufhead] = i2cp->id_i2c->DR;
     if ((_rxbytes - _rxbufhead) <= 2){
       // clear ACK bit for automatically send NACK
-      i2cp->id_i2c->CR1 &= (~I2C_CR1_ACK);
+      i2cp->id_i2c->CR1 = (i2cp->id_i2c->CR1 & (~I2C_CR1_ACK)) | I2C_CR1_STOP;
     }
     (_rxbufhead)++;
     return(FALSE);

The result is a scope trace looking like this:

The error callback is not entered now, and the system continues to run fine.

[barthess]

Obviously, that is my error. But most interesting question - why my accelerometer works fine with that error?

[zyp]

I guess what you're doing results in unspecified behavior, which may vary between manufacturers and devices.

My workaround apparently broke your state machine, and I now have to work around that again by manually resetting it to I2C_READY before next reading.

[Dave_fr]

Hi,

After looking at the previous posts regarding the issues you are having with I2C and stm32 I was wondering wether it would be easy, at that point in time, to hook up a wii motion plus gyro to my stm32f103 board ?
I'd rather ask you, the specialists, I'm hesitating between spending time fiddle around the wii motion plus I2C interface or buying more expessive but simpler digital gyros.

Best regards,

Dave

[Giovanni]

The I2C driver is still under development, we have to wait a status update from barthess. At this point its use would be up to you, the driver is still not officially part of the OS.

Giovanni