Zephyr crashing when I connect to a device

RE: Zephyr crashing when I connect to a device

Vidar Berg — Fri, 06 Dec 2024 08:16:49 GMT

The Nordic UART Service (NUS) Client which the custom_client is based on is specifically made to interface with the Nordic UART Service. Any project that needs to work with this service can include this this implementation by enabling the CONFIG_BT_NUS_CLIENT setting, not just the central_uart sample. If you want, you can remove the need for the nested callbacks in custom_client by integrating the code into your application.

RE: Zephyr crashing when I connect to a device

DiBosco — Thu, 05 Dec 2024 17:19:22 GMT

[quote userid="4240" url="~/f/nordic-q-a/116852/zephyr-crashing-when-i-connect-to-a-device/513691"]The goal is to decouple the code and allow callbacks to be registered in the application. It was not designed to contain any application specific logic. I don't see any problems with changing this though. The custom_client.c file I made is more or less a copy of the nrf/subsys/bluetooth/services/nus_client.c file with some renaming and small changes I made along the way to try to match your GATT server.[/quote]

The thing that doesn't make sense to me with that is that custom_client is full of custom code anyway, the UUIDs are unique to that header as is

struct bt_custom_client_handles 

which depends on what characteristics are in a service. 
In other words,it's not a generic file that you can use with any
service. If it was, I could more see the advantage in it. 

The likelihood is that I will go through and simplify as 
much of it as I can.
I still don't understand a lot of this, and maybe tidying
up the code as much as possible will help me with that. 

Thanks again for all the help, I'd never have got this
working otherwise.

RE: Zephyr crashing when I connect to a device

Vidar Berg — Thu, 05 Dec 2024 16:32:31 GMT

I'm glad to hear that you are receiving responses now from your peripheral.

[quote user="DiBosco"]And I see nothing there. If I stop the program there err is
optimised out (and yes I have it building for debugging).[/quote]

'-Og' still enables some optimizations. You can add CONFIG_NO_OPTIMIZATIONS=y to your prj.conf if you want to use '-O0'. Just make sure that you don't override this in your project build configuration in VS code.

[quote user="DiBosco"]ble_data_received_rx

This is where I get stuff back in from the remote unit over BLE

What is this for?

ble_data_received_tx

[/quote]

First one is invoked when receiving notifications from the RX characteristic and the other one is when you receive it from the TX characteristic. I don't know if your peripheral will actually send anything on the TX characteristic, but the screenshot from phone showed that both characteristics had the "notify" property. If not, I would have just updated the existing function to use the RX handle.

[quote user="DiBosco"]Why does this have to be done with the obfuscation
of a callback? Why not call

ble_data_received_rx

directly? Or even better, simply do all the work in

ble_data_received_tx

Without having to call yet another function? Just 
seems like an extra layer of unnecessary complexity and code. 

The callbacks and their associated structs are a nightmare 
for reducing readability. 

[/quote]

The goal is to decouple the code and allow callbacks to be registered in the application. It was not designed to contain any application specific logic. I don't see any problems with changing this though. The custom_client.c file I made is more or less a copy of the nrf/subsys/bluetooth/services/nus_client.c file with some renaming and small changes I made along the way to try to match your GATT server.

RE: Zephyr crashing when I connect to a device

DiBosco — Thu, 05 Dec 2024 15:38:31 GMT

[quote userid="4240" url="~/f/nordic-q-a/116852/zephyr-crashing-when-i-connect-to-a-device/513670"]Unless an ATT error is reported in the callback, the write command will have been sent. Did you check this error code?[/quote]

If there was an error it would be spat out by this in ble_data_sent:

 if (err != 0) 
 {
 LOG_WRN("ATT error code: 0x%02X", err);
 }

And I see nothing there. If I stop the program there err is 
optimised out (and yes I have it building for debugging).[quote userid="4240" url="~/f/nordic-q-a/116852/zephyr-crashing-when-i-connect-to-a-device/513670"]Did you change the handle value from RX to TX as mentioned in my previous reply?[/quote]
Hmmm, no I did not, I missed that. <Scrolls back> 

Damnit, yes, that was not changed. 

OK, having changed that it now works in that I can put the
remote unit into ATE mode. Thank whatever deity you might 
worship for that. 

AND, I get data back. 

That might have really broken the back of it finally. 

I have a couple of things I'm not sure about:

ble_data_received_rx

This is where I get stuff back in from the remote unit over BLE

What is this for?

ble_data_received_tx

------------------------------------------

Also, one thing here in on_received_tx:

return custom->cb.received_tx(custom, data, length);

Why does this have to be done with the obfuscation 
of a callback? Why not call
ble_data_received_rx

directly? Or even better, simply do all the work in

ble_data_received_tx

Without having to call yet another function? Just 
seems like an extra layer of unnecessary complexity and code. 

The callbacks and their associated structs are a nightmare 
for reducing readability. 

Thanks!

RE: Zephyr crashing when I connect to a device

Vidar Berg — Thu, 05 Dec 2024 14:49:42 GMT

[quote user="DiBosco"]

ble_data_sent is getting called , which I think is called when the

