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 gdb skill are pretty weak.
I tried gdb where, with the following outcome.
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
hal_system_reset () at
repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/hal_system.c:50
50 asm("bkpt");
(gdb)
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
hal_system_reset () at
repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/hal_system.c:50
50 asm("bkpt");
(gdb) where
#0 hal_system_reset () at
repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/hal_system.c:50
#1 0x0000bf2e in os_default_irq (tf=0x2000ffc8) at
repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/os_fault.c:170
#2 0x0000da56 in os_default_irq_asm () at
repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/m4/HAL_CM4.s:260
#3 <signal handler called>
#4 0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> On 31-Aug-2018, at 4:30 PM, marko kiiskila <[email protected]> wrote:
>
>
>
>> On Aug 31, 2018, at 1:47 PM, Aditya Xavier <[email protected]>
>> wrote:
>>
>> Hi !
>>
>> Am having an issue with Sending and Receiving a Mesh Message. Though am
>> positive the problem is more towards releasing the semaphore.
>>
>> Action Received over MESH Length :- 15
>> 012273 Unhandled interrupt (3), exception sp 0x2000abd0
>> 012273 r0:0xd7229882 r1:0xd929b3bb r2:0xcf0f98cb r3:0x5c5a76b3
>> 012273 r4:0x1b000000 r5:0x2000acc0 r6:0x2000aca0 r7:0x00000008
>> 012273 r8:0x00000000 r9:0x200008a9 r10:0x2000ad28 r11:0x00011d91
>> 012273 r12:0x681af5c8 lr:0xb1334673 pc:0x7e3cdeb8 psr:0x2266a80b
>> 012273 ICSR:0x00411803 HFSR:0x40000000 CFSR:0x00040000
>> 012273 BFAR:0xe000ed38 MMFAR:0xe000ed34
>>
>> Am sending a group mesh message for testing. The sequence of events are as
>> follows.
>>
>> Button TASK -> send message over MESH -> Mesh receives message on model ->
>> copies the data and starts releases the Semaphore for another task -> LOG
>> Task starts and logs the message.
>>
>> In this entire flow, the moment I receive the message and release the
>> semaphore the firmware crashes.
>>
>> I tried increasing the STACK size of the LOG task, however that didn’t help.
>>
>> Could someone let me know how to understand where / why the crash is
>> happening ?
>
> Looking at your registers they seem to be garbage, so I’m guessing stack
> corruption of some sort; does not have to be overflow.
> Try turning on OS_CRASH_STACKTRACE, or manually walk the stack for looking
> for things which
> look like pointers to text.
>
>
