diff options
author | Vincent Palatin <vpalatin@chromium.org> | 2014-04-22 10:45:59 -0700 |
---|---|---|
committer | chrome-internal-fetch <chrome-internal-fetch@google.com> | 2014-04-25 23:06:56 +0000 |
commit | 96ef35acba6656bd27aa7e4162d5bafa9e915900 (patch) | |
tree | 9dbc5a809e0bcadd79f55cd3d13034c7b89f3d51 /driver | |
parent | 3ac560d41bf8c225725cdf03c2b4f4d723739d0f (diff) | |
download | chrome-ec-96ef35acba6656bd27aa7e4162d5bafa9e915900.tar.gz |
cortex-m0: fix hard-faults during software interrupt calls
From time to time (usually under heavy interrupt load), the runtime on
Cortex-M0 was panic'ing at the "svc" instruction with a HardFault
exception (inside the wait_event() function).
The issue was probably the following :
the wait_event() code is doing an atomic_read_clear() whose critical
section disables interrupts and re-enables them using "cpsie i",
then do __schedule() call which is essentially a "svc" instruction.
According to ARMv6-m reference manual :
"If execution of a CPS instruction:
increases the execution priority, the CPS execution serializes that
change to the instruction stream.
decreases the execution priority, the architecture guarantees only that
the new priority is visible to instructions executed after either executing
an ISB instruction, or performing an exception entry or exception
return."
So, when we are executing the "svc", PRIMASK.PM can still be seen as 1
(while it was set to 0 by "cpsie i") and in that case the software
interrupt is replaced by a HardFault.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28296
TEST=run Firefly board under load for extended periods of time.
Change-Id: Ie355c36f06e6fe2fee5cca8998a469fa096badad
Reviewed-on: https://chromium-review.googlesource.com/196659
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Diffstat (limited to 'driver')
0 files changed, 0 insertions, 0 deletions