dwvcfii@yahoo.com [nuttx]
2015-12-30 15:56:42 UTC
I'm working with the F3 discovery board (STM32F303VC) and am presently trying to get I2C working on it.
Unfortunately, it appears that in its infinite wisdom, ST made the register map slightly different between the F1,F2,F4 vs. the F3. Hence the reason nuttx has separate drivers for these devices.
I have also noticed that we have two different drivers for the F1/F2/F4, "stm32_i2c.c" and "stm32_i2c_alt.c". It would appear that the alt driver is a newer / tweaked version of the other driver, but as the Kconfig description implies it's not sufficiently tested on other platforms to justify inclusion as the primary driver. Fine.
I spent the last couple of days learning the F3 I2C peripheral and stepping through the existing F3 driver (stm32f3xxx_i2c.c), particularly the ISR, and it's painfully clear this is an unfinished work. The reads / writes work in the context that they produce:
[Start/Address][Subaddress][Restart/Address][Data]
on the wire and don't hang the device, but my slave devices do not tolerate / respond to restarts on writes...they expect:
[Start/Address][Subaddress][Data]
....so I went down the rabbit hole of attempting to activate the no-restart flag (which the I2CTool does not, coincidently). Long story short: this results in a trace overflow because the ISR state machine is not correctly handling the state of the device, it gets stuck and just keeps looping doing nothing useful until the trace buffer overflows.
While debugging I noticed a few other undesirable properties, including simple stuff like the local / private copy of the status register not being updated at the top of the ISR, so the state of the device was always in question. Not surprisingly, upon reviewing the stm32_i2c_alt.c driver I found this was properly done. And further review of the ISR in that driver reveals that it's MUCH better written. Long story short, the F3 driver ISR is incomplete and broken in some cases.
I'm not sure of the chronology here exactly (I'm being lazy), but my guess is the F3 driver was forked from the primary stm32_i2c driver some time ago and then someone came along and revamped the ISR in the primary / alt driver, because while there are many similarities between the drivers, the ISRs are completely different.
So I'm considering integrating the alt driver ISR with the existing F3 driver, with the intent to publish the final result.
Anyone have any objections / concerns about this path? Greg -- what do you think?
Unfortunately, it appears that in its infinite wisdom, ST made the register map slightly different between the F1,F2,F4 vs. the F3. Hence the reason nuttx has separate drivers for these devices.
I have also noticed that we have two different drivers for the F1/F2/F4, "stm32_i2c.c" and "stm32_i2c_alt.c". It would appear that the alt driver is a newer / tweaked version of the other driver, but as the Kconfig description implies it's not sufficiently tested on other platforms to justify inclusion as the primary driver. Fine.
I spent the last couple of days learning the F3 I2C peripheral and stepping through the existing F3 driver (stm32f3xxx_i2c.c), particularly the ISR, and it's painfully clear this is an unfinished work. The reads / writes work in the context that they produce:
[Start/Address][Subaddress][Restart/Address][Data]
on the wire and don't hang the device, but my slave devices do not tolerate / respond to restarts on writes...they expect:
[Start/Address][Subaddress][Data]
....so I went down the rabbit hole of attempting to activate the no-restart flag (which the I2CTool does not, coincidently). Long story short: this results in a trace overflow because the ISR state machine is not correctly handling the state of the device, it gets stuck and just keeps looping doing nothing useful until the trace buffer overflows.
While debugging I noticed a few other undesirable properties, including simple stuff like the local / private copy of the status register not being updated at the top of the ISR, so the state of the device was always in question. Not surprisingly, upon reviewing the stm32_i2c_alt.c driver I found this was properly done. And further review of the ISR in that driver reveals that it's MUCH better written. Long story short, the F3 driver ISR is incomplete and broken in some cases.
I'm not sure of the chronology here exactly (I'm being lazy), but my guess is the F3 driver was forked from the primary stm32_i2c driver some time ago and then someone came along and revamped the ISR in the primary / alt driver, because while there are many similarities between the drivers, the ISRs are completely different.
So I'm considering integrating the alt driver ISR with the existing F3 driver, with the intent to publish the final result.
Anyone have any objections / concerns about this path? Greg -- what do you think?