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.
hal_system_reset () at
repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/hal_system.c:50
50 asm("bkpt");
(gdb) bt
#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?)
(gdb) frame 1
#1 0x0000bf2e in os_default_irq (tf=0x2000ffc8) at
repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/os_fault.c:170
170 hal_system_reset();
(gdb) p/x *tf
$1 = {ef = 0x2000abd0, r4 = 0x1b000000, r5 = 0x2000acc0, r6 = 0x2000aca0, r7 =
0x7, r8 = 0x0, r9 = 0x200008a9, r10 = 0x2000ad28, r11 = 0x11d91, lr =
0xfffffffd}
(gdb) p/x *tf->ef
$2 = {r0 = 0xd7229882, r1 = 0xd929b3bb, r2 = 0xcf0f98cb, r3 = 0x5c5a76b3, r12 =
0x681af5c8, lr = 0xb1334673, pc = 0x7e3cdeb8, psr = 0x2266a80b}
(gdb) x/32x 0xd7229882
0xd7229882: 0x00000000 0x00000000 0x00000000 0x00000000
0xd7229892: 0x00000000 0x00000000 0x00000000 0x00000000
0xd72298a2: 0x00000000 0x00000000 0x00000000 0x00000000
0xd72298b2: 0x00000000 0x00000000 0x00000000 0x00000000
0xd72298c2: 0x00000000 0x00000000 0x00000000 0x00000000
0xd72298d2: 0x00000000 0x00000000 0x00000000 0x00000000
0xd72298e2: 0x00000000 0x00000000 0x00000000 0x00000000
0xd72298f2: 0x00000000 0x00000000 0x00000000 0x00000000
(gdb) x/32x 0x2000abd0
0x2000abd0: 0xd7229882 0xd929b3bb 0xcf0f98cb 0x5c5a76b3
0x2000abe0: 0x681af5c8 0xb1334673 0x7e3cdeb8 0x2266a80b
0x2000abf0: 0x59d8de5b 0xe8eb9828 0x96d74690 0xb4b1ee9b
0x2000ac00: 0x95f0cad6 0x7d1b52fe 0xebcc146e 0x5f7dfaf5
0x2000ac10: 0x62dd2c19 0x1fc67ee7 0xf40a6a89 0xab77907c
0x2000ac20: 0x00000010 0x00039c74 0x2000ad28 0x0002329f
0x2000ac30: 0xd87c5730 0xa203a288 0x00000010 0x00039c74
0x2000ac40: 0x2000ad28 0x00023485 0x00000000 0x00000000
(gdb) p &__text
No symbol "__text" in current context.
(gdb) p &__etext
$3 = (<data variable, no debug info> *) 0x3a9c8
(gdb) p &__text
No symbol "__text" in current context.
(gdb) x/i 0xd7229882
0xd7229882: movs r0, r0
(gdb) list *0xd7229882
(gdb) x/i 0x681af5c8
0x681af5c8: movs r0, r0
(gdb) x/i 0x59d8de5b
0x59d8de5b: movs r0, r0
(gdb) x/i 0x62dd2c19
0x62dd2c19: movs r0, r0
(gdb) x/i 0x2000ad28
0x2000ad28: lsls r0, r2, #6
(gdb) x/i 0x1fc67ee7
0x1fc67ee7: movs r0, r0
(gdb) x/i 0xa203a288
0xa203a288: movs r0, r0
(gdb) x/i 0xe8eb9828
0xe8eb9828: movs r0, r0
(gdb) x/i 0xcf0f98cb
0xcf0f98cb: movs r0, r0
(gdb) x/i 0x96d74690
0x96d74690: movs r0, r0
(gdb) x/i 0xf40a6a89
0xf40a6a89: movs r0, r0
(gdb) x/i 0x2000ad28
0x2000ad28: lsls r0, r2, #6
(gdb) x/i 0x00000010
0x10: movs r0, r0
(gdb) x/i 0x0002329f
0x2329f <shift_rows+108>: add sp, #20
(gdb) x/i 0x00039c74
0x39c74 <sbox>: ldrb r3, [r4, #17]
(gdb) x/i 0xa203a288
0xa203a288: movs r0, r0
(gdb) x/i 0x0002329f
0x2329f <shift_rows+108>: add sp, #20
(gdb) list *0x0002329f
0x2329f is in shift_rows
(repos/apache-mynewt-core/crypto/tinycrypt/src/aes_encrypt.c:156).
151 t[0] = s[0]; t[1] = s[5]; t[2] = s[10]; t[3] = s[15];
152 t[4] = s[4]; t[5] = s[9]; t[6] = s[14]; t[7] = s[3];
153 t[8] = s[8]; t[9] = s[13]; t[10] = s[2]; t[11] = s[7];
154 t[12] = s[12]; t[13] = s[1]; t[14] = s[6]; t[15] = s[11];
155 (void) _copy(s, sizeof(t), t, sizeof(t));
156 }
157
158 int tc_aes_encrypt(uint8_t *out, const uint8_t *in, const
TCAesKeySched_t s)
159 {
160 uint8_t state[Nk*Nb];
> On 31-Aug-2018, at 4:46 PM, marko kiiskila <[email protected]> wrote:
>
> Sure. Something like this:
>
> 000933 compat> crash div0
> crash div0
> 003157 Unhandled interrupt (3), exception sp 0x20001dd8
> 003157 r0:0x00000000 r1:0x00017161 r2:0x00000000 r3:0x0000002a
> 003157 r4:0x200041d6 r5:0x00000000 r6:0x20000318 r7:0x00000000
> 003157 r8:0x00000000 r9:0x00000000 r10:0x00000000 r11:0x00000000
> 003157 r12:0x00000000 lr:0x00014949 pc:0x00014978 psr:0x61000000
> 003157 ICSR:0x00421803 HFSR:0x40000000 CFSR:0x02000000
> 003157 BFAR:0xe000ed38 MMFAR:0xe000ed34
>
> Then from gdb:
>
> 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) bt
> #0 hal_system_reset ()
> at repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/hal_system.c:50
> #1 0x00008be8 in os_default_irq (tf=0x2000ffc0)
> at repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/os_fault.c:171
> #2 0x0000a5b6 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 ?? ()
> #5 0x0000812c in Reset_Handler ()
> at
> repos/apache-mynewt-core/hw/bsp/nrf52dk/src/arch/cortex_m4/gcc_startup_nrf52.s:180
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb) frame 1
> #1 0x00008be8 in os_default_irq (tf=0x2000ffc0)
> at repos/apache-mynewt-core/kernel/os/src/arch/cortex_m4/os_fault.c:171
> 171 hal_system_reset();
> (gdb) p/x *tf
> $1 = {ef = 0x20001dd8, r4 = 0x200041d6, r5 = 0x0, r6 = 0x20000318, r7 = 0x0,
> r8 = 0x0, r9 = 0x0, r10 = 0x0, r11 = 0x0, lr = 0xfffffffd}
> (gdb) p/x *tf->ef
> $2 = {r0 = 0x0, r1 = 0x17161, r2 = 0x0, r3 = 0x2a, r12 = 0x0, lr = 0x14949,
> pc = 0x14978, psr = 0x61000000}
> (gdb) x/32x 0x20001dd8
> 0x20001dd8 <os_main_stack+3896>: 0x00000000 0x00017161
> 0x00000000 0x0000002a
> 0x20001de8 <os_main_stack+3912>: 0x00000000 0x00014949
> 0x00014978 0x61000000
> 0x20001df8 <os_main_stack+3928>: 0x00000003 0x00000000
> 0x00000000 0x0000002a
> 0x20001e08 <os_main_stack+3944>: 0x00000001 0x00000002
> 0x0000000a 0x00014a21
> 0x20001e18 <os_main_stack+3960>: 0x00014a15 0x0000ebd9
> 0x00000000 0x200041d0
> 0x20001e28 <os_main_stack+3976>: 0x200041d6 0x00000000
> 0x0000000a 0x0001574d
> 0x20001e38 <os_main_stack+3992>: 0x00015741 0x0000c925
> 0x200041d0 0x00000011
> 0x20001e48 <os_main_stack+4008>: 0x00000073 0x200041d3
> 0x00000000 0x0000ede9
> (gdb) p &__text
> $3 = (<data variable, no debug info> *) 0x8020 <__isr_vector>
> (gdb) p &__etext
> $4 = (<data variable, no debug info> *) 0x175f0
> (gdb) x/i 0x00017161
> 0x17161: movs r0, r0
> (gdb) x/i 0x00014949
> 0x14949 <crash_device+12>: cbz r0, 0x1496a <crash_device+46>
> (gdb) x/i 0x00014978
> 0x14978 <crash_device+60>: sdiv r3, r3, r2
> (gdb) x/i 0x00014a21
> 0x14a21 <crash_cli_cmd+12>: cbz r0, 0x14a28 <crash_cli_cmd+20>
> (gdb) x/i 0x00014a15
> 0x14a15 <crash_cli_cmd>: push {r3, lr}
> (gdb) list *0x14949
> 0x14949 is in crash_device
> (repos/apache-mynewt-core/test/crash_test/src/crash_test.c:42).
> warning: Source file is more recent than executable.
> 37 int
> 38 crash_device(char *how)
> 39 {
> 40 volatile int val1, val2, val3;
> 41
> 42 if (!strcmp(how, "div0")) {
> 43
> 44 val1 = 42;
> 45 val2 = 0;
> 46
> (gdb) list *0x00014a21
> 0x14a21 is in crash_cli_cmd
> (repos/apache-mynewt-core/test/crash_test/src/crash_cli.c:41).
> 36 };
> 37
> 38 static int
> 39 crash_cli_cmd(int argc, char **argv)
> 40 {
> 41 if (argc >= 2 && crash_device(argv[1]) == 0) {
> 42 return 0;
> 43 }
> 44 console_printf("Usage crash [div0|jump0|ref0|assert|wdog]\n");
> 45 return 0;
> (gdb) list *0x14a21
> 0x14a21 is in crash_cli_cmd
> (repos/apache-mynewt-core/test/crash_test/src/crash_cli.c:41).
> 36 };
> 37
> 38 static int
> 39 crash_cli_cmd(int argc, char **argv)
> 40 {
> 41 if (argc >= 2 && crash_device(argv[1]) == 0) {
> 42 return 0;
> 43 }
> 44 console_printf("Usage crash [div0|jump0|ref0|assert|wdog]\n");
> 45 return 0;
>
> good luck.
>
>> On Aug 31, 2018, at 2:10 PM, Aditya Xavier <[email protected]>
>> wrote:
>>
>> 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.
>>>
>>>
>>
>