central_uart app gets confirmation that the remote unit has read
the charctersitic that has been written to locally? 

[/quote]

Unless an ATT error is reported in the callback, the write command will have been sent. Did you check this error code?

[quote user="DiBosco"]Is your central_uart app on the DK definitely writing to:

#define BT_UUID_CUSTOM_SRV_TX_VAL \

[/quote]

Did you change the handle value from RX to TX as mentioned in my previous reply?

[quote user="DiBosco"]

LOG_ERR etc messages to a specific UART and have one UART for
control comms to the PC that is being sent on via BLE and another

purely for debug data, ie the data currently sent to
LOG_ERR, LOG_WRN and LOG_INF?

If so, surely we could route it to ttyACM0? I can see ttyAM0 is
currently spitting out data because it shows exactly the same

[/quote]

You can select which device(s) the UART logger backend should use by modifying the zephyr,console property in the chosen node. The DK board sets this property to zephyr,console = &uart0 by default. Alternatively, if you want to have console (printf, printk) and log (LOG_*) output on separate devices, you can use the zephyr,log-uart property as shown in the Devicetree overlay I shared. What is not possible is to have the Logger module to print debug messages to one device and only error messages to another. It seems like I misunderstood the question.

RE: Zephyr crashing when I connect to a device

DiBosco — Thu, 05 Dec 2024 13:49:05 GMT

[quote userid="4240" url="~/f/nordic-q-a/116852/zephyr-crashing-when-i-connect-to-a-device/513589"]Sorry for not being more clear. What I meant to say is that the second COM port (/dev/ttyACM1) exposed by the interface MCU isn't available on this board as there are no nRF pins routed to this UART - USB bridge on the board. You can of course hook up an external FTDI device to the pin headers, or simply use the nRF USB.[/quote]

I still don't understand this.

Can we route the

LOG_ERR etc messages to a specific UART and have one UART for 
control comms to the PC that is being sent on via BLE and another
purely for debug data, ie the data currently sent to 
LOG_ERR, LOG_WRN and LOG_INF?

If so, surely we could route it to ttyACM0? I can see ttyAM0 is 
currently spitting out data because it shows exactly the same
info that I am getting out of the UART I have connected to an
FTDI lead with:

CONFIG_LOG_BACKEND_UART=y

RE: Zephyr crashing when I connect to a device

DiBosco — Thu, 05 Dec 2024 13:44:48 GMT

[quote userid="4240" url="~/f/nordic-q-a/116852/zephyr-crashing-when-i-connect-to-a-device/513589"]Glad to hear you found the reason for the usage fault. Regarding the -ENOTCONN, could you check if it is returned here: [/quote]

This morning it's not giving me the same error and it's allegedly sending messages out to the remote unit. I haven't changed anything, so goodness knows what was going on last night. I do often find with this ecosystem is very flaky. I often have to clean and recompile because it sometimes just doesn't work after a normal compile and I often have to program twice because it fails the first time, so maybe it was the end of a long fruitless day and had I cleaned and rebuilt it would have been OK.

Today, I have found out, from a colleague, that sending "status<CR><LF>" into the main RX characteristic puts the unit I'm trying to communicate with into ATE mode.

Previously, I've been trying to get this this really complicated binary comms system it normally uses going. With this binary method the master is constantly sending out frames and expecting responses back and I had to use a specific program. So I was going:

Program using PC_UART <-> nrf52840 bLE <-> Remote Unit BLE

Now I can go:

Cutecom on PC <->nrf52840 bLE <-> Remote Unit BLE

And I don't have to worry about frames, it can all be ASCII based and simple. I can switch on the verbose errors and warnings in central_uart and read them on Cutecom along with any other data coming back over BLE from the custom unit.

I have proven I can get into ATE on the custom unit mode over BLE by using BLE Scanner app on my phone and once I send status<CR><LF> the unit goes into ATE mode, with the LCD on the front panel confirming it.

However, if I send that via the central_uart app on the 52840DK the remote does not go into ATE mode. So, I hook up the DK running your central_uart app to Cutecom and I send

status<CR><LF>

The central_uart app is clearly getting that exact text in, I can see that by either mirroring the message back to Cutecom or stopping the app with the debugging and looking at what it received.

Once the status request is received by UART into centrral_uart app, this is called:

err = bt_custom_client_send(&custom_client, data_ptr, len);

I can see with the debugger that

data_ptr points to:

"status<CR><LF>"

len is 8

err = 0 is the response back from the bt_custom_client_send function which suggests is being sent to the remote unit.

ble_data_sent is getting called , which I think is called when the

central_uart app gets confirmation that the remote unit has read
the charctersitic that has been written to locally? 

Is your central_uart app on the DK definitely writing to:

#define BT_UUID_CUSTOM_SRV_TX_VAL \
 BT_UUID_128_ENCODE(0x651135b0, 0xdfe9, 0x45a2, 0x95c1, 0x46552a8a77e2)

What do all these functions:

 uint8_t (*received_tx)(struct bt_custom_client *custom, const uint8_t *data, uint16_t len);
 uint8_t (*received_rx)(struct bt_custom_client *custom, const uint8_t *data, uint16_t len); 
 void (*sent)(struct bt_custom_client *custom, uint8_t err, const uint8_t *data, uint16_t len);
 void (*unsubscribed)(struct bt_custom_client *custom);

