[DONE] I2C driver for STM32F0

[MartinP]

Ad ISR: I just noted that after a transmission some of the remaining IF statements became true and the driver ran into a timeout and the status became locked --> game Over

Of course this can be on my side somewhere as it might be possible that I did not merge all necessary changes you made (I do not know the reference manual by heart)

Martin

[MartinP]

Giovanni,

I've stripped out all changes from my side except the DMA related fixes ported from V1.
my tests with a stm32f3 discovery worked fine. The stm32f051 discovery I can test this evening but I feel confident.
I have attached the files and hope it will save some of your time ...

Martin

[Giovanni]

Hi Martin,

Thanks, very appreciated, I will give it a try in the evening.

Giovanni

[Giovanni]

Hi,

I tested the modifications, now the driver seems to work but there is still a problem somewhere. Try the test application under ./testhal/STM32F37x/I2C, you can easily adapt it to the F0xx or the F3xx.

This is the relevant code (it reads from a small I2C memory):

Code: Select all

  /*
   * Normal main() thread activity, in this demo it does nothing.
   */
  while (TRUE) {
    unsigned i;
    msg_t msg;
    static const uint8_t cmd[] = {0, 0};
    uint8_t data[16];

    msg = i2cMasterTransmitTimeout(&I2CD2, 0x52, cmd, sizeof(cmd),
                                   data, sizeof(data), TIME_INFINITE);
    if (msg != RDY_OK)
      palTogglePad(GPIOC, GPIOC_LED3);
    for (i = 0; i < 256; i++) {
      chThdSleepMilliseconds(2);
      msg = i2cMasterReceiveTimeout(&I2CD2, 0x52,
                                    data, sizeof(data), TIME_INFINITE);
      if (msg != RDY_OK)
        palTogglePad(GPIOC, GPIOC_LED3);
    }
    chThdSleepMilliseconds(500);
    palTogglePad(GPIOC, GPIOC_LED2);
  }

It works perfectly but if I remove that chThdSleepMilliseconds(2) then it hangs after few seconds, it is like it does not like repeated operations. When it hangs the ISR register contains BUSY=1 and the function does not return because no interrupt is ever triggered.

Enabling timeout would probably unlock it but not explain the behavior, I don't consider it a solution.

Giovanni

[Giovanni]

Hi,

Fixed that last problem as well, now the driver is very stable, thanks for all those who helped.

Giovanni

[goeck]

Awesome. Thanks for the motion going on here, will try the new driver. I like it!

[steved]

Been trying to track down an unhandled exception on this new code, and found a couple of things:

1. In the stm32f0 dma driver, the DMA ISRs are defined as function names, apparently with no define to link them with 'Vector64', 'Vector68' and 'Vector6C'. This was the cause of my exception.

I suspect this has crept in due to some other change, since this code used to work!


2. I am receiving single bytes, and if debug is enabled, line 615 of the stm32/I2CV2/i2c_lld.c has:

chDbgCheck((rxbytes > 1), "i2c_lld_master_receive_timeout");

Changing '1' to '0' fixed that.


Only done a quick check, but looking good again.

I'll raise a ticket later if necessary.

[Giovanni]

Hi,

Thanks, let me know.

Giovanni

[MartinP]

The missing Vectors for the stm32f0xx I already mentioned here: http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=822&start=20#p9983

didn't follow up as I thougt it was fixed. Sorry for that.


Martin

[steved]

Given things a better test - works with both short and long data transfers, and on two different sets of hardware (Discovery and board of my own build), and with three different devices (DS2483, FM24V02, DS1340). All looks good to me.

Also discovered that the ADC driver is suffering from lack of defined interrupt vectors.