| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than just reset the board, report assertion failures to aid
debugging. To enable this, use CONFIG_ASSERT_HELP.
BUG=chrome-os-partner:10149
TEST=manual
Enable the option for snow, add a failing ASSERT() to the rw command
and see the a nice message is printed now.
ASSERTION FAILURE 'address' in command_read_word() at common/memory_commands.c:00000037
Change-Id: Ice59434c5daf610832dd0e1fcfa5630dc847bb67
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/25411
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fault status registers sometimes have useful information, so provide
an option to display these.
This adds about 1KB to the code size.
BUG=chrome-os-partner:10146
TEST=manual:
build for all boards
On snow, cause a panic and see that it is reported correctly.
=== 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
Change-Id: I1a18c85ee63760502c92b300f5a87e57468469a5
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/24505
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For particularly nasty errors the stack or stack pointer may be corrupt,
or in a place that we do not want overwritten. Provide and option to
place the stack in a fresh place, assuming you can reach exception_panic().
Note that exception_panic() does not write anything to stack itself.
BUG=chrome-os-partner:10146
TEST=manual:
build for all boards
On snow, cause a panic and see that it is reported correctly.
Change-Id: I21d8b9bb12455758309d54ef20de66640d8a2df6
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/24504
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than just reset with no information when we hit a watchdog, try
to anticipate the problem and display a trace message as on lm4.
This solution is not ideal since we must constantly reset the WWDG to make
it work. It may be better to look at dedicating a timer to this purpose
instead, since we are really just shadowing the IWDG and don't actually
need the reset functionality.
One problem is that we now have a fairly short time limit on many
operations, since if we can't service an interrupt within about 30ms then
the WWDG will reset the system.
It also affects JTAG since it seems that the watchdog goes off the first
time JTAG is invoked to program the flash. The solution here is to retry.
For these reasons it is implemented as an option, CONFIG_WATCHDOG_HELP.
BUG=chrome-os-partner:10145
TEST=manual:
build for all boards
On snow:
> waitms 500
See that there is no message
> waitms 1300
Time: 0x0000000000733ba3 us
Deadline: 0x00000000006b6db2 -> -0.511473 s from now
Active timers:
Task Ready Name Events Time (s)
0 R << idle >> 00000000 0.000000
1 R WATCHDOG 80000000 0.000000
2 KEYSCAN 00000000 0.000000
3 GAIAPOWER 00000000 0.000000
4 R CONSOLE 00000000 0.000000
5 HOSTCMD 00000000 0.000000
--- UART initialized after reboot ---
[Reset cause: watchdog]
[Image: RO, snow_v1.1.32-8c00326-dirty 2012-06-03 07:54:29 sjg@sglass.mtv.corp.google.com]
done
Change-Id: I042fcc9ecd9c21210ea3826ca69c943aab949d1f
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/24398
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
BUG=None
Test=None
|
