Hard faults #11

danielkucera · 2020-01-29T11:10:11Z

I'll start collecting my hard-faults here:

(gdb) bt
#0  hard_fault_handler (sp=0x20000200 <heap_top>, corrupted=1, exc_return=4294967281, r4_to_r11_stack=0x200001e0 <isr_stack+480>)
    at /storage/Projects/pinetime/PineTime-apps/RIOT/cpu/cortexm_common/vectors_cortexm.c:344
#1  0x0000040e in isr_pendsv () at /storage/Projects/pinetime/PineTime-apps/RIOT/cpu/cortexm_common/thread_arch.c:284
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info registers
r0             0xffffffff	-1
r1             0x2	2
r2             0x2861443	42341443
r3             0x92000000	-1845493760
r4             0x20000200	536871424
r5             0x0	0
r6             0x0	0
r7             0x92	146
r8             0x1	1
r9             0x2000094c	536873292
r10            0x200001e0	536871392
r11            0xfffffff1	-15
r12            0x2	2
sp             0x20000180	0x20000180 <isr_stack+384>
lr             0x597	1431
pc             0x5d4	0x5d4 <hard_fault_handler+108>
xPSR           0x21000003	553648131
fpscr          0x0	0
msp            0x20000180	0x20000180 <isr_stack+384>
psp            0x200009f0	0x200009f0 <sched_threads+40>
primask        0x0	0
basepri        0x0	0
faultmask      0x0	0
control        0x0	0

a.zip

The text was updated successfully, but these errors were encountered:

danielkucera · 2020-01-29T11:10:41Z

and sp[6] doesn't work...

(gdb) print sp[6]
$8 = 1
(gdb) print $sp[6]
Attempt to dereference a generic pointer.

danielkucera · 2020-01-29T15:11:06Z

(gdb) bt
#0  hard_fault_handler (sp=0x20000200 <heap_top>, corrupted=1, exc_return=4294967281, r4_to_r11_stack=0x200001e0 <isr_stack+480>)
    at /storage/Projects/pinetime/PineTime-apps/RIOT/cpu/cortexm_common/vectors_cortexm.c:344
#1  0x0000040e in isr_pendsv () at /storage/Projects/pinetime/PineTime-apps/RIOT/cpu/cortexm_common/thread_arch.c:284
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info registers
r0             0xffffffff	-1
r1             0x3	3
r2             0x1444e67c	340059772
r3             0x92000000	-1845493760
r4             0x20000200	536871424
r5             0x0	0
r6             0x0	0
r7             0x92	146
r8             0x1	1
r9             0x2000094c	536873292
r10            0x200001e0	536871392
r11            0xfffffff1	-15
r12            0x3	3
sp             0x20000180	0x20000180 <isr_stack+384>
lr             0x597	1431
pc             0x5d4	0x5d4 <hard_fault_handler+108>
xPSR           0x21000003	553648131
fpscr          0x0	0
msp            0x20000180	0x20000180 <isr_stack+384>
psp            0x200009f0	0x200009f0 <sched_threads+40>
primask        0x0	0
basepri        0x0	0
faultmask      0x0	0
control        0x0	0
(gdb)

danielkucera · 2020-01-29T16:55:23Z

(gdb) bt
#0  hard_fault_handler (sp=0x20000200 <heap_top>, corrupted=1, exc_return=4294967281, r4_to_r11_stack=0x200001e0 <isr_stack+480>)
    at /storage/Projects/pinetime/PineTime-apps/RIOT/cpu/cortexm_common/vectors_cortexm.c:344
#1  0x0000040e in isr_pendsv () at /storage/Projects/pinetime/PineTime-apps/RIOT/cpu/cortexm_common/thread_arch.c:284
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info registers
r0             0xffffffff	-1
r1             0x1	1
r2             0x219e17a	35250554
r3             0x92000000	-1845493760
r4             0x20000200	536871424
r5             0x0	0
r6             0x0	0
r7             0x92	146
r8             0x1	1
r9             0x2000094c	536873292
r10            0x200001e0	536871392
r11            0xfffffff1	-15
r12            0x1	1
sp             0x20000180	0x20000180 <isr_stack+384>
lr             0x597	1431
pc             0x5d4	0x5d4 <hard_fault_handler+108>
xPSR           0x21000003	553648131
fpscr          0x0	0
msp            0x20000180	0x20000180 <isr_stack+384>
psp            0x200009f0	0x200009f0 <sched_threads+40>
primask        0x0	0
basepri        0x0	0
faultmask      0x0	0
control        0x0	0

bergzand · 2020-01-29T19:03:12Z

I've confirmed the hard fault here. It seems there is at least one assertion failure triggered in the xtimer system in RIOT.

bergzand · 2020-01-30T11:36:33Z

@danielkucera I've pushed a commit to bump the RIOT submodule version. The new RIOT version includes RIOT-OS/RIOT#13212 among other xtimer bug fixes. The issue caused by that bug (RIOT-OS/RIOT#13209) and which should be fixed with this sounded awfully familiar to what you mentioned.

Please let me know if the new RIOT submodule commit improves stability for you!

danielkucera · 2020-01-30T18:20:38Z

It looks like it's still there:

hard_fault_handler (sp=0x20000200 <heap_top>, corrupted=1, exc_return=4294967281, r4_to_r11_stack=0x200001e0 <isr_stack+480>)
    at /storage/Projects/pinetime/PineTime-apps/RIOT/cpu/cortexm_common/vectors_cortexm.c:344
