mirror of
https://github.com/Telecominfraproject/OpenCellular.git
synced 2026-01-12 10:55:21 +00:00
696b908f53a9d33bc9ce1a676ee646f45d489ee5
The I2C peripheral on the EC can get confused if there is a very specific kind of noise introduced to the line. This can be manifested by jiggling the battery jack. It gets the I2C into a state where everything seems fine outwardly, but the device refuses to even transmit START bits on the line. It appears that one of the stray pulses on the i2c bus gets the device off set from the actual bytes, leaving it misinterpreting everything and waiting forever. In this case, there is only one way to recover (as you can't directly access these aspects of the internal state) and that is to do a software reset of the i2c peripheral. Here I add some code to check for the condition where the EC was unable to even send a START bit, and do a software reset of the i2c to recover. BUG=chrome-os-partner:13161 TEST=With a faulty-battery-jack-board: Boot board, test that i2c works by running "pmu" on the EC console. Jiggle battery jack repeatedly until errors are displayed on console. Try to run pmu again. Make sure that it recovers gracefully, and do this many times. BRANCH=snow Change-Id: I91b8ef0c6f6079bc63f4a6a1bc91f67d19db9fc0 Signed-off-by: Charlie Mooney <charliemooney@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32286 Reviewed-by: David Hendricks <dhendrix@chromium.org>
- EC Lib
This wraps Blizzard driverlib and implements the EC chip interface defined
by Google. See below diagram for architecture.
+--------------------+
| Host BIOS/OS |
+--------------------+
---- host interface ----
+--------------------+
| Google EC features |
+--------------------+
---- chip interface ---- The interface is defined in
src/platform/ec/chip_interface/*.
+--------------------+ But the real implementation is in EC Lib.
| EC Lib |
+--------------------+
| Blizzard low level |
| driver, the |
| driverlib. |
+--------------------+
Build Options
=============
- CONFIG_WATCHDOG_HELP
Try to detect a watchdog that is about to fire, and print a trace.
This is needed on STM32, where the independent watchdog has no early
warning feature and the windowed watchdog has a very short period.
- CONFIG_PANIC_HELP
Report extra information about a panic, such as the fault address,
here shown as bfar. This shows the reason for the fault and may help
to determine the cause.
=== EXCEPTION: 03 ====== xPSR: 01000000 ===========
r0 :0000000b r1 :00000047 r2 :60000000 r3 :200013dd
r4 :00000000 r5 :080053f4 r6 :200013d0 r7 :00000002
r8 :00000000 r9 :200013de r10:00000000 r11:00000000
r12:00000000 sp :200009a0 lr :08002b85 pc :08003a8a
Precise data bus error, Forced hard fault, Vector catch, bfar = 60000000
mmfs = 00008200, shcsr = 00000000, hfsr = 40000000, dfsr = 00000008
- CONFIG_ASSERT_HELP
Report assertion failures in a vebose manner to aid debugging. When
enabled an ASSERT() which fails will produce message in the form:
ASSERTION FAILURE '<expr>' in function() at file:line
- CONFIG_CONFIGURE_BOARD_LATE
Define this to call configure_board_late() after initial system init
is complete (and after GPIOs are set up).
- CONFIG_AC_POWER_STATUS
Monitor the state of the AC power input and drive out a GPIO to
the AP indicating this state. The GPIO will be driven low when
AC power is not connected, and high when it is connected. This
uses GPIO_AC_STATUS for this purpose.
Description
Languages
C
64.7%
Lasso
20.7%
ASL
3.6%
JavaScript
3.2%
C#
2.9%
Other
4.6%