So and when should they be called? It looks to me, 
(although I might be wrong because all the callbacks 
within structures [sometimes] within further structures really

are hard to read) that they are set up with 

 struct bt_custom_client_init_param init = {
 .cb = {

 .received_tx = ble_data_received_tx,
 .received_rx = ble_data_received_rx,
 .sent = ble_data_sent,
 }
 };


and 

err = bt_custom_client_init(&custom_client, &init);
But there are four callbacks in the structstruct bt_custom_client_cb
in custom_client.h and we on;y pass three here. 
So maybe they aren't really connected. 

So, I guess the big question is: 

If the central_uart app is 100% definitely getting the right 
string to send to the remote unit and the central_uart app claims
that is has sent the string to the remote unit, and I even, 
seemingly get confirmation back that the remote unit has received
something, how can we ascertain it's actually put the right 
data into the Tx characteristic? I would hook up the other DK and 
see what is received but of course that no longer connects because
of all the new stuff we have in central now.

RE: Zephyr crashing when I connect to a device

Vidar Berg — Thu, 05 Dec 2024 10:01:58 GMT

Glad to hear you found the reason for the usage fault. Regarding the -ENOTCONN, could you check if it is returned here:

? The 'conn' object should be assigned at the end of the bt_custom_handles_assign() function.

Also, not directly related to this issue, but while reviewing this function again I noticed that I assigned the RX handle instead of the TX handle here:

[quote user="DiBosco"]I don't understand what you're saying here.[/quote]

Sorry for not being more clear. What I meant to say is that the second COM port (/dev/ttyACM1) exposed by the interface MCU isn't available on this board as there are no nRF pins routed to this UART - USB bridge on the board. You can of course hook up an external FTDI device to the pin headers, or simply use the nRF USB.

From the nRF52840 DK user guide:

