Debugging NRF51822 (OpenOCD + GDB)


Scott Nelson <scott@...>
 

Hello,

I wrote into the list about an issue I was having with an NRF51822 board a couple days ago. It’s occasionally ending up in _SysFatalErrorHandler but I’m still not sure why (though I suspect it may be something BLE related). I’m trying to attach a debugger with the ultimate goal of printing a stack trace when the code ends up in the error handler. First I’m starting an OpenOCD server:

$ openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg

And then trying to connect GDB:

$ arm-none-eabi-gdb outdir/nrf51_blenano/zephyr.elf
(gdb) set verbose on
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
Reading in symbols for /Users/scott/Code/bms/zephyr/lib/libc/minimal/source/stdout/fprintf.c...done.
fprintf (F=<optimized out>, Abort trap: 6

The OpenOCD logs show:

accepting 'gdb' connection on tcp/3333
dropped 'gdb' connection

Any idea why I’m getting this error? I’m new to OpenOCD and GDB so I’m not sure if this is an issue with my toolchain setup or if it is something related to Zephyr. Any help would be much appreciated!

Thanks,
Scott


Carles Cufi
 

Hi Scott,

I don’t know why you are getting the gdb error (here at Nordic we all use Segger debug ICs), but if the _SysFatalErrorHandler is getting called because of BLE then it’s highly likely that there is a preceding printk() statement giving the cause. I understand you don’t have a serial port connected, so could you try enabling the RAM console and dumping the memory with gdb once you hit the fatal error?

You should be able to do so with this option:
https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/console/Kconfig#L106

Regards,

Carles

On 22/08/2017, 21:16, "zephyr-users-bounces@lists.zephyrproject.org on behalf of Scott Nelson" <zephyr-users-bounces@lists.zephyrproject.org on behalf of scott@scottnelson.co> wrote:

Hello,

I wrote into the list about an issue I was having with an NRF51822 board a couple days ago. It’s occasionally ending up in _SysFatalErrorHandler but I’m still not sure why (though I suspect it may be something BLE related). I’m trying to attach a debugger with the ultimate goal of printing a stack trace when the code ends up in the error handler. First I’m starting an OpenOCD server:

$ openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg

And then trying to connect GDB:

$ arm-none-eabi-gdb outdir/nrf51_blenano/zephyr.elf
(gdb) set verbose on
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
Reading in symbols for /Users/scott/Code/bms/zephyr/lib/libc/minimal/source/stdout/fprintf.c...done.
fprintf (F=<optimized out>, Abort trap: 6

The OpenOCD logs show:

accepting 'gdb' connection on tcp/3333
dropped 'gdb' connection

Any idea why I’m getting this error? I’m new to OpenOCD and GDB so I’m not sure if this is an issue with my toolchain setup or if it is something related to Zephyr. Any help would be much appreciated!

Thanks,
Scott
_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Chettimada, Vinayak Kariappa
 

Hi,


I wrote into the list about an issue I was having with an NRF51822 board a couple days ago. It’s occasionally ending up in _SysFatalErrorHandler but I’m still not sure why (though I suspect it may be something BLE related).
I can help you if its an issue with BLE, can you give details of the application you are using and the symptoms of the issue?

I’m trying to attach a debugger with the ultimate goal of printing a stack trace when the code ends up in the error handler. First I’m starting an OpenOCD server:

$ openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg

And then trying to connect GDB:

$ arm-none-eabi-gdb outdir/nrf51_blenano/zephyr.elf
(gdb) set verbose on
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
Reading in symbols for /Users/scott/Code/bms/zephyr/lib/libc/minimal/source/stdout/fprintf.c...done.
fprintf (F=<optimized out>, Abort trap: 6

The OpenOCD logs show:

accepting 'gdb' connection on tcp/3333
dropped 'gdb' connection

Any idea why I’m getting this error? I’m new to OpenOCD and GDB so I’m not sure if this is an issue with my toolchain setup or if it is something related to Zephyr. Any help would be much appreciated!
I have no experience myself with OpenOCD, I always have used our DK boards with JLinkGDBServer or pyocd-gdbserver (mbed debugger host firmware).

Thanks,
Scott
_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Scott Nelson <scott@...>
 

I’ve previously left it with a serial port connected but, oddly, it never ends up in the _SysFatalErrorHandler when I do that. I currently turn on an LED so I know when the code has entered _SysFatalErrorHandler and was hoping to connect the debugger after the fact. I’ll look into the RAM console. Thanks.

-Scott

On Aug 22, 2017, at 3:25 PM, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi Scott,

I don’t know why you are getting the gdb error (here at Nordic we all use Segger debug ICs), but if the _SysFatalErrorHandler is getting called because of BLE then it’s highly likely that there is a preceding printk() statement giving the cause. I understand you don’t have a serial port connected, so could you try enabling the RAM console and dumping the memory with gdb once you hit the fatal error?

You should be able to do so with this option:
https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/console/Kconfig#L106

Regards,

Carles

On 22/08/2017, 21:16, "zephyr-users-bounces@lists.zephyrproject.org on behalf of Scott Nelson" <zephyr-users-bounces@lists.zephyrproject.org on behalf of scott@scottnelson.co> wrote:

Hello,

I wrote into the list about an issue I was having with an NRF51822 board a couple days ago. It’s occasionally ending up in _SysFatalErrorHandler but I’m still not sure why (though I suspect it may be something BLE related). I’m trying to attach a debugger with the ultimate goal of printing a stack trace when the code ends up in the error handler. First I’m starting an OpenOCD server:

$ openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg

And then trying to connect GDB:

$ arm-none-eabi-gdb outdir/nrf51_blenano/zephyr.elf
(gdb) set verbose on
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
Reading in symbols for /Users/scott/Code/bms/zephyr/lib/libc/minimal/source/stdout/fprintf.c...done.
fprintf (F=<optimized out>, Abort trap: 6

The OpenOCD logs show:

accepting 'gdb' connection on tcp/3333
dropped 'gdb' connection

Any idea why I’m getting this error? I’m new to OpenOCD and GDB so I’m not sure if this is an issue with my toolchain setup or if it is something related to Zephyr. Any help would be much appreciated!

Thanks,
Scott
_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Scott Nelson <scott@...>
 

On Aug 22, 2017, at 3:27 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi,


I wrote into the list about an issue I was having with an NRF51822 board a couple days ago. It’s occasionally ending up in _SysFatalErrorHandler but I’m still not sure why (though I suspect it may be something BLE related).
I can help you if its an issue with BLE, can you give details of the application you are using and the symptoms of the issue?
My hunch that it’s BLE related is very anecdotal (I did not notice the issue before adding the BLE component). Probably not worth pursuing this hunch too far until I can figure out what code is causing the fatal error. My code configures a single BLE peripheral and periodically calls bt_gatt_notify.


I’m trying to attach a debugger with the ultimate goal of printing a stack trace when the code ends up in the error handler. First I’m starting an OpenOCD server:

$ openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg

And then trying to connect GDB:

$ arm-none-eabi-gdb outdir/nrf51_blenano/zephyr.elf
(gdb) set verbose on
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
Reading in symbols for /Users/scott/Code/bms/zephyr/lib/libc/minimal/source/stdout/fprintf.c...done.
fprintf (F=<optimized out>, Abort trap: 6

The OpenOCD logs show:

accepting 'gdb' connection on tcp/3333
dropped 'gdb' connection

Any idea why I’m getting this error? I’m new to OpenOCD and GDB so I’m not sure if this is an issue with my toolchain setup or if it is something related to Zephyr. Any help would be much appreciated!
I have no experience myself with OpenOCD, I always have used our DK boards with JLinkGDBServer or pyocd-gdbserver (mbed debugger host firmware).

Thanks,
Scott
_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Scott Nelson <scott@...>
 

OK, I finally was able to catch the fault while I had a serial console connected and here’s what I saw:

***** HARD FAULT *****
Executing thread ID (thread): 0x20001908
Faulting instruction address: 0xbc76

What do I do with that info? Is there a way to determine what code corresponds to that address?

Thanks!

-Scott

On Aug 22, 2017, at 3:27 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi,


I wrote into the list about an issue I was having with an NRF51822 board a couple days ago. It’s occasionally ending up in _SysFatalErrorHandler but I’m still not sure why (though I suspect it may be something BLE related).
I can help you if its an issue with BLE, can you give details of the application you are using and the symptoms of the issue?

I’m trying to attach a debugger with the ultimate goal of printing a stack trace when the code ends up in the error handler. First I’m starting an OpenOCD server:

$ openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg

And then trying to connect GDB:

$ arm-none-eabi-gdb outdir/nrf51_blenano/zephyr.elf
(gdb) set verbose on
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
Reading in symbols for /Users/scott/Code/bms/zephyr/lib/libc/minimal/source/stdout/fprintf.c...done.
fprintf (F=<optimized out>, Abort trap: 6

The OpenOCD logs show:

accepting 'gdb' connection on tcp/3333
dropped 'gdb' connection

Any idea why I’m getting this error? I’m new to OpenOCD and GDB so I’m not sure if this is an issue with my toolchain setup or if it is something related to Zephyr. Any help would be much appreciated!
I have no experience myself with OpenOCD, I always have used our DK boards with JLinkGDBServer or pyocd-gdbserver (mbed debugger host firmware).

Thanks,
Scott
_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Boie, Andrew P
 

OK, I finally was able to catch the fault while I had a serial console connected
and here’s what I saw:

***** HARD FAULT *****
Executing thread ID (thread): 0x20001908
Faulting instruction address: 0xbc76

What do I do with that info? Is there a way to determine what code
corresponds to that address?
Yes, the addr2line tool will show you this, if you run it on the zephyr.elf binary.
https://sourceware.org/binutils/docs/binutils/addr2line.html

Andrew


Scott Nelson <scott@...>
 

Thanks everyone! Learning a lot here.

Here’s what I get:

$ arm-none-eabi-addr2line -f -e outdir/nrf51_blenano/zephyr.elf 0xbc76
radio_event_adv_prepare.part.31
errno.c:?

I tried disassembling the object file that contains the radio_event_adv_prepare function:

$ arm-none-eabi-objdump -z -S outdir/nrf51_blenano/subsys/bluetooth/controller/ll_sw/ctrl.o

I didn’t see 0xbc76 in there though. Here’s the output for that section:

00000000 <radio_event_adv_prepare>:
0: b57f push {r0, r1, r2, r3, r4, r5, r6, lr}
__ASM volatile ("sev");
2: 4c0b ldr r4, [pc, #44] ; (30 <radio_event_adv_prepare+0x30>)
__ASM volatile ("wfe");
4: 7b25 ldrb r5, [r4, #12]
6: b2ed uxtb r5, r5
*((u32_t volatile *)ops_context) = status;
8: 2d00 cmp r5, #0
}
a: d001 beq.n 10 <radio_event_adv_prepare+0x10>
if (status == 0) {
c: f7ff fffe bl 0 <radio_event_adv_prepare>
hdr->ticks_xtal_to_start |= ((u32_t)1 << 31);
10: 2605 movs r6, #5
12: 0023 movs r3, r4
14: 0022 movs r2, r4
16: 7326 strb r6, [r4, #12]
18: 9503 str r5, [sp, #12]
}
1a: 4d06 ldr r5, [pc, #24] ; (34 <radio_event_adv_prepare+0x34>)
if (status == 0) {
1c: 9601 str r6, [sp, #4]
1e: 9502 str r5, [sp, #8]
hdr->ticks_xtal_to_start &= ~((u32_t)1 << 31);
20: 69e4 ldr r4, [r4, #28]
22: 3318 adds r3, #24
24: 3214 adds r2, #20
26: 9400 str r4, [sp, #0]
}
28: f7ff fffe bl 0 <radio_event_adv_prepare>
{
2c: bd7f pop {r0, r1, r2, r3, r4, r5, r6, pc}
2e: 46c0 nop ; (mov r8, r8)
if (bite & 0x01) {
30: 00000000 .word 0x00000000
while (byte_count--) {
34: 00000000 .word 0x00000000

When I manually looked through the zephyr.map file I found this:

.text.event_scan_prepare.part.32
0x000000000000bc70 0x6 subsys/built-in.o
*fill* 0x000000000000bc76 0x2

It now seems clear to me that the fault is BLE related but I’m not sure how to find the exact line or cause. Thanks again for your ongoing help and patience!

-Scott

On Aug 24, 2017, at 12:25 PM, Boie, Andrew P <andrew.p.boie@intel.com> wrote:

OK, I finally was able to catch the fault while I had a serial console connected
and here’s what I saw:

***** HARD FAULT *****
Executing thread ID (thread): 0x20001908
Faulting instruction address: 0xbc76

What do I do with that info? Is there a way to determine what code
corresponds to that address?
Yes, the addr2line tool will show you this, if you run it on the zephyr.elf binary.
https://sourceware.org/binutils/docs/binutils/addr2line.html

Andrew


Marti Bolivar <marti.bolivar@...>
 

Hi Scott,

On 24 August 2017 at 18:24, Scott Nelson <scott@...> wrote:

I tried disassembling the object file that contains the radio_event_adv_prepare function:

$ arm-none-eabi-objdump -z -S outdir/nrf51_blenano/subsys/bluetooth/controller/ll_sw/ctrl.o

I didn’t see 0xbc76 in there though. 

There should be an outdir/zephyr.lst file in your build directory. This contains a disassembly of the final executable. You may have better luck searching for that address in there.

Marti
 


Scott Nelson <scott@...>
 

Ahha! I found this in there:

0000bc70 <chan_set.part.23>:
LL_ASSERT(!_radio.ticker_id_prepare);
bc70: b662 cpsie i
bc72: 2004 movs r0, #4
bc74: df02 svc 2


I think the “…" is displayed when that address is just zeros?

When I look through the code that I’m running though I do not see "LL_ASSERT(!_radio.ticker_id_prepare);” inside “chan_set”. I do see calls to "LL_ASSERT(!_radio.ticker_id_prepare);” in “radio_event_adv_prepare” and “event_scan_prepare”. Here’s the version I’m running: https://github.com/zephyrproject-rtos/zephyr/blob/dd52b8ea02da44b58dd16b8304fec16a15b24648/subsys/bluetooth/controller/ll_sw/ctrl.c

-Scott

On Aug 24, 2017, at 6:38 PM, Marti Bolivar <marti.bolivar@linaro.org> wrote:

Hi Scott,

On 24 August 2017 at 18:24, Scott Nelson <scott@scottnelson.co> wrote:

I tried disassembling the object file that contains the radio_event_adv_prepare function:

$ arm-none-eabi-objdump -z -S outdir/nrf51_blenano/subsys/bluetooth/controller/ll_sw/ctrl.o

I didn’t see 0xbc76 in there though.

There should be an outdir/zephyr.lst file in your build directory. This contains a disassembly of the final executable. You may have better luck searching for that address in there.

Marti


Chettimada, Vinayak Kariappa
 

On 24 Aug 2017, at 17:21, Scott Nelson <scott@scottnelson.co> wrote:

OK, I finally was able to catch the fault while I had a serial console connected and here’s what I saw:

***** HARD FAULT *****
Executing thread ID (thread): 0x20001908
Faulting instruction address: 0xbc76
Nice! May I ask if there where any preceding console messages? usually, the assert condition is printed along with the function name.

-Vinayak


Chettimada, Vinayak Kariappa
 

Hi Scott,

On 25 Aug 2017, at 05:23, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:


On 24 Aug 2017, at 17:21, Scott Nelson <scott@scottnelson.co> wrote:

OK, I finally was able to catch the fault while I had a serial console connected and here’s what I saw:

***** HARD FAULT *****
Executing thread ID (thread): 0x20001908
Faulting instruction address: 0xbc76
Nice! May I ask if there where any preceding console messages? usually, the assert condition is printed along with the function name.
If I where to force an assert (break the design), this is how I would get (for samples/bluetooth/peripheral on my local repo):

[bt] [INF] show_dev_info: Identity: da:d7:35:42:55:80 (random)
[2017-08-25 05:28:18.771] [bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0xffff
[2017-08-25 05:28:18.779] [bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
[2017-08-25 05:28:18.785] [bt] [WRN] bt_pub_key_gen: ECC HCI commands not available
[2017-08-25 05:28:18.797] [bt] [WRN] irk_init: Using temporary IRK
[2017-08-25 05:28:18.802] Bluetooth initialized
[2017-08-25 05:28:18.806] Advertising successfully started
[2017-08-25 05:28:18.913] [bt] [ERR] radio_event_adv_prepare: assert: '!_radio.ticker_id_prepare' failed
[2017-08-25 05:28:18.920] ***** HARD FAULT *****
[2017-08-25 05:28:18.922] Executing thread ID (thread): 0x200021a4
[2017-08-25 05:28:18.926] Faulting instruction address: 0xf7be
[2017-08-25 05:28:18.930] Fatal fault in ISR! Spinning...


and,

arm-none-eabi-addr2line -afie samples/bluetooth/peripheral/outdir/nrf51_pca10028/zephyr.elf 0xf7be
0x0000f7be
radio_event_adv_prepare
/Users/hemal/workspace/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c:5551

and the line in the source file:

5541
5542 void radio_event_adv_prepare(u32_t ticks_at_expire, u32_t remainder,
5543 u16_t lazy, void *context)
5544 {
5545 ARG_UNUSED(lazy);
5546 ARG_UNUSED(context);
5547
5548 DEBUG_RADIO_PREPARE_A(1);
5549
5550 LL_ASSERT(!_radio.ticker_id_prepare);
5551 _radio.ticker_id_prepare = RADIO_TICKER_ID_ADV;
5552


The faulting instruction address corresponds to the next program counter, hence the line number given is next line in c source code.


Could you please give details on how I can reproduce the hardfault, I do not have a ble_nano (16 KB RAM nRF51), but pca10028 boards should have a similar nRF51 (32 KB RAM).

Hmmmm…. I see Kconfig.defconfig.nrf51822_QFAA has:
15 config ISR_STACK_SIZE
16 default 640

Could you please use 1024 bytes, and give a try, if your observation is related to insufficient ISR call stack? (pong sample of the micro:bit uses 1024, maybe for a reason!).

-Vinayak

_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Scott Nelson <scott@...>
 

I forced an assert in radio_event_adv_prepare by setting "_radio.tocker_id_prepare = 1”. All I see is:

***** HARD FAULT *****
Executing thread ID (thread): 0x200007a8
Faulting instruction address: 0xbc76

No additional logging.

I tried setting the ISR stack size to 1024 and got the same result when explicitly triggering the assert. I’ll let it sit for a while during normal operation and see if I see the real error show up (it’s very intermittent).

-Scott

On Aug 24, 2017, at 11:55 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi Scott,

On 25 Aug 2017, at 05:23, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:


On 24 Aug 2017, at 17:21, Scott Nelson <scott@scottnelson.co> wrote:

OK, I finally was able to catch the fault while I had a serial console connected and here’s what I saw:

***** HARD FAULT *****
Executing thread ID (thread): 0x20001908
Faulting instruction address: 0xbc76
Nice! May I ask if there where any preceding console messages? usually, the assert condition is printed along with the function name.
If I where to force an assert (break the design), this is how I would get (for samples/bluetooth/peripheral on my local repo):

[bt] [INF] show_dev_info: Identity: da:d7:35:42:55:80 (random)
[2017-08-25 05:28:18.771] [bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0xffff
[2017-08-25 05:28:18.779] [bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
[2017-08-25 05:28:18.785] [bt] [WRN] bt_pub_key_gen: ECC HCI commands not available
[2017-08-25 05:28:18.797] [bt] [WRN] irk_init: Using temporary IRK
[2017-08-25 05:28:18.802] Bluetooth initialized
[2017-08-25 05:28:18.806] Advertising successfully started
[2017-08-25 05:28:18.913] [bt] [ERR] radio_event_adv_prepare: assert: '!_radio.ticker_id_prepare' failed
[2017-08-25 05:28:18.920] ***** HARD FAULT *****
[2017-08-25 05:28:18.922] Executing thread ID (thread): 0x200021a4
[2017-08-25 05:28:18.926] Faulting instruction address: 0xf7be
[2017-08-25 05:28:18.930] Fatal fault in ISR! Spinning...


and,

arm-none-eabi-addr2line -afie samples/bluetooth/peripheral/outdir/nrf51_pca10028/zephyr.elf 0xf7be
0x0000f7be
radio_event_adv_prepare
/Users/hemal/workspace/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c:5551

and the line in the source file:

5541
5542 void radio_event_adv_prepare(u32_t ticks_at_expire, u32_t remainder,
5543 u16_t lazy, void *context)
5544 {
5545 ARG_UNUSED(lazy);
5546 ARG_UNUSED(context);
5547
5548 DEBUG_RADIO_PREPARE_A(1);
5549
5550 LL_ASSERT(!_radio.ticker_id_prepare);
5551 _radio.ticker_id_prepare = RADIO_TICKER_ID_ADV;
5552


The faulting instruction address corresponds to the next program counter, hence the line number given is next line in c source code.


Could you please give details on how I can reproduce the hardfault, I do not have a ble_nano (16 KB RAM nRF51), but pca10028 boards should have a similar nRF51 (32 KB RAM).

Hmmmm…. I see Kconfig.defconfig.nrf51822_QFAA has:
15 config ISR_STACK_SIZE
16 default 640

Could you please use 1024 bytes, and give a try, if your observation is related to insufficient ISR call stack? (pong sample of the micro:bit uses 1024, maybe for a reason!).

-Vinayak

_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Chettimada, Vinayak Kariappa
 

I forced an assert in radio_event_adv_prepare by setting
"_radio.tocker_id_prepare = 1”. All I see is:

***** HARD FAULT *****
Executing thread ID (thread): 0x200007a8
Faulting instruction address: 0xbc76

No additional logging.
[vich]
Are you using the upstream master as-is? Or you have modified the default configurations?
BT_ERR message when ASSERTing should be printed out on UART by default for the peripheral sample.


Scott Nelson <scott@...>
 

I’m using an unmodified master as of revision 2de5902. Here’s the full code for the project I’m working on: https://github.com/scttnlsn/bms

Thanks!

-Scott

On Aug 25, 2017, at 9:31 AM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

I forced an assert in radio_event_adv_prepare by setting
"_radio.tocker_id_prepare = 1”. All I see is:

***** HARD FAULT *****
Executing thread ID (thread): 0x200007a8
Faulting instruction address: 0xbc76

No additional logging.
[vich]
Are you using the upstream master as-is? Or you have modified the default configurations?
BT_ERR message when ASSERTing should be printed out on UART by default for the peripheral sample.


Carles Cufi
 

Hi Scott,

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-
bounces@lists.zephyrproject.org] On Behalf Of Scott Nelson
Sent: 25 August 2017 15:38
To: Chettimada, Vinayak Kariappa
<vinayak.kariappa.chettimada@nordicsemi.no>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Debugging NRF51822 (OpenOCD + GDB)

I’m using an unmodified master as of revision 2de5902. Here’s the full
code for the project I’m working on: https://github.com/scttnlsn/bms
Let's make this simple. Can you replace BT_ERR with printk in:
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/common/log.h#L93

Thanks,

Carles


Chettimada, Vinayak Kariappa
 

Ah… I see your revision is older than a controller regression fix done in cb90fbe56.
The symptom was the exact assert as you see, around ~8 mins interval from power up.

Please use latest revision and let me know if you still see assert.
But its weird you don’t get logs from your application.

On 25 Aug 2017, at 15:38, Scott Nelson <scott@scottnelson.co> wrote:

I’m using an unmodified master as of revision 2de5902. Here’s the full code for the project I’m working on: https://github.com/scttnlsn/bms

Thanks!

-Scott

On Aug 25, 2017, at 9:31 AM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

I forced an assert in radio_event_adv_prepare by setting
"_radio.tocker_id_prepare = 1”. All I see is:

***** HARD FAULT *****
Executing thread ID (thread): 0x200007a8
Faulting instruction address: 0xbc76

No additional logging.
[vich]
Are you using the upstream master as-is? Or you have modified the default configurations?
BT_ERR message when ASSERTing should be printed out on UART by default for the peripheral sample.


Scott Nelson <scott@...>
 

Updating the Zephyr code seemed to have resolved the issue entirely. Thanks!

-Scott

On Aug 25, 2017, at 10:28 AM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Ah… I see your revision is older than a controller regression fix done in cb90fbe56.
The symptom was the exact assert as you see, around ~8 mins interval from power up.

Please use latest revision and let me know if you still see assert.
But its weird you don’t get logs from your application.

On 25 Aug 2017, at 15:38, Scott Nelson <scott@scottnelson.co> wrote:

I’m using an unmodified master as of revision 2de5902. Here’s the full code for the project I’m working on: https://github.com/scttnlsn/bms

Thanks!

-Scott

On Aug 25, 2017, at 9:31 AM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

I forced an assert in radio_event_adv_prepare by setting
"_radio.tocker_id_prepare = 1”. All I see is:

***** HARD FAULT *****
Executing thread ID (thread): 0x200007a8
Faulting instruction address: 0xbc76

No additional logging.
[vich]
Are you using the upstream master as-is? Or you have modified the default configurations?
BT_ERR message when ASSERTing should be printed out on UART by default for the peripheral sample.


Carles Cufi
 

Hi Scott,

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-
bounces@lists.zephyrproject.org] On Behalf Of Scott Nelson
Sent: 28 August 2017 15:15
To: Chettimada, Vinayak Kariappa
<vinayak.kariappa.chettimada@nordicsemi.no>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Debugging NRF51822 (OpenOCD + GDB)

Updating the Zephyr code seemed to have resolved the issue entirely.
Thanks!
That's good news, we fixed this issue, which also affected the nRF52 ICs that Linaro use for their distributed testing, in preparation for the 1.9 release, and was hoping that this would be the same. Sorry for the initial confusion.

Carles