ChibiOS Free Embedded RTOS

Hello Everyone,

I was playing around with my custom board and ChibiOS since that OS is everything I ever wanted from RTOS. First thing I was trying to run is I2C communication since I've got bunch of devices attached to that interface. And it wasn't working. The I2C HAL driver seamed to stop (hang) on reading, not receiving any "useful" event in i2c_lld_serve_event_interrupt().

Since I2C implementation in STM32, especially the F1 series, had a really bad reputation as far as my field of interests goes (namely UAV, so a lot of I2C communication to sensors), I went on to investigate, looking for other implementations of I2C driver for STM32, and the most convoluted one found in OpenPilot, had a workaround for probably every single strange event they got on I2C ISR handler, half of them leading to transaction repeat. And they are not using DMA...

There was something strange with that and as I'm a kind of person that reads Reference Manual, I found a lot of warnings in STM32F4 RM about ADDR flag that is reset on read of SR2. The same kind of warnings show up in RM for STM32F1. The funny thing is that, according to manual, controlling the resetting of ADDR flag is required for properly handling SR1_ADDR and SR1_ADD10 flags in ISR, and ADDR flag is cleared automatically after reading SR2 after reading SR1. And every single implementation I saw (including the one in ChibiOS and the STM32 peripheral library) uses so called "event" made up of SR1 and SR2 to define the state. And the event is constructed by reading SR1 and SR2 in sequence, which clears ADDR flag before properly configuring transfer (ie. clearing CR2_ITEVTEN and enabling DMA).

The workaround was to just read SR2 before reading SR1 - ADDR was not cleared and it was possible to clear ADDR after transfer is properly setup (enabled DMA stream).

The other problem with ChibiOS I2C driver that I found reading RM is clearing of CR1_ACK flag and setting of CR1_POS flag depending on the size of transaction. Namely I2C on STM32F4 (and F1 AFAIK) requires that for receiving of 2 or less bytes to clear ACK bit in CR1, and when receiving excacly 2 bytes to set POS flag in CR1.

After applying above modifications to I2C HAL driver in ChibiOS I was able to run I2C transactions one after another for a whole week with a speed of 300kHz (I have too strong pull-ups, need to resolder them ) with no hang nor lockup nor error.

See the attached patch for making I2C reliable on STM32F4.

Hi,

Thanks for the analysis and the patch, the I2C driver has been one of the most troublesome for us too. That cell has a bad reputation for a good reason IMO, they changed it starting from the F0 devices but we don't have a driver for that one yet.

Barthess could you give a try to this patch?

Giovanni

Sure.
Update:
It looks workable for first look. Tomorrow I will run some stress tests.
Update2:
Tests passed fine. Patch merged to trunk (rev.4497).

ahaczewski, could you provide your code causing problems?

Thanks Barthess,

I also am curious about how the previous implementation failed.

Barthess, do you think the timeout handling is really useful or it is just making the driver more complex? I am considering removing the related code.

Giovanni

AFAIR it was just simple while loop doing I2C transactions with infinite timeout. I have a scope and was able to look at the data exchange and after first transmission (register address, one byte) to device both I2C line lines were low, and BUSY flag was set in uC. Because I've set no timeout, no other transmission was possible.

That was using 300kHz clock.

Going down to like 88kHz (since you can't use 100kHz with STM32F4 as per errata ) I was able to do 2 transactions, one byte out with device register address and then get data from that register, and then again both lines were stuck low and BUSY flag was set and no sign of life was given out of I2C cell. This gave me a hint that there might be some sort of race going on and reading RM I had a feeling that resetting that ADDR and proper setting of ACK and POS flags was the right thing to do: POS sounds very much like POStpone, like that NACK which should be generated due to ACK being reset was postponed for one byte, that's why they ask you to set POS and reset ACK for 2-byte reception, just like they ask to reset ACK before starting 1-byte reception because I2C has to know in advance to generate NACK after that byte is clocked out... but that is my wild guess; the other guess with ADDR is that once ADDR is reset, I2C cell might generate a DMA request, and since DMA was enabled after ADDR being reset, there MIGHT be a race between enabling DMA and I2C generating request... that was the other guess.

While I was debugging I also added a thread that was logging I2C events (those (SR2 << 16) | SR1 events) that got to ISR, and except those already served there I was getting a lot of strange ones, which were not supposed to be there (according to RM). After patch there is no "spurious" events except one that looked harmful, ie. it worked anyway . I should be able to get that logs for you also.

Note that is on a custom board made by me, so it MIGHT be a problem with the hardware, but it would be strange that it was fixed by such a patch...

I'll try to get a test code when I get some time at home (kids and wife, you know...). I have the code in repo so what I need to do is find that damned revision...

PS. I was fixing that like a month ago, but then had no time to go back to ChibiOS and provide the proper patch until now. So excuse me that it comes with no test case nor any logs or scope snapshots but my plain explanations, I'll try to get better materials as soon as possible.

@ ahaczewski
Thanks for explanation. It would be very useful to have sources.

@Giovanni
Timeout handling is useful in case of some device pulled line down and died. This is typically no ChibiOS problems. For example "double reset problem" with OpenOCD in my case cause EEPROM IC to pull SDA line down locking all bus. This situation can be solved only by powering down whole (because we can not determine problematic IC) bunch of I2C devices using external MOSFET. That hardware solution is unacceptable in most cases. On the other hand, user can realize himself timeout using VT and power switch.
My suggestion to postpone removing of timeout functionality to time when config generator will be ready enough to create timing constants for I2C. I have vocation since Monday, so I can spend more time to testing of conf generator in parallel of developing my auto(driver/pilot). What your near development plans?

Hi Barthess,

The Eclipse plugin is almost done, the procedure is much simplified compared to the manual method you tested. It works this way:

1) A wizard allows to create a "configuration project" composed of two files: xxx.chcfg and xxx.chxml. The .chcfg is the configuration settings file, the .chxml the data to be edited with the XML editor.
2) When a .chcfg file is selected in the project explorer a menu appears in Eclipse and a button in the toolbar.
3) When the button is clicked the associated .chxml file is processed and the output files generated in the pre-defined location.

For example I can open the .chxml of the STM32F4-Discovery board, change the board settings, click the .chcfg and the board.* files are immediately regenerated already in the correct position. The project can then be immediately recompiled with the new board settings.

I plan to make "templates" for:
1) Other the board files types (now it is for the F4 only).
2) chconf.h, halconf.h and mcuconf.h (various platforms).
3) HAL and ADC drivers (and others having time...).
4) Whole application projects templates.

Of course the effort is not small but I believe it will be a huge plus for ChibiOS users and developers.

Giovanni

I've been following the discussion with a little bit of interest, as I had a problem with the I2C support a few months back. Just coincidentally, I happened across an app note http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00209826.pdf entitled "STM32F10xxx I2C optimized examples".

I'm not sure if it covers any new ground, contradicts or confirms what you've seen, but I thought I'd bring it your attention if you hadn't seen it before. It also addresses I2C slave mode examples as well.

Hi,

will this fix also solve the read only 1 byte via DMA issue?
(see http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=25&start=240#p1830 from barthess

regards

Martin

No, it will not.