rooty/LibrePilot
1
0
Fork 0
mirror of https://bitbucket.org/librepilot/librepilot.git synced 2024-11-29 07:24:13 +01:00
Code Issues Releases Activity
33188bd78e
LibrePilot/shared/uavobjectdefinition/i2cstats.xml

20 lines
2.2 KiB
XML
Raw Normal View History

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 08:01:58 +01:00
<xml>
Categorizing all UAVObjects into 5 main categories: State, Sensors, System, Navigation, Control
2013-06-22 19:58:54 +02:00
<object name="I2CStats" singleinstance="true" settings="false" category="System">
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 08:01:58 +01:00
<description>Tracks statistics on the I2C bus.</description>
OP-14 OP-16: I2C Improvements 1) Added nack counter monitoring 2) Made timeout for getting semaphore in I2C user space code use the one from driver and record timeouts. This does not influence timeouts in the non FreeRTOS case 3) Remove case block from the error handler so that all bus errors reset the i2c interface git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2469 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-01-17 03:11:12 +01:00
<field name="event_errors" units="" type="uint8" elements="1"/>
<field name="fsm_errors" units="" type="uint8" elements="1"/>
<field name="irq_errors" units="" type="uint8" elements="1"/>
<field name="nacks" units="" type="uint8" elements="1"/>
<field name="timeouts" units="" type="uint8" elements="1"/>
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 08:01:58 +01:00
<field name="last_error_type" units="" type="enum" elements="1" options="EVENT,FSM,INTERRUPT"/>
OP-14 I2C Diagnostics: Improve the logging so that the events going into FSM are logged, and separately the erirq and evirq logs are exported git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2368 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-01-10 06:42:53 +01:00
<field name="evirq_log" units="" type="uint32" elements="5"/>
<field name="erirq_log" units="" type="uint32" elements="5"/>
<field name="event_log" units="" type="enum" elements="5" options="I2C_EVENT_BUS_ERROR, I2C_EVENT_START, I2C_EVENT_STARTED_MORE_TXN_READ, I2C_EVENT_STARTED_MORE_TXN_WRITE, I2C_EVENT_STARTED_LAST_TXN_READ, I2C_EVENT_STARTED_LAST_TXN_WRITE, I2C_EVENT_ADDR_SENT_LEN_EQ_0, I2C_EVENT_ADDR_SENT_LEN_EQ_1, I2C_EVENT_ADDR_SENT_LEN_EQ_2, I2C_EVENT_ADDR_SENT_LEN_GT_2, I2C_EVENT_TRANSFER_DONE_LEN_EQ_0, I2C_EVENT_TRANSFER_DONE_LEN_EQ_1, I2C_EVENT_TRANSFER_DONE_LEN_EQ_2, I2C_EVENT_TRANSFER_DONE_LEN_GT_2, I2C_EVENT_NACK, I2C_EVENT_STOPPED, I2C_EVENT_AUTO"/>
<field name="state_log" units="" type="enum" elements="5" options="I2C_STATE_FSM_FAULT,I2C_STATE_BUS_ERROR,I2C_STATE_STOPPED,I2C_STATE_STOPPING,I2C_STATE_STARTING,I2C_STATE_R_MORE_TXN_ADDR,I2C_STATE_R_MORE_TXN_PRE_ONE,I2C_STATE_R_MORE_TXN_PRE_FIRST,I2C_STATE_R_MORE_TXN_PRE_MIDDLE,I2C_STATE_R_MORE_TXN_LAST,I2C_STATE_R_MORE_TXN_POST_LAST,R_LAST_TXN_ADDR,I2C_STATE_R_LAST_TXN_PRE_ONE,I2C_STATE_R_LAST_TXN_PRE_FIRST,I2C_STATE_R_LAST_TXN_PRE_MIDDLE,I2C_STATE_R_LAST_TXN_PRE_LAST,I2C_STATE_R_LAST_TXN_POST_LAST,I2C_STATE_W_MORE_TXN_ADDR,I2C_STATE_W_MORE_TXN_MIDDLE,I2C_STATE_W_MORE_TXN_LAST,I2C_STATE_W_LAST_TXN_ADDR,I2C_STATE_W_LAST_TXN_MIDDLE,I2C_STATE_W_LAST_TXN_LAST,I2C_STATE_NACK"/>
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 08:01:58 +01:00
<access gcs="readwrite" flight="readwrite"/>
<telemetrygcs acked="false" updatemode="manual" period="0"/>
<telemetryflight acked="false" updatemode="periodic" period="10000"/>
set all uavobjects logging mode to manual enable only at users discretion as needed to preserve log space
2013-11-17 20:45:04 +01:00
<logging updatemode="manual" period="0"/>
OP-316 UAVObject Fix typo, indents, units, default values git-svn-id: svn://svn.openpilot.org/OpenPilot/trunk@2896 ebee16cc-31ac-478f-84a7-5cbb03baadba
2011-02-27 01:38:59 +01:00
</object>
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 08:01:58 +01:00
</xml>
Reference in New Issue Copy Permalink