Central UART on 52840 dongle

[babos]

Hello everybody,
i am trying to use BLE central uart sample software in zephyr, on nrf52840 dongle. I mapped the uart outputs on pins 20 and 24 of the connector, made the loaded board or the S140 softdevice insecure and flashed via Visual Studio Code and Jlink via the programming socket on the 10 pin dongle board.
This is the result on the terminal:

*** Booting Zephyr OS build v3.0.99-ncs1  ***
Starting Bluetooth Central UART example
[Disconnected]
[Connected]

on JlinkRTTView:

00> [00:00:32.617,645] <inf> central_uart: Disconnected: D4:F0:2B:4E:B1:6D (random) (reason 8)
00> [00:00:34.202,667] <inf> central_uart: Filters matched. Address: D4:F0:2B:4E:B1:6D (random) connectable: 0
00> [00:00:35.208,679] <inf> central_uart: Connected: D4:F0:2B:4E:B1:6D (random)
00> [00:00:35.409,942] <inf> central_uart: MTU exchange done

so everything seems ok, however, the strings that I send from the peripheral via BLE do not arrive (I do not see) on the uart terminal or on the RTT; what am I doing wrong ?

Obviously the connection takes place and if I do it from a smartphone with nrftool I see the incoming strings and transmit.

(if I do the same thing using a nrf52840DK everything works and there is the transmission but I should use it on the dongle ...)

thank you
Silvio

[Simon]

so everything seems ok, however, the strings that I send from the peripheral via BLE do not arrive (I do not see) on the uart terminal or on the RTT; what am I doing wrong ?

• Could you upload a sniffer trace? Then we can see exactly what is going on
• You can aslo try to enable more logging in the Bluetooth libraries and see if you get some more information. Set CONFIG_BT_DEBUG_GATT=y and CONFIG_BT_NUS_CLIENT_LOG_LEVEL=y

Best regards,

Simon

[babos]

Hi Simon,

it is nice to hear you again.
I use the 2.x.x toolchain, CONFIG_BT_DEBUG_GATT = y is already inserted as ure the log level of the NUS_CLIENT, apparently and even circuitally there are no errors and the dk and the dongle are more or less similar. I think it may be some GPIO setting or CTS or RTS flow control working differently ..: /
I can't find configurations to rule out any hardware flow control, as you know, I'm not very familiar with Zepkyr yet.
If I compile on DK everything works fine. It appears that the callbacks on the dongle are disabled.

[babos]

for convenience I diverted the debugs on the shell of the serial port pin 20 and 24 of the dongle 52840

[00:00:00.012,023] <inf> fs_nvs: 4 Sectors of 4096 bytes

[00:00:00.012,054] <inf> fs_nvs: alloc wra: 0, fe8

[00:00:00.012,054] <inf> fs_nvs: data wra: 0, 0

[00:00:00.017,303] <inf> central_uart: Bluetooth initialized

[00:00:00.019,439] <inf> central_uart: Scan module initialized

[00:00:00.019,439] <inf> central_uart: NUS Client module initialized

[00:00:00.027,587] <inf> central_uart: Scanning successfully started

[00:00:00.658,447] <inf> central_uart: Filters matched. Address: D4:F0:2B:4E:B1:6D (random) connectable: 0

[00:00:01.665,954] <inf> central_uart: Connected: D4:F0:2B:4E:B1:6D (random)

[00:00:01.917,175] <inf> central_uart: MTU exchange done

[Simon]

Hello Slivio,

babos said:

it is nice to hear you again.

Thank you, nice to hear from you as well!

Let's try to narrow down the issue.

When the central_uart receives data, the function ble_data_received should run, which should output the data through uart_tx. 

Try to check if ble_data_received is actually triggered. This can be done by setting printk("In ble_data_received\n")*, setting LOG_INF("In ble_data_received") (RTT logs) , or set a break point here and/or here.

If the function ble_data_received is triggered, but the output from uart_tx, then there is something wrong with the UART, however, if ble_data_received is not triggered (no logs, or breakpoint is not hit), then the issue is something else.

To confirm that your printk/LOG_INF/break point are working as expected, you can for example first add it inside connected().

*printk should output through uart0 and the pins 20 and 24, because zephyr,console should be set to uart0 by default (you can confirm this by checking \nrf\samples\bluetooth\central_uart\build_1\zephyr\zephyr.dts. Since you're able to get printk to work ("Starting Bluetooth Central UART example") find it strange then that uart_tx should not output anything, because that will also use uart0. Regarding flow control, that should be disabled for uart0 by default (you can confirm this by looking at uart0 inside \nrf\samples\bluetooth\central_uart\build_1\zephyr\zephyr.dts. If there is no hw-flow-control present (like here), flow control is disabled), just make sure to disable it in the receiving terminal as well:

 

Best regards,

Simon

[babos]

Hi SImon,

I had already tried to make a break point on the 'ble_data_received' but it will not trigger on the dongle52840 and instead it will trigger on the nrf52840dk. I also tested on 9160dk in section 52840, and again it won't trigger; only work on 52840dk.

thank you

[Simon]

Okay, then I guess the issue is not UART, I will get back to you later with more info on how to debug furhter.

In the meanwhile, can you add printk and LOG_INF in ble_data_received to be even more certain that the function is not triggered. In case for example that there is some wrong with the debugging of the dongle.

You can also try to use uart_tx in main, here for example, to make sure that is working as expected.

[babos]

okay, i did what you suggested but there is no trigger.

In summary, I would need to use central uart on nrf52840_dongle with transceiver on pins P0.20 and P0.24 without hardware flow control.

I compiled on visual studio code for the chosen board.

on RTTViewer it connects to me without problems and writes me on the logger 'MTU Exchange done' but it does not trigger the 'ble_data_received' call back.

The security setting is: 'BT_SECURITY_L1'

with an nrf52840dk card, communication works without problems.

[babos]

hi there,
I am attaching the code for the dongle nrf52840 and the log on RTT.

could it be the soc device S140?

00> [00:00:00.011,047] <inf> fs_nvs: 4 Sectors of 4096 bytes
00> [00:00:00.011,047] <inf> fs_nvs: alloc wra: 0, fd0
00> [00:00:00.011,077] <inf> fs_nvs: data wra: 0, 1c
00> [00:00:00.011,199] <inf> sdc_hci_driver: SoftDevice Controller build revision: 
00>                                          33 78 2a 18 20 f5 61 61  a6 8b 77 60 62 83 39 2a |3x*. .aa ..w`b.9*
00>                                          7c f1 14 e4                                      ||...             
00> [00:00:00.016,357] <inf> bt_hci_core: No ID address. App must call settings_load()
00> [00:00:00.016,357] <inf> central_uart: Bluetooth initialized
00> [00:00:00.018,432] <inf> central_uart: Scan module initialized
00> [00:00:00.018,432] <inf> central_uart: NUS Client module initialized
00> [00:00:00.029,327] <inf> central_uart: Scanning successfully started
00> [00:00:01.957,397] <inf> central_uart: Filters matched. Address: FC:23:45:E6:D4:AC (random) connectable: 0
00> [00:00:02.966,827] <inf> central_uart: Connected: FC:23:45:E6:D4:AC (random)
00> [00:00:03.168,060] <inf> central_uart: MTU exchange done

source code