Hi guys,
     I met a problem here and hop anyone can help. Thanks.

     I enable hardware control in menuconfig, build a firmware of hci_uart sample and burn the firmware into nrf52_pca10040 (nrf52832), 

(top menu) → Device Drivers → Serial Drivers → nRF UART nrfx drivers

                                                                     Zephyr Kernel Configuration

[*] UART Port 0 Driver type (nRF UART 0)  --->

[*] Enable interrupt support on port 0

[ ] Enable parity bit

[*] Enable flow control

 

and then connect it  with my NXP board via uart， tx rx rts cts,
but when I attach the ble with command hciattach, it prints time out and seems the uart cannot communicate.

root~# hciattach /dev/ttymxc2 any 115200

Device setup complete

root:~# Bluetooth: hci0 command 0x1003 tx timeout

root:~# Bluetooth: hci0 command 0x1001 tx timeout

root:~# Bluetooth: hci0 command 0x1009 tx timeout

Hi,

When could we expect that blemesh code will be usable in c++.
Most header files in zephyr are compatible with c++ but not ble mesh headers.
No #ifdef __cplusplus in headers.

Regards,
Robert

HI All,
Recently i have started working on Zephyr RTOS to explore IPV6 over BLE.And i am totally new this.
I would like to form a mesh network with PCA10059(5 boards) and PCA10040(1 boards) boards, and control the leds on boards.

Now, i have been successfully established connection with nordic board and PC and was getting proper response from device(If i ping from PC).
But i don't know how to control the LEDS.
I have seen a demo example in "net/leds_demo", with this can we make a mesh network and control the LEDS?
could you please help me to form a mesh network on IPV6 over BLE? if possible please suggest reference examples for nrf52 DK.
And i am total new to IPV6 over BLE to form mesh network, so please provide suitable explanation about IPV6 over BLE to form mesh network in Zephyr RTOS.    

Advance in thanks.

BR
Akash.

On 16/11/2018 17:28, Kumar Gala wrote:

Guys,
I’m looking to see if someone (or group) can help with maintenance of the Atmel SAMD2x SoC family. We have a few things that need updating (like the watchdog driver). And need someone I can check in w/from time to time if there are questions or we need testing on a board.
Let me know if you can help in the short term with converting drivers/watchdog/wdt_sam0.c to use the new watchdog API.
[ I also have a question about testing flash support ]

Hi,

Got buried in my inbox. Happy to help.

I'm currently winding down a project on the SAM21 - I was planning on looking at the USB.

I don't mind running some updates/tests/reviews as needed. Here to help, let me know what's required I can make time.

Hi,

On 23 Nov 2018, at 20.37, abaska@intermatic.com wrote:
I have a HCI host and controller setup. When the host starts, and the controller had already been running, it sometimes begins reading in the middle of a HCI message from the controller. It reads the wrong HCI message type and length. This causes the buffer to completely fill where it errors out in h4.c, read_payload(), BT_ERR("Not enough space in buffer"). After this the host application does not recover and a power cycle is needed.

I found a quick fix for this is to remove a line in h4.c read_payload(). I think it was meant to discard the rest of a message data if the buffer is full, but it looks like its assuming rx.remaining is valid. In this case, rx.remaining is invalid because it read the wrong byte as the length when it jumped into the middle of a HCI message.
if (rx.remaining > net_buf_tailroom(rx.buf)) {
BT_ERR("Not enough space in buffer");
//rx.discard = rx.remaining; // fixes issue. it was discarding thousands of bytes
reset_rx();
return;
}
I don't know what other consequences this quick fix will have. Is there a better way to fix this issue? Maybe check the message validity before it fills up the buffer?

Basically the code is assuming that the packet is valid, but the buffer sizes have simply been defined too small to fit the packet. In such a case discarding the rx.remaining bytes would be the correct thing since then the driver skips a valid but too long packet. In the case that you’re getting corrupt data (starting in the middle of a packet) it’s all a guessing game. You could discard everything indicated, like it does now, or try again with the next byte (in which case you’ll be repeating this until you get something that makes sense). Since the code needs to read (i.e. jump forward) at least the H4 + ACL/event headers, you don’t have any guarantee that you’ll ever hit a clean packet boundary.

