mirror of
https://github.com/Telecominfraproject/OpenCellular.git
synced 2026-01-01 12:52:26 +00:00
a78bb5e560
There were a number of problems resulting from i2c crashes, particularly when trying to access the battery. The problem is that the stack was overflowing on this particularly deep path, all the way down to wait_status. This in itself was fine, but if there was a timeout, debugging information would be printed to the uart, and that function would cause an exception and restart the EC. To fix it, I stripped the debugging CPRINTFs from wait_status. This allows everything to work fine, but looses some information for debugging. To allow future developers to still see what event the i2c was waiting for, I added an additional variable to store it in, so that it can be displayed/handled further up the stack. BUG=chrome-os-partner:12245 TEST=Boot the machine using a Servo. On the AP's UART, run "cros_test i2c" to start pounding the i2c bus. Then from the EC, run "pmu 1000" and then "battery 1000" there should be no error messages, exceptions, and the EC should not restart. Repeat this process with i2c arbitration disabled (remove the flag in ./board/snow/board.h). You should suffer no fatal errors. cros_test may report errors detected, but the EC will never crash, restart, or throw exceptions. These other errors are the EC and the AP stepping on each other's toes now that you have disabled arbitration. Change-Id: Idd2f017d3557652bf3e8536c4ac776c1f70319cb Signed-off-by: Charlie Mooney <charliemooney@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/29351 Reviewed-by: Simon Glass <sjg@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_NEW_STACK
When reporting a panic, change to a completely new stack. This might
help get a useful trace out a situation where the stack or stack
pointer has been corrupted.
- 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