Hi Vinayak, > I assume, you mean, you are using nRF52832 chip and your custom board; and using a Zephyr build using the BOARD=nrf52_pca10040. > Do you have the 32KHz crystal mounted in your custom

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

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

Hi, 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 have no experience myself with OpenOCD, I always have used our DK

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

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

Hello, I've observed the same issue on 96b_carbon while trying to communicate over I2C_1. In polling mode, it looks like carbon sends slave address and waits forever for the status of address sent in

Hi, I just test I2C_1 using the latest master branch. I am driving an oled display using I2C_1 on 96b_carbon just fine in both interrupt and polling modes. Does interrupt mode works for you? Yannis

yikes... I was connecting to PB8/PB9 by looking at the pinout. But the default pinmux is configured for PB6/PB7 and it works with the same. It looks confusing with having two different I2C_1 labels in

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

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

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

Hi Scott, 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

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

Nice! May I ask if there where any preceding console messages? usually, the assert condition is printed along with the function name. -Vinayak

Hi Scott, 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

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

[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.

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

Hi Scott,