I do not think a driver requires an os device personally. You could write a
driver that does not have os dev functionality in it. I do agree that it seems
most people implement drivers with os dev functionality but I do not think it
is a requirement.
> On Aug 31, 2018, at 9:51 AM, Christopher
it’s easiest to inspect these addresses with gdb :)
arm-none-eabi-gdb bin/targets/……. .elf
and then start feeding those addresses to see which ones look likely to be part
of callchain.
x/i 0x0003b4d8
x/i 0x000246a7
x/i 0x0003b4d8
etc
> On Aug 31, 2018, at 3:30 PM, Aditya Xavier
> wrote:
>
>
Am really bad at GDB. Also its like a rabbit hole :)
I ported over my application with the git version of Mynewt-core, and enabled
OS_CRASH_STACKTRACE.
With it enabled, the following is the dump.
#mesh-onoff STATUS: Sent !
Action Received over MESH Length :- 14
000486 Unhandled interrupt (3),
Some suggestions (inline).
> On Aug 31, 2018, at 2:32 PM, Aditya Xavier
> wrote:
>
> Gosh, this doesn’t make much sense to me :(
>
> (gdb) monitor go
> (gdb) monitor reset
> Resetting target
> (gdb) c
> Continuing.
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
>
Sure. Something like this:
000933 compat> crash div0
crash div0
003157 Unhandled interrupt (3), exception sp 0x20001dd8
003157 r0:0x r1:0x00017161 r2:0x r3:0x002a
003157 r4:0x200041d6 r5:0x r6:0x2318 r7:0x
003157 r8:0x r9:0x
It seems OS_CRASH_STACKTRACE was introduced after 1.4.1 and hence not in the
release.
If I change the release, I believe there would be many API changes to be done
on MESH side.
Can you guide me on how to "manually walk the stack for looking for things
which look like pointers to text” ?
My