I’m not sure there’s any correct answer in how the host should behave, since either way this is an unreliable setup: you should ideally design your device so that you can force a reset of the controller (e.g. by power-cycling it) so that you know you start off in a known state.

Johan

Hi,

I have a HCI host and controller setup. When the host starts, and the controller had already been running, it sometimes begins reading in the middle of a HCI message from the controller. It reads the wrong HCI message type and length. This causes the buffer to completely fill where it errors out in h4.c, read_payload(), BT_ERR("Not enough space in buffer"). After this the host application does not recover and a power cycle is needed.

I found a quick fix for this is to remove a line in h4.c read_payload(). I think it was meant to discard the rest of a message data if the buffer is full, but it looks like its assuming rx.remaining is valid. In this case, rx.remaining is invalid because it read the wrong byte as the length when it jumped into the middle of a HCI message.

Hi Martin,

There is an API to help parsing advertisements:

https://github.com/zephyrproject-rtos/zephyr/blob/master/include/bluetooth/bluetooth.h#L480

It will call the callback given for each data type found, for instance
the sample on the site has flags + manufacturer data, you probably are
only interested in the second. You can also parse the UUID using:

https://github.com/zephyrproject-rtos/zephyr/blob/master/include/bluetooth/uuid.h#L48

--
Luiz Augusto von Dentz

Sorry Joe, I will no longer this.
Thanks for reporting it.
Frank

--

Thanks you guys, it helps a lot. I think this will solve my problem, I will have a try then.

--

Hi icephyr,

I'm far from a Zephyr BLE expert, but I had this process in mind what could be a solution.

As Nordic doesn't store a public BLE device address in flash I would try to implement the following steps:

• store the public address in Nordic's UICR (http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fuicr.html), Example of writing via nrfjprog,  nrfjprog --memwr 0x10001208 --val 0xffffff00    See/search also the Nordic Dev zone for how to do read/write from UICR, eg. https://devzone.nordicsemi.com/f/nordic-q-a/18257/how-to-write-data-to-uicr-customer-registers
• not sure if this is the best implementation (place to add in code), but you could add to the hci_init() function (subsys/bluetooth/host/hci_core.c), see bt_setup_id_addr(), if no public address is set, to readout here the UICR (NRF_UCIR) as public address instead of the random address.

Good luck.

Best regards,
Frank

Hi guys,

    I met a problem and hope someone can help me here.

    I want to use nrf52832 as a tag device and can locate it by its mac address, so I have to flash pre-assigned static address into nrf52832 running zephyr project, since nrf chip don't have a pre-assigned mac address. 

    I wonder if there is any method to implement this function ? 

   Thanks  a lot if anyone can help.

Sorry, I was copying the wrong code..

int i;

//print adv. packet
for(i=0;i<buf->len;i++) {
printk("%d %02X\n",i, buf->data[i]);
}

//print major
printk("maj: %d\n",((buf->data[25] & 0xff) * 0x100 + (buf->data[26] & 0xff) ));
Am Mi., 21. Nov. 2018 um 18:12 Uhr schrieb Martin <ma@jgs-wg.de>:

Well, simple enough.

int i;

for(i=0; i<5; i++) {
printf("i%d\n", i+1);
}

prints the advertisement packet's bytes in decimals and includes the
UUID acc. to the kontakt.io article. Hope this helps anyone...

Martin
Am Mi., 21. Nov. 2018 um 17:56 Uhr schrieb Martin <ma@jgs-wg.de>:

Hi,
I am quite new to Zephyr and want to extract iBeacon Advertisement
Packets. I already have access to them as a net_buf_simple structure,
but I want to read the major and minor for example. I realize that I
have to probably read some certain bytes out of net_buf_simple
(according to https://support.kontakt.io/hc/en-gb/articles/201492492-Advertising-packet-structure).
Can someone point me to a direction (function) to do this?

Thanks,
Martin

Hi Luiz Augusto von Dentz,

Thank you very much for your reply. This should give me sufficient direction to go further. 

The idea for our BLE central oriented platform (two boards solution) is to run on the BLE Host board Linux and thus depending on BlueZ. The BLE controller runs on a Nordic board Zephyr (HCI_UART).
Both boards will be bridged via a HCI uart(h4) transport layer.

Our BLE peripheral oriented platform might be a pure single board Nordic BLE Host Controller approach depending on Nordic's SoftDevice for the BLE stack.

Best regards,
Frank