We try to keep the stack sizes really small in order to conserve memory for constrained platforms. The controller stack is pretty small and it gets pretty close to the bottom. Furthermore, it is a bit of difficult task to test every combination of system configuration variable so I would not be terribly surprised if there is a combination that can exceed the stack.
It would be great if you could post to the list your target and/or system configuration variables you might have changed along with what was happening at the time (if you know) so the controller stack size can be adjusted accordingly. You can easily tell if the stack overflowed; just look at the bottom of the stack and if 0xdeadbeef is not there it overflowed. The controller stack is called g_ble_ll_stack. If you are in gdb you can do this: x/32wx g_ble_ll_stack and it should show 0xdeadbeef for some amount of words. What platform are you running this on Pritish? > On Apr 19, 2017, at 2:14 AM, Andrey Serdtsev > <[email protected]> wrote: > > Well, recently I've also get stack corruption: 80 dwords for BLE controller's > LL task was too low value. Increasing it to 128 works for me. > I'm in doubt, in theory this should be the common case, but de-facto it's > not. Possibly your exception is related to the case. Anyway, this requires > more analysis. > > BR, > Andrey > > On 19.04.2017 01:20, Pritish Gandhi wrote: >> Hi All, >> I have leveraged the blecent demo application to build a BLE gateway type >> application. It works great most of the time but rarely I see a crash which >> I could really use some help debugging. >> >> Console logs: >> 18286:[ts=18286000ssb, mod=4 level=1] GATT procedure initiated: read; >> att_handle=43 >> 18293:[ts=18293000ssb, mod=4 level=1] GATT procedure initiated: write; >> att_handle=44 len=2 >> 18529:Unhandled interrupt (3), exception sp 0x10000760 >> 18529: r0:0x100007a7 r1:0x20017d91 r2:0x20008534 r3:0x10010001 >> 18529: r4:0x0000001c r5:0xfffffffe r6:0x00000001 r7:0x100007a7 >> 18529: r8:0x00000000 r9:0x00000000 r10:0x10000000 r11:0x00000000 >> 18529:r12:0x10000648 lr:0x08023753 pc:0x08025df6 psr:0x21000200 >> 18529:ICSR:0x0440f803 HFSR:0x40000000 CFSR:0x00000400 >> 18529:BFAR:0xe000ed38 MMFAR:0xe000ed34 >> >> (gdb) list *0x08025df6 >> 0x8025df6 is in memcpy (memcpy.c:23). >> 18 size_t nq = n >> 3; >> 19 asm volatile ("cld ; rep ; movsq ; movl %3,%%ecx ; rep ; movsb":"+c" >> 20 (nq), "+S"(p), "+D"(q) >> 21 :"r"((uint32_t) (n & 7))); >> 22 #else >> 23 while (n--) { >> 24 *q++ = *p++; >> 25 } >> 26 #endif >> 27 >> (gdb) list *0x08023753 >> 0x8023753 is in os_mbuf_copydata (os_mbuf.c:722). >> 717 m = SLIST_NEXT(m, om_next); >> 718 } >> 719 while (len > 0 && m != NULL) { >> 720 count = min(m->om_len - off, len); >> 721 memcpy(udst, m->om_data + off, count); >> 722 len -= count; >> 723 udst += count; >> 724 off = 0; >> 725 m = SLIST_NEXT(m, om_next); >> 726 } >> >> Dumping more from the stack from the crash log: >> >> (gdb) x/20wx 0x10000760 >> 0x10000760 <ble_gateway_stack+1888>: 0x100007a7 0x20017d91 0x20008534 >> 0x10010001 >> 0x10000770 <ble_gateway_stack+1904>: 0x10000648 0x08023753 0x08025df6 >> 0x21000200 >> 0x10000780 <ble_gateway_stack+1920>: 0x08023738 0x20008514 0x00000002 >> 0x20008514 >> 0x10000790 <ble_gateway_stack+1936>: 0x00000001 0x00000000 0x00000000 >> 0x0802c055 >> 0x100007a0 <ble_gateway_stack+1952>: 0x00000000 0x0502bf6f 0x04000100 >> 0x00501300 >> (gdb) >> 0x100007b0 <ble_gateway_stack+1968>: 0x00220000 0xe3df95b1 0x8210d712 >> 0x65664608 >> 0x100007c0 <ble_gateway_stack+1984>: 0x1950c6c9 0x5fb80fba 0x01021fd0 >> 0x10020305 >> 0x100007d0 <ble_gateway_stack+2000>: 0x000000f1 0x00000000 0x00000000 >> 0x00000000 >> 0x100007e0 <ble_gateway_stack+2016>: 0x00000000 0x00000000 0x3e04bc00 >> 0x0001022b >> 0x100007f0 <ble_gateway_stack+2032>: 0xb8158700 0x1ff4f5d8 0x03060102 >> 0x17fe9f03 >> >> It seems like the caller is: >> (gdb) list *0x0802c055 >> 0x802c055 is in ble_hs_log_mbuf (ble_hs_log.c:31). >> 26 ble_hs_log_mbuf(const struct os_mbuf *om) >> 27 { >> 28 uint8_t u8; >> 29 int i; >> 30 >> 31 for (i = 0; i < OS_MBUF_PKTLEN(om); i++) { >> 32 os_mbuf_copydata(om, i, 1, &u8); >> 33 BLE_HS_LOG(DEBUG, "0x%02x ", u8); >> 34 } >> 35 } >> >> But notice that I cannot trace back further to who called ble_hs_log_mbuf() >> because it seems like >> the stack has been trashed!! >> >> Any help is appreciated. >> Thanks, >> Pritish >> >