344	    if (cfsr & BFARVALID_MASK) {
(gdb) bt
#0  hard_fault_handler (sp=0x20000200 <heap_top>, corrupted=1, exc_return=4294967281, r4_to_r11_stack=0x200001e0 <isr_stack+480>)
    at /storage/Projects/pinetime/PineTime-apps/RIOT/cpu/cortexm_common/vectors_cortexm.c:344
#1  0x0000040e in isr_pendsv () at /storage/Projects/pinetime/PineTime-apps/RIOT/cpu/cortexm_common/thread_arch.c:284
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info registers
r0             0xffffffff	-1
r1             0x1	1
r2             0xb0e6fc2	185495490
r3             0x92000000	-1845493760
r4             0x20000200	536871424
r5             0x0	0
r6             0x0	0
r7             0x92	146
r8             0x1	1
r9             0x2000094c	536873292
r10            0x200001e0	536871392
r11            0xfffffff1	-15
r12            0x1	1
sp             0x20000180	0x20000180 <isr_stack+384>
lr             0x597	1431
pc             0x5d4	0x5d4 <hard_fault_handler+108>
xPSR           0x21000003	553648131
fpscr          0x0	0
msp            0x20000180	0x20000180 <isr_stack+384>
psp            0x200009f0	0x200009f0 <sched_threads+8>
primask        0x0	0
basepri        0x0	0
faultmask      0x0	0
control        0x0	0
(gdb)

a.zip

danielkucera · 2020-02-04T09:22:49Z

I've tried to leave it without BT pairing and it crashed anyway.

bergzand · 2020-02-14T19:24:15Z

@danielkucera I've pushed a new version which includes an updated RIOT branch. Long story short, the Nimble repo merged an important fix in their timer glue code for RIOT. The latest push includes those fixes.

danielkucera · 2020-02-17T09:21:45Z

$ make BUILD_IN_DOCKER=1
Launching build container using image "riot/riotbuild:latest".
docker run --rm -t -u "$(id -u)" \
.
.
.
.
/data/riotbuild/external/hal/hal.c: In function 'hal_get_reset_reason':
/data/riotbuild/external/hal/hal.c:88:16: error: implicit declaration of function 'bitarithm_lsb' [-Werror=implicit-function-declaration]
         return bitarithm_lsb(reset_reason);
                ^~~~~~~~~~~~~
/data/riotbuild/external/hal/hal.c: At top level:
cc1: error: unrecognized command line option '-Wno-cast-function-type' [-Werror]
cc1: all warnings being treated as errors
/data/riotbuild/riotbase/Makefile.base:110: recipe for target '/data/riotbuild/riotproject/apps/pinetime/bin/pinetime/hal/hal.o' failed
make[2]: *** [/data/riotbuild/riotproject/apps/pinetime/bin/pinetime/hal/hal.o] Error 1
/data/riotbuild/riotbase/Makefile.base:30: recipe for target 'ALL--/data/riotbuild/external/hal' failed
make[1]: *** [ALL--/data/riotbuild/external/hal] Error 2
/data/riotbuild/riotbase/Makefile.include:539: recipe for target '/data/riotbuild/riotproject/apps/pinetime/bin/pinetime/application_PineTime.a' failed
make: *** [/data/riotbuild/riotproject/apps/pinetime/bin/pinetime/application_PineTime.a] Error 2
/home/yw674/private/PineTime-apps/RIOT/makefiles/docker.inc.mk:285: recipe for target '..in-docker-container' failed
make: *** [..in-docker-container] Error 2

commit:

commit 115ac52cc58f00110d0620f47f460706a679d79a (HEAD -> master, origin/master, origin/HEAD)
Author: Koen Zandberg <koen@bergzand.net>
Date:   Fri Feb 14 20:20:10 2020 +0100

    bleman: update Nimble config for new version

$ git status 
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

danielkucera · 2020-02-17T09:24:06Z

same as here: https://cirrus-ci.com/task/5448693046312960

bergzand · 2020-02-19T09:17:29Z

Whoops, my bad. Should be fixed now, CI shows all green

danielkucera · 2020-02-20T16:02:00Z

It is more than 5 hours since last upload and still working. Maybe the difference is in compilation - this time I used dockerized compiler. I will try my system gcc tomorrow.

bergzand · 2020-02-20T16:07:56Z

@danielkucera That sounds promising!

bergzand · 2020-03-01T17:11:29Z

@danielkucera Any news here?

danielkucera · 2020-04-05T12:34:38Z

I built latest master using my system gcc

gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (15:7-2018-q2-6)

and it hard faults.
Attaching built binary
PineTime.zip

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Hard faults #11

Hard faults #11

danielkucera commented Jan 29, 2020

danielkucera commented Jan 29, 2020

danielkucera commented Jan 29, 2020

danielkucera commented Jan 29, 2020

bergzand commented Jan 29, 2020

bergzand commented Jan 30, 2020

danielkucera commented Jan 30, 2020

danielkucera commented Feb 4, 2020

bergzand commented Feb 14, 2020

danielkucera commented Feb 17, 2020

danielkucera commented Feb 17, 2020

bergzand commented Feb 19, 2020

danielkucera commented Feb 20, 2020

bergzand commented Feb 20, 2020

bergzand commented Mar 1, 2020

danielkucera commented Apr 5, 2020

Hard faults #11

Hard faults #11

Comments

danielkucera commented Jan 29, 2020

danielkucera commented Jan 29, 2020

danielkucera commented Jan 29, 2020

danielkucera commented Jan 29, 2020

bergzand commented Jan 29, 2020

bergzand commented Jan 30, 2020

danielkucera commented Jan 30, 2020

danielkucera commented Feb 4, 2020

bergzand commented Feb 14, 2020

danielkucera commented Feb 17, 2020

danielkucera commented Feb 17, 2020

bergzand commented Feb 19, 2020

danielkucera commented Feb 20, 2020

bergzand commented Feb 20, 2020

bergzand commented Mar 1, 2020

danielkucera commented Apr 5, 2020