I2C implementation for STM32

[barthess]

I have attached my halconf.h mcuconf.h and chconf.h (configs.zip).
Compilation options: -O0 -ggdb -fomit-frame-pointer -falign-functions=16 -Wall -Wextra
Kernel: 2.3.4unstable
Gcc: 4.5.2 (Sourcery G++ Lite 2011.03-42)
OpenOCD: 0.5.0-dev-00949-gac43d7a-dirty (built myself)

Can I provide usable information anymore?

[Giovanni]

Found the problem, you do:

NVICEnableVector(I2C1_EV_IRQn, STM32_I2C_I2C1_IRQ_PRIORITY);

instead of:

NVICEnableVector(I2C1_EV_IRQn, CORTEX_PRIORITY_MASK(STM32_I2C_I2C1_IRQ_PRIORITY));

The function NVICEnableVector() takes as parameter a priority mask not a priority level. Thant way you are setting priority 0 which is above kernel priority, this caused the crashes.
The simplified kernel mode didn't crash because it always masks all interrupts.

Giovanni

[barthess]

Hi, Giovanni.
You are right, that was the the reason of bugs. Now driver successfully works simultaneously with IRQ storm test.
There is only one blocking in ISR now. Approximately 3 uS in read-through-write routine.
Tested callbacks, waiting and mutual exclusion.

[Badger]

I'm happy to report that all my problems have gone away with the latest i2c driver

One thing that doesn't seem possible is to call i2cReleaseBus() from within the callback function. I think this is because the callback is not within the same thread as the thread which called i2cAcquireBus(), so the mutex doesn't work, but is there any way around this? it doesn't seem a neat implementation if we have to either call i2cReleaseBus() immediately after issuing the transaction, which will release it before the transaction is complete if I2C_USE_WAIT is FALSE

otherwise I am very happy to have it all working well, good work!

[barthess]

Badger,
If you want to call i2cReleaseBus() from within the callback, than you must disable mutexes and allow semaphores in chconf.h. But I think that better to use mutexes with I2C_USE_WAIT set to TRUE, and call i2cReleaseBus() just after transfer call.

[Giovanni]

Note that from callbacks you can only invoke I-Class APIs, if you call i2cReleaseBus() the system will crash randomly. As barthess wrote, mutexes don't have I-Class variants at all because their nature.

You may use (after disabling mutexes):

chSysLockFromIsr();
chSemSignal(&i2cp->id_semaphore);
chSysUnlockFromIsr();

Giovanni

[barthess]

Badger,
If you read-through-write exactly two bytes somewhere in your code, than update driver to rev. 3150.

[barthess]

Hi all.
Driver successfully work in case of concurrent access to bmp085, lis3lv02 via I2C1 and tmp75, max1236 via I2C2 and IRQ_storm test in background (pass 100 iterations).

I finished writing the documentation to driver, but have one issue. When I run doxygen it includes not my "os\hal\platforms\STM32\i2c_lld.h"
but "os\hal\templates\i2c_lld.h". I do not know how to fix that.

Does anybody have suggestions about API improvements? May be not only API?

[Giovanni]

The doxygen file does not include low level implementations because the document would become huge and the structures defined in the various HALs would conflict (old doxygen bug).

LLDs are only included into the HAL manuals so don't worry about this.

It seems the implementation is robust now, personally I am more concerned about the high level API, I wish more feedback about that.

Giovanni

[barthess]

Rev. 3157
Stability improvements in hi loads. Side effect: added small blocking pollings after a stop bit setting.

Instability has been detected when I add IRQ storm test to my real application.