This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

struct bt_conn issue, how to include conn_internal.h

1.) I used the sample code for BLE peripheral uart as template for my own project and modified it. I removed the nordic uart service "nus" and replaced it with a custom service "cus" - with a different UUID. My code compiles with warnings, in my custom.h file I have this:

struct bt_cus_cb
{
  void (*received)(struct bt_conn* conn, const uint8_t* const data, uint16_t len);
  void (*sent)(struct bt_conn* conn);
  void (*send_enabled)(enum bt_cus_send_status status);
};

the compiler complains : 'struct bt_conn' declared inside parameter list will not be visible outside of this definition or declaration

I found the declaration of bt_conn in conn_internal.h - but I'm not able to #include this file : whatever I tried, the compiler always says : conn_internal.h : no such file or directory - does anyone know how to do this ?

2.) I connected the Nordic serial RX/TX lines to a Raspberry PI in order to test my custom service. I'm using nRF connect for desktop together with a nRF52840 dongle. I can scan for the nordic chip and connect. Any data sent from the central (dongle) to the Nordic works well and is display on the Raspberry minicom console. The other direction, Raspberry => Nordic => custom service => Central usually works once, with the second attempt to send data it crashes like this:

[00:00:06.673,004] [0m<inf> fs_nvs: 6 Sectors of 4096 bytes[0m
[00:00:06.673,004] [0m<inf> fs_nvs: alloc wra: 0, fb8[0m
[00:00:06.673,034] [0m<inf> fs_nvs: data wra: 0, 4c[0m
[00:00:06.673,248] [0m<inf> sdc_hci_driver: SoftDevice Controller build revision:
                                         0e e7 c5 66 67 18 3c ac  b3 d2 cc 81 a3 dc f1 c0 |...fg.<. ........
                                         c0 36 02 22                                      |.6."             [0m
[00:00:06.680,694] [0m<inf> bt_hci_core: No ID address. App must call settings_load()[0m
[00:00:06.680,694] [0m<inf> peripheral_uart: Bluetooth initialized[0m
[00:00:06.697,845] [0m<inf> peripheral_uart: Connected C9:80:ED:68:20:3E (random)[0m
[00:00:21.930,725] [0m<inf> peripheral_uart: Sent data...[0m
[00:00:21.960,327] [0m<inf> peripheral_uart: Sent data...[0m
[00:00:24.900,451] [1;31m<err> os: r0/a1:  0x00000004  r1/a2:  0x000000a3  r2/a3:  0x2000363e[0m
[00:00:24.900,451] [1;31m<err> os: r3/a4:  0x00027f87 r12/ip:  0x00000000 r14/lr:  0x000118b1[0m
[00:00:24.900,451] [1;31m<err> os:  xpsr:  0x41000000[0m
[00:00:24.900,482] [1;31m<err> os: Faulting instruction address (r15/pc): 0x0002610e[0m
[00:00:24.900,482] [1;31m<err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0[0m
[00:00:24.900,482] [1;31m<err> os: Current thread: 0x200016a8 (unknown)[0m
[00:00:25.205,841] [1;31m<err> fatal_error: Resetting system

Maybe these 2 issues are related ? any ideas how to troubleshoot this ?
thanks, Matthias

Parents
  • I was able to find and fix the crash, which is not related to BLE - but happens because of the (stupid) code in uart_cb().

    When incoming UART data is received the coder enters the case UART_RX_RDY and then checks if the last character was LF or CR - and this code does not check for (buf->len == 0) which can happen. I also noticed that this buffer management (allocate and release) only works well if 1 char per time is inserted in the fifo. Trying to insert a whole message works once, and then the release mgmt seems to go bad.

    This same sample code is used in central_uart and in peripheral_uart. Since the sample documentation suggests to use a Rxd-Txd loopback between the chip's pins, this crash is not showing up.

    If ever anyone would have tested these UART samples with a real serial-UART connection to another device and a stupid user like me at the other end, the problem would show up

Reply
  • I was able to find and fix the crash, which is not related to BLE - but happens because of the (stupid) code in uart_cb().

    When incoming UART data is received the coder enters the case UART_RX_RDY and then checks if the last character was LF or CR - and this code does not check for (buf->len == 0) which can happen. I also noticed that this buffer management (allocate and release) only works well if 1 char per time is inserted in the fifo. Trying to insert a whole message works once, and then the release mgmt seems to go bad.

    This same sample code is used in central_uart and in peripheral_uart. Since the sample documentation suggests to use a Rxd-Txd loopback between the chip's pins, this crash is not showing up.

    If ever anyone would have tested these UART samples with a real serial-UART connection to another device and a stupid user like me at the other end, the problem would show up

Children
No Data
Related