(Ref. https://docs.nordicsemi.com/bundle/ug_nrf52840_dk/page/UG/dk/vir_com_port.html )

To enable logging over the nRF USB port, you can try adding the following 2 overlays to the boards folder in your project source directory and do a pristine build.

<PROJ_DIR>/boards/
├── nrf52840dk_nrf52840.conf
└── nrf52840dk_nrf52840.overlay

devzone.nordicsemi.com/.../4555.nrf52840dk_5F00_nrf52840.overlay

devzone.nordicsemi.com/.../0636.nrf52840dk_5F00_nrf52840.conf

[quote user="DiBosco"]

Assuming you have more than one UART, can you route the

LOG_WRN & LOG_ERR

traffic to that other UART? If so, how. How and where do you

specify *which* UART

[/quote]

The UART backend does not support individual filtering per device. I.e., you can't define one log level for one UART/USB instance and a different level for another.

RE: Zephyr crashing when I connect to a device

DiBosco — Wed, 04 Dec 2024 19:57:25 GMT

I've solved the crashing issue, that trick worked.

Am currently getting

#define ENOTCONN 128 /* Socket is not connected */
Error when I try to write to this:

err = bt_custom_client_send(&custom_client, data_ptr, len);
Even though, the system's telling me it's connected to the custom unit.

[quote userid="4240" url="~/f/nordic-q-a/116852/zephyr-crashing-when-i-connect-to-a-device/513502"]Unfortunately, the second COM port on the nRF52840 DK is not connected to the nRF chip on this board. Otherwise, you could have created a board overlay to direct logs to the second UARTE instance.[/quote]

I don't understand what you're saying here.

First question is:

Assuming you have more than one UART, can you route the

LOG_WRN & LOG_ERR
traffic to that other UART? If so, how. How and where do you 
specify *which* UART 
is being used for the debug information? 

Also, I assume you can change between spitting out LOG_ERR and LOG_WRN and both? If so, how?


Second question

Assuming the above is possible:

a. This second UART: what do you mean it's not connected to the nrf chip? Surely the second UART is a peripheral IN the nrf? Also, I thought this was a funky chip where you could connect any pin to any peripheral? So as long as the pins are accessible on the SIL headers I can connected up an FTDI 3V3 cable to the second UART just as I am to the first to get UART traffic in and out.

b. There are clearly some virtual com ports on this DK, when the board is powered up via the USB connection to the board, I get:

crw-rw-rw- 1 root dialout 166, 0 Dec 4 19:50 /dev/ttyACM0
crw-rw-rw- 1 root dialout 166, 1 Dec 4 19:50 /dev/ttyACM1

Now, I know that the debug information comes out of this because at one point I somehow managed to open some sort of terminal in VSC and when

CONFIG_LOG_BACKEND_UART=y

Was in prj.conf

I got the same serial info into VSC as I currently get into Cutecom. 

So is it not possible to use that VCP in Cutecom 
as the BACKEND UART? This would be the easiest and best way to 
do it. 
Just in case it matters, in the interest of readability I have split 
all the serial stuff into a new file, so when I not get a packet 
in over the UART in serial.c, I call this function in main.c

void send_ble_data_to_xlrt(uint8_t *data_ptr, uint16_t len)
{
 int err;
 err = bt_custom_client_send(&custom_client, data_ptr, len);
 if (err != NO_ERROR) 
 {
 LOG_WRN("CUSTOM send timeout");
 }

}
This is where I get the error -128 not connected

Eventually I'll put all the BLE stuff in another file 
so main is as it should be, a very basic file. Baby steps though. 

RE: Zephyr crashing when I connect to a device

Vidar Berg — Wed, 04 Dec 2024 18:18:07 GMT

[quote user="DiBosco"]I can only assume that when modifying the code to allow for this new subscription I've messed something up.[/quote]

I’m not sure what could have triggered the unaligned memory access. The first thing I would do is look up the faulting instruction address to see which line of code it maps to. You can do this either by using arm-zephyr-eabi-addr2line or by placing a breakpoint at the address.

With addr2line:

1. Open a terminal in Vs code with the toolchain env set:

2. Enter the following command from the "nRF connect" terminal

In my case:

[quote user="DiBosco"]Would be great to have one of those take the traffic and send it to Cutecom to see what's going on at the same time I'm trying to use the BLE "UART"[/quote]

Unfortunately, the second COM port on the nRF52840 DK is not connected to the nRF chip on this board. Otherwise, you could have created a board overlay to direct logs to the second UARTE instance.

[quote user="DiBosco"]I do, of course, realise this and I also know that coding style varies massively from person to person. I do appreciate that some people even like K&R style indentation.[/quote]

I don’t have strong opinions on this to be honest, but I think it makes sense for us to follow the same style as Zephyr for consistency, even though there are always things that could be improved.

RE: Zephyr crashing when I connect to a device

DiBosco — Wed, 04 Dec 2024 13:07:19 GMT

Actually, one more thing that might help me.

Those debug messages that are turned on by having:

CONFIG_LOG_BACKEND_UART=y

In the conf file are very useful, but no good when I'm actually 
trying to ship traffic through the BLE "UART". Could I route
it through to a different UART, preferably one of the
virtual com ports that are on the debug USB interface?
I do see that I have 

/dev/ttyACMx where x is couple of a numbers per dev kit.

Would be great to have one of those take the traffic and send it to Cutecom to see what's going on at the same time I'm trying to use the BLE "UART".

RE: Zephyr crashing when I connect to a device

DiBosco — Wed, 04 Dec 2024 12:55:24 GMT

OK, that's crashing again now:

[00:00:00.013,366] <0x1b>[0m<inf> bt_hci_core: No ID address. App must call settings_load()<0x1b>[0m␍␊

[00:00:00.013,397] <0x1b>[0m<inf> central_uart: Bluetooth initialized<0x1b>[0m␍␊

[00:00:00.014,373] <0x1b>[0m<inf> bt_hci_core: Identity: D9:AD:8D:A9:1A:A2 (random)<0x1b>[0m␍␊

[00:00:00.014,404] <0x1b>[0m<inf> bt_hci_core: HCI: version 6.0 (0x0e) revision 0x104e, manufacturer 0x0059<0x1b>[0m␍␊

[00:00:00.014,434] <0x1b>[0m<inf> bt_hci_core: LMP: version 6.0 (0x0e) subver 0x104e<0x1b>[0m␍␊

[00:00:00.015,747] <0x1b>[1;31m<err> os: ***** USAGE FAULT *****<0x1b>[0m␍␊

[00:00:00.015,747] <0x1b>[1;31m<err> os: Unaligned memory access<0x1b>[0m␍␊

[00:00:00.015,777] <0x1b>[1;31m<err> os: r0/a1: 0x20003800 r1/a2: 0x00000000 r2/a3: 0x00000001<0x1b>[0m␍␊

[00:00:00.015,777] <0x1b>[1;31m<err> os: r3/a4: 0x00038207 r12/ip: 0x00038207 r14/lr: 0x00014bc5<0x1b>[0m␍␊

[00:00:00.015,808] <0x1b>[1;31m<err> os: xpsr: 0x61000000<0x1b>[0m␍␊

[00:00:00.015,808] <0x1b>[1;31m<err> os: Faulting instruction address (r15/pc): 0x00014bd6<0x1b>[0m␍␊

[00:00:00.015,838] <0x1b>[1;31m<err> os: >>> ZEPHYR FATAL ERROR 31: Unknown error on CPU 0<0x1b>[0m␍␊

[00:00:00.015,899] <0x1b>[1;31m<err> os: Current thread: 0x200032c0 (main)<0x1b>[0m␍␊

[00:00:01.547,698] <0x1b>[1;31m<err> os: Halting system<0x1b>[0m␍␊

I can only assume that when modifying the code to allow for this new subscription I've messed something up.

[quote userid="4240" url="~/f/nordic-q-a/116852/zephyr-crashing-when-i-connect-to-a-device/513385"]The use of 0 to indicate success is an established convention in C, and is not limited to Zephyr or the linux kernel. But I see your point. defining a symbol such as NO_ERROR could help improve the code readability. In the old SDK we had the NRF_SUCCESS symbol that was defined as '0'.[/quote]

I do, of course, realise this and I also know that coding style varies massively from person to person. I do appreciate that some people even like K&R style indentation.

I've never liked this

if (whatevs)

type of thing, right from when I started learning C in the 90s it always made me baulk. IMHO code should be as easy as possible to read.

Having done a medical job where they were incredibly strict about stuff like this, as well as things like never using magic numbers it really teaches you how valuable it is to not take short cuts, not to ever have ifs without ==, not to call functions with a call to a function, not use use things like the ternary operator and so on.

I believe some of how C was originally invented was to mitigate for the fact that space to store source code was at a premium, but those days are long gone. Disk space is plentiful and cheap and there's no reason not to be verbose in the interest of clarity. Especially when you're providing code for others to read. It especially helps when debugging and single stepping through code.

I'll see if I can go through this code by update setting breakpoints and trying to work out where it crashes, in the meantime if there's anything you can thing of to track this down that would be great. I can't pretend to really follow exactly what's going on with these changes, let alone how the system works as whole, I get partway down one of these deep callback/macro/structure in a structure rabbit holes and soon forget where I was up to or what I was trying to do.

[quote userid="4240" url="~/f/nordic-q-a/116852/zephyr-crashing-when-i-connect-to-a-device/513385"]Since your peripheral doesn't implement BLE security, you can remove this line and call gatt_discover() unconditionally in your connected callback.[/quote]

OK, cool, thanks!

Thanks again for all the help, it is greatly appreciated.

RE: Zephyr crashing when I connect to a device

Vidar Berg — Wed, 04 Dec 2024 10:18:42 GMT

I made some edits to the GATT client implementation I posted earlier to also enable notifications for the second characteristic. Please try it with this.

devzone.nordicsemi.com/.../custom_5F00_client.c

devzone.nordicsemi.com/.../custom_5F00_client.h

devzone.nordicsemi.com/.../3146.diff.diff

This change is also required in main.c:

@@ -294,7 +304,8 @@ static void discovery_complete(struct bt_gatt_dm *dm,
 	bt_gatt_dm_data_print(dm);
 
 	bt_custom_handles_assign(dm, custom);
-	bt_custom_subscribe_receive(custom);
+	bt_custom_subscribe_tx_receive(custom);
+	bt_custom_subscribe_rx_receive(custom);
 
 	bt_gatt_dm_data_release(dm);
 }

[quote user="DiBosco"]if ((!err) && (err != -EALREADY))[/quote]

I assume the developer intended to write if ((err) && (err != -EALREADY)) so the error message would be printed for any error except -EALREADY. However, I don't see any obvious reasons for ignoring the EALREADY error in this sample. There is no side effect to this as only the error message is printed, which I assume is why it has not been caught by our tests. Will report this internally.

This is how I would have expected it to be written:

	err = bt_scan_stop();
	if (err) {
		LOG_ERR("Stop LE scan failed (err %d)", err);
	}

The use of 0 to indicate success is an established convention in C, and is not limited to Zephyr or the linux kernel. But I see your point. defining a symbol such as NO_ERROR could help improve the code readability. In the old SDK we had the NRF_SUCCESS symbol that was defined as '0'.

[quote user="DiBosco"]

 err = bt_conn_set_security(conn, BT_SECURITY_L1);

As we're not using security on our unit and it was giving
me an error when it was set to L2. Does that sound right?[/quote]

Since your peripheral doesn't implement BLE security, you can remove this line and call gatt_discover() unconditionally in your connected callback.

RE: Zephyr crashing when I connect to a device

DiBosco — Tue, 03 Dec 2024 16:42:40 GMT

OK, a little more info and more questions:

Firstly - and I'm not sure this actually matters in terms of it functioning. This second line must be wrong:

 err = bt_scan_stop();
 if ((NO_ERROR == err) && (err != -EALREADY)) 
 {
 LOG_ERR("Stop LE scan failed (err %d)", err);
 }

This line was originally the mind bending:

if ((!err) && (err != -EALREADY))

Even when written out to make it much more understandable where 

NO_ERROR is defined as 0 rather than a magic number that is 
littered throughout all this code.

This seems like a mad line of code. If err is equal to 0 
it can't be anything else. 

However, as it's just printing out a line of debug code I 
suspect it doesn't actually matter. 

What doesn't seem to be getting called though is this:

discovery_complete

This is used in this:

struct bt_gatt_dm_cb discovery_cb 

Which in turn is filled out, I think, in

gatt_discover

But

gatt_discover never gets called from here: 

 err = bt_conn_set_security(conn, BT_SECURITY_L1);

 if (NO_ERROR != err) // was if (err), changed for clarity
 {
 LOG_WRN("Failed to set security: %d", err);

 gatt_discover(conn);
 }

Surely gatt_discover should be called if err *is* equal 
to 0 which is, again, defined as NO_ERROR for clarity.

Oh, also I changed bt_conn_set_security to:

 err = bt_conn_set_security(conn, BT_SECURITY_L1);

As we're not using security on our unit and it was giving 
me an error when it was set to L2. Does that sound right?

gatt_discover is also called in:

security_changed, but security_changed never gets called 
(I don't know what this is for).

RE: Zephyr crashing when I connect to a device

DiBosco — Tue, 03 Dec 2024 14:22:25 GMT

If it is necessary to enable notifications, how do you do that please?

RE: Zephyr crashing when I connect to a device

DiBosco — Tue, 03 Dec 2024 13:44:55 GMT

Thanks for the boot banner tip.

On the subject of writing from the Android app, I have made some progress, This system is quite complex and the remote unit only writes when requested by a convoluted message, so I found what the standard debug request header is and wrote those 32 bytes using the BLE Scanner app by writing to characteristic UUID

0x651135b0, 0xdfe9, 0x45a2, 0x95c1, 0x46552a8a77e2

Now, unless and until I actually hit notify for the 

0xe7d6274e, 0xb765, 0x11e9, 0xa2a3, 0x2a2ae2dbcce4

characteristic, I got nothing back. When I did hit notify then the 
remote node wrote some valid data into the phone. 

Is the issue that on this Zephyr app we're not subscribing 
(is that the right word) to the read characteristic? 

I'm assuming that should go on in the
bt_custom_handles_assign

function? 

RE: Zephyr crashing when I connect to a device

Vidar Berg — Mon, 02 Dec 2024 22:41:45 GMT

I'm wondering if there any specific requirements for interfacing with your peripheral device or if it behaves just like the original NUS sample. For instance, if it requires notifications to be enabled on more than one characteristic to allow notifications to be sent or some kind of handshake, etc. Either way, I think it might be faster to use the nRF Connect app to determine what works and what doesn't. For example, you can check if you're able to receive data if you only enable notifications for the e7d6274e-b765-11e9-a2a3-2a2ae2dbcce4 characteristic:

[quote user="DiBosco"]One ot her slight annoyance that needs sorting is this that is spat out of the UART at boot:[/quote]

You can disable the boot banners by adding the following 2 lines to your project configuration file:

CONFIG_NCS_BOOT_BANNER=n
CONFIG_BOOT_BANNER=n

RE: Zephyr crashing when I connect to a device

DiBosco — Mon, 02 Dec 2024 19:40:43 GMT

I've tried the 52840DK using your peripheral UART and that works. So I have done

UART | BLE | UART

PC UART<->CENTRAL_UART on 52840<-><PERIPHERAL_UART on 528040<->PC UART

When I try to connect to the custom unit, which uses the very same UUIDs as your custom program, rather than peripheral_uart, it does not work.

The custom unit has successfully done exactly the same thing I'm trying to achieve here, but with a Raspberry Pi:

UART | BLE | UART

PC UART <-> Raspberry Pi with BLE <-> Custom Unit<->STM32

I want to replace that with

UART | BLE | UART

PC UART <-> CENTRAL_UART on 52840<-> Custom Unit<->STM32

BTW, I know how crazy this is, but it's what we've been asked to do.

The custom unit's service for which you had the screen shot has the following setup in its firmware where Rx is data going into it and Tx is data going out.

// the service
#define BASE_UUID128   "2a1f963c-143a-4f7d-9107-6315196a02a6"
#define BASE_UUID16    0x963c
// BLE Data into the custom unit (so the central_uart I'm trying to get working will write into this)
#define RX_LENGTH      240
#define RX_UUID128     "651135b0-dfe9-45a2-95c1-46552a8a77e2"
#define RX_UUID16      0x35b0
// Not sued for UART comms
#define RX_ACK_LENGTH 2
#define RX_ACK_UUID128 "946ba79e-3162-46d5-9ba7-8a9d08c11ff0"
#define RX_ACK_UUID16 0xa79e
// Data out from the custom unit into the central_uart over Bluetooth
#define TX_LENGTH      240
#define TX_UUID128     "e7d6274e-b765-11e9-a2a3-2a2ae2dbcce4"
#define TX_UUID16      0x274e
// Unused for this UART function
#define TX_ACK_LENGTH 2
#define TX_ACK_UUID128 "e7d629ba-b765-11e9-a2a3-2a2ae2dbcce4"
#define TX_ACK_UUID16 0x29ba

The custom unit is running an older Nordic device and I have successfully talked to it the custom unit by writing a Qt program on Linux to talk directly to it. So, the point being we know the custom unit works with these UUIDs

I have tried swapping RX and TX round in custom_client.h just in case there was a BLE equivalent of a 2/3 swap needed, but that does not help.

i.e.

/** @brief UUID of the TX Characteristic. **/
#define BT_UUID_CUSTOM_SRV_RX_VAL \
 BT_UUID_128_ENCODE(0x651135b0, 0xdfe9, 0x45a2, 0x95c1, 0x46552a8a77e2)

/** @brief UUID of the RX Characteristic. **/
#define BT_UUID_CUSTOM_SRV_TX_VAL \
 BT_UUID_128_ENCODE(0xe7d6274e, 0xb765, 0x11e9, 0xa2a3, 0x2a2ae2dbcce4)

One ot her slight annoyance that needs sorting is this that is spat out of the UART at boot:

*** Booting nRF Connect SDK v2.8.0-a2386bfc8401 ***␍␊

*** Using Zephyr OS v3.7.99-0bc3393fb112 ***␍␊

If I search for "Booting nRF Connect" in VSC it does not give me any hits. Do you

know where that is in the source so I can get rid of it please?

RE: Zephyr crashing when I connect to a device

Vidar Berg — Mon, 02 Dec 2024 17:55:02 GMT

I thought you were using the Nordic UART service with custom UUIDs. However, after looking at the the nRF Connect screendump you shared again, I notice several differences. For instance, your service includes three or more characteristics, while the UART service only has two. The client code I provided will only subscribe to notifications from the first characteristic with UUID:651135b0-dfe9-45a2-95c1-46552a8a77e2.

I don't know which characteristics the peripheral is supposed to send notifications on in your case.

RE: Zephyr crashing when I connect to a device

DiBosco — Mon, 02 Dec 2024 17:10:56 GMT

So are you saying the central_uart project needs to be modified (in this case the one you supplied) so that the Rx characteristic in central subscribes to the Tx characteristic in the remote node?

When I use your peripheral_uart to talk to your central with my UUIDs in, I don't need to do anything else other than send data into the UART on the peripheral and it appears on the central_uart project's UART output.

If I look with nrf connect on my Android phone, the Tx on the remote node - whether it be the Nordic DK running peripheral_uart, or our custom device, (which is the RX on the central_uart project) it is notify only, so why would it work on peripheral_uart and not our custom device. What am I not understanding here?

RE: Zephyr crashing when I connect to a device

Vidar Berg — Mon, 02 Dec 2024 16:46:47 GMT

The NUS service only supports notifications on the TX characteristic (Nordic UART service). However, from the screenshot you posted earlier of the nRF Connect app, it seems that both of your characteristics support notifications. This means the GATT client must be modified to subscribe to both characteristics (i.e. custom_client.c if you're using my project).

RE: Zephyr crashing when I connect to a device

DiBosco — Mon, 02 Dec 2024 14:48:24 GMT

OK, in gatt.c the pointer looks like it is NULL.

That function really should have:

if ((NULL != conn) && (NULL != params))

at the start of that function to stop that issue.

I think we should forget about this particular project though, because...

----------------------------------------------------------------------------------

Your program does not do this, but although I can get comms in over the UART, write it to

the characteristic

in the remote node and I get notification it's been read by the remote node

becauswe the ble_data_sent function is called.

However, I never get the ble_data_received callback function being called, so

either the data isn't being quite sent to the write characteristic properly in your app

or something's wrong

with the setup fior the read characteristic in your app. We know the remote node works correctly

because it's been working with a Raspberry Pi just fine.

I'm assuming that, somehow, when you set up the syatem to be able to write to

BT_UUID_CUSTOM_TX

That you are setting up some area of memoryt that is 
automatically the same size as the characteristic in our custom
remote node? 

I did put this:

CONFIG_BT_L2CAP_TX_MTU=247
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_BUF_ACL_TX_SIZE=251

in prj.conf

and changed:

#define UART_BUF_SIZE 240 

from it being just 20 bytes long to allow
for our larger characteristics.

----------------------------------------------------------------------------------

In your program I am guessing via custom_client_init you somehow tell the system

that if it finds the the service you are telling it to call ble_data_received. I'm again

guessing that

bt_custom_handles_assign does the magic of knitting them together
in one of thosememset lines somewhere? Or maybe:

custom_c->handles.rx = gatt_desc->handle;

But I could be wrong, I can't follow that
code I'm afraid. What should be looking for here in
an attempt to ascertain whether that is all set up correctly?
 

RE: Zephyr crashing when I connect to a device

Vidar Berg — Mon, 02 Dec 2024 13:24:05 GMT

It seems you are encountering the same assertion as before:

[quote user="DiBosco"]

ASSERTION FAIL [conn] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/gatt.c:5433␍␊

⇥ invalid parameters␍␊

[/quote]

Can you place a breakpoint at this line to confirm that the conn pointer is not set? Also, were you able to reproduce this with the central project I uploaded?

RE: Zephyr crashing when I connect to a device

DiBosco — Mon, 02 Dec 2024 10:58:02 GMT

OK, and FWIW, yes I had a breakpoint and without it, I get this:

Starting Bluetooth Central UART example␍␊

[00:00:03.093,292] <0x1b>[0m<inf> fs_nvs: 2 Sectors of 4096 bytes<0x1b>[0m␍␊

[00:00:03.093,292] <0x1b>[0m<inf> fs_nvs: alloc wra: 0, fb8<0x1b>[0m␍␊

[00:00:03.093,322] <0x1b>[0m<inf> fs_nvs: data wra: 0, 88<0x1b>[0m␍␊

[00:00:03.093,475] <0x1b>[0m<inf> bt_sdc_hci_driver: SoftDevice Controller build revision: ␍␊

fe 2c f9 6a 7f 36 22 2e a0 79 c0 40 be 2c 03 20 |.,.j.6". .y.@.,. ␍␊

40 c2 f3 32 |@..2 <0x1b>[0m␍␊

[00:00:03.097,717] <0x1b>[0m<inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)<0x1b>[0m␍␊

[00:00:03.097,747] <0x1b>[0m<inf> bt_hci_core: HW Variant: nRF52x (0x0002)<0x1b>[0m␍␊

[00:00:03.097,778] <0x1b>[0m<inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 254.63788 Build 573996906<0x1b>[0m␍␊

[00:00:03.098,480] <0x1b>[0m<inf> bt_hci_core: No ID address. App must call settings_load()<0x1b>[0m␍␊

[00:00:03.098,510] <0x1b>[0m<inf> central_uart: Bluetooth initialized<0x1b>[0m␍␊

[00:00:03.099,487] <0x1b>[0m<inf> bt_hci_core: Identity: D9:AD:8D:A9:1A:A2 (random)<0x1b>[0m␍␊

[00:00:03.099,517] <0x1b>[0m<inf> bt_hci_core: HCI: version 6.0 (0x0e) revision 0x104e, manufacturer 0x0059<0x1b>[0m␍␊

[00:00:03.099,578] <0x1b>[0m<inf> bt_hci_core: LMP: version 6.0 (0x0e) subver 0x104e<0x1b>[0m␍␊

[00:00:03.100,952] <0x1b>[0m<inf> central_uart: Scan module initialized<0x1b>[0m␍␊

[00:00:03.100,952] <0x1b>[0m<inf> central_uart: NUS Client module initialized<0x1b>[0m␍␊

[00:00:03.105,987] <0x1b>[0m<inf> central_uart: Scanning successfully started<0x1b>[0m␍␊

[00:00:03.414,184] <0x1b>[0m<inf> central_uart: Filters matched. Address: E8:A0:DB:24:21:62 (random) connectable: 1<0x1b>[0m␍␊

[00:00:03.604,248] <0x1b>[0m<inf> central_uart: Connected: E8:A0:DB:24:21:62 (random)<0x1b>[0m␍␊

[00:00:03.604,370] <0x1b>[1;33m<wrn> central_uart: Failed to set security: -12<0x1b>[0m␍␊

[00:00:03.604,431] <0x1b>[1;31m<err> central_uart: Stop LE scan failed (err 0)<0x1b>[0m␍␊

[00:00:03.855,590] <0x1b>[1;33m<wrn> bt_conn: conn 0x20002640 failed to establish. RF noise?<0x1b>[0m␍␊

[00:00:03.855,926] <0x1b>[1;33m<wrn> central_uart: MTU exchange failed (err 14)<0x1b>[0m␍␊

[00:00:03.855,957] <0x1b>[0m<inf> central_uart: Service not found<0x1b>[0m␍␊

[00:00:03.856,140] <0x1b>[0m<inf> central_uart: Disconnected: E8:A0:DB:24:21:62 (random), reason 0x3e <0x1b>[0m␍␊

[00:00:03.987,030] <0x1b>[0m<inf> central_uart: Filters matched. Address: E8:A0:DB:24:21:62 (random) connectable: 1<0x1b>[0m␍␊

[00:00:04.183,074] <0x1b>[0m<inf> central_uart: Connected: E8:A0:DB:24:21:62 (random)<0x1b>[0m␍␊

[00:00:04.183,166] <0x1b>[1;33m<wrn> central_uart: Failed to set security: -12<0x1b>[0m␍␊

[00:00:04.183,258] <0x1b>[1;31m<err> central_uart: Stop LE scan failed (err 0)<0x1b>[0m␍␊

[00:00:04.334,655] <0x1b>[0m<inf> central_uart: MTU exchange done<0x1b>[0m␍␊

ASSERTION FAIL [conn] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/gatt.c:5433␍␊

⇥ invalid parameters␍␊

␍␊

[00:00:05.684,509] <0x1b>[0m<inf> central_uart: Service discovery completed<0x1b>[0m␍␊

[00:00:05.694,183] <0x1b>[1;31m<err> os: r0/a1: 0x00000004 r1/a2: 0x00001539 r2/a3: 0x20000b60<0x1b>[0m␍␊

[00:00:05.694,213] <0x1b>[1;31m<err> os: r3/a4: 0x00000004 r12/ip: 0x00000000 r14/lr: 0x000217df<0x1b>[0m␍␊

[00:00:05.694,213] <0x1b>[1;31m<err> os: xpsr: 0x21000000<0x1b>[0m␍␊

[00:00:05.694,213] <0x1b>[1;31m<err> os: Faulting instruction address (r15/pc): 0x00031072<0x1b>[0m␍␊

[00:00:05.694,274] <0x1b>[1;31m<err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0<0x1b>[0m␍␊

[00:00:05.694,305] <0x1b>[1;31m<err> os: Current thread: 0x20002568 (BT RX WQ)<0x1b>[0m␍␊

[00:00:05.747,711] <0x1b>[1;31m<err> os: Halting system<0x1b>[0m␍␊

RE: Zephyr crashing when I connect to a device

DiBosco — Mon, 02 Dec 2024 10:37:40 GMT

OK, it is apparent I have a big gap (no pun intended) in my client side knowledge. As soon as you say it though it is obvious that the client can't be expected to know what's going on in all the peripherals. I suspect the best bet here might be to work with your project and see if I can work out how it functions.