1
0
mirror of https://bitbucket.org/librepilot/librepilot.git synced 2024-11-30 08:24:11 +01:00
Commit Graph

8 Commits

Author SHA1 Message Date
stac
66a9d53d0a hwinit: Convert I2C driver to dynamic init
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2773 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-12 22:19:54 +00:00
peabody124
4b4a66c2d7 PiOS/I2C: Lots of small changes. Added a few weird bus events that are
sometimes thrown, and made errors not lock it up by default.  It works for me,
but since this has historically been associated with lots of lock ups please
check your systems carefully.

PiOS/I2C: Make the bus by default try to recover from errors instead of locking
up

PiOS/I2C: After a bus error and clocking all previous data create a STOP
condition to make sure bus is released (note, this also requires creating a
START condition first)

PiOS/I2C: If the same event hits the I2C bus twice in a row then disregard
second one, there is no situation where we should get the same event multiple
times that matters and this gets us out really quickly to catch the real
events.  I was seeing this with repeated 0x70084 which means byte transmitted.
This is related to STM32 bugs in the IRQ timings I believe.

PiOS/I2C: 1) Mask out some bits we don't care about in the event flags
2) Don't lock up if the give semaphore fails, although why it does is strange
3) Recover from bus failure through the "auto" state path instead of just
coding state

PiOS/I2C: Change the reset bus code to follow
http://www.analog.com/static/imported-files/application_notes/54305147357414AN686_0.pdf
(thanks for the reference Neontangerine).  Although this may actually NOT clear
the bus the first time through, subsequent bus errors should eventually clock
it out.  The up side is it is less likely to clock a bunch of 1s into an ESC
and make it run up.

PiOS/I2C: Some cleaned up code for getting a snippet of the history when
something strange happens

PiOS/I2C: Export logging information from I2C through a UAV object

PiOS/I2C: Improve the diagnostic information

PiOS/I2C: Need to handle the event 0x30084.  This seems to happen between a
byte transmitted and new byte started

PiOS/I2C: Handle the NACK condition by simply going to the stopping state.

PiOS/I2C: Add a new NACK state to handle sending the STOP signal after a NACK
following the STM documentation.  Other error conditions still are not dealt
with.

PiOS/I2C: Should handle the NACK condition from all the write cases.  Need to
think about read cases

git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2239 ebee16cc-31ac-478f-84a7-5cbb03baadba
2010-12-17 07:01:58 +00:00
peabody124
3c021c09d9 Flight/PiOS: Whitespace changes
find ./flight/PiOS/inc/ \! \( -name '*~' -a -prune \) -type f    | xargs -I{}
bash -c 'echo {}; dos2unix {}; gnuindent -npro -kr -i8 -ts8 -sob -ss -ncs -cp1
-il0 -hnl -l150 {};'

git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1777 ebee16cc-31ac-478f-84a7-5cbb03baadba
2010-09-27 07:28:45 +00:00
stac
88e73906d0 i2c: Add recovery code for i2c bus errors
I2C bus errors are now recoverable.  The bus is properly reset
and an error indication is now provided to the caller whenever
a bus error occurs during processing of the transaction list.

For now, the users of the I2C layer just retry infinitely on
failure.  The BMP085 and HMC5843 code should be changed to
report errors to its callers to allow a more sensible retry
strategy.

git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1625 ebee16cc-31ac-478f-84a7-5cbb03baadba
2010-09-15 14:20:57 +00:00
stac
85c60479c1 i2c: rename FSM faulted state
Differentiate the _FSM_ faulted from the (soon to
exist _BUS_ faulted state.

git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1621 ebee16cc-31ac-478f-84a7-5cbb03baadba
2010-09-15 14:20:52 +00:00
pip
8bfaa997d3 made curr_state 'volatile' in pios_i2c_priv.h to prevernt compiler optimization lockup.
git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1611 ebee16cc-31ac-478f-84a7-5cbb03baadba
2010-09-13 20:52:56 +00:00
stac
98822bff98 i2c: force bus free on warm starts
Since the i2c bus is bidirectional, there are certain
states (eg. part way through a read) where the slave
device is in control of driving the SDA line.

On a cold start (power on), the slave devices are all
quiescent and will not drive the bus.  However, on a warm
start (eg. watchdog or jtag restart), it is possible that as
the CPU boots, the slave device may be holding the SDA line
low.  This is a bus busy condition and will prevent the I2C
bus master in the CPU from being able to seize the bus during
init.

The fix for this is to clock the i2c bus sufficiently to ensure
that the the slave device finishes its transaction and releases
the bus.

Once the slave has released the bus, the bus master can properly
initialize and assert a STOP condition on the bus.

git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1349 ebee16cc-31ac-478f-84a7-5cbb03baadba
2010-08-21 16:19:02 +00:00
stac
f74c6ffdd5 i2c: rewrite i2c layer
The STM32 I2C block has a number of errata associated with it.
These errata are primarily related to timing sensitivities between
the peripheral and the interrupt handler.  In particular, the
correct generation of the stop bit relies on the I2C IRQ running
immediately and not being held off for any reason.

NOTE: The I2C interrupts must be the highest priority IRQs in the
      system to ensure correct operation.

I2C protocol is now implemented as a formal state machine.
See: stm32_i2c_fsm.{dot,jpg} for FSM description.

I2C init is now expressed by const initializers in pios_board.c
for both OP and AHRS boards.

I2C device drivers (ie. bmp085/hmc5843) now pass in const arrays
of an unlimited number of bus transfers to be done atomically.
The I2C adapter driver now handles all bus-level locking across the
list of transactions.  Generation of start/restart/stop conditions
are handled automatically over the list of transactions.

Timeouts have been removed from the API for now.  May be added
back later.

This driver has run error free on both the OP and AHRS boards for
up to 48hrs but it still sometimes fails earlier than that on the OP
board.  There is another possible set of improvements to the driver
that could employ the DMA engine for transfers of >= 2bytes.  This
change would reduce the timing sensitivities between the peripheral
and the driver but unfortunately, both the SPI and I2C interfaces
share the DMA1 engine.  That means only one of these two peripherals
can use the DMA engine and right now, SPI between OP and AHRS is
already using it.

Failures are currently fatal and will lock up the CPU.  This allows
useful information to be obtained in the failure cases.

git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@1241 ebee16cc-31ac-478f-84a7-5cbb03baadba
2010-08-08 04:15:08 +00:00