Hi While running the bluetooth sample "beacon" for the target qemu_x86, I get the following error Starting Beacon Demo Bluetooth initialized Beacon started [bt] [ERR] read_payload: Not enough

Hi When programming based on arduino 101, 1. How to choice the gpio? 2. What is the different between CONFIG_GPIO_QMSI_0_NAME and CONFIG_GPIO_QMSI_1_NAME? Thanks

Hi Scott,

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

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

Hi 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

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

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

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

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

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

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

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

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

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

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

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

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