Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

RE: Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

Relitech-Jeroen — Wed, 21 May 2025 10:27:55 GMT

We have found the cause of the problem, and verified a fix. The issue indeed came from our crystal being incorrectly specified to the load capacitance, as our 32k crystal expected 4pF but the nordic chip could only go down to 6pf internal capacitance.

To validate this, I have desoldered the 32k crystal from a defect DK board we had lying around, and replaced our own with it. After doing this and using the default crystal settings in the board configuration, the device was able to keep a connection alive after a connection parameter update request was called.

Why or how flashing a DK with a heart rate peripheral firmware meant that our device was able to accept longer connection intervals, is a mystery to me. Why our device was unable to synthesize the 32kHz clock is also a dubious issue, but not an important one.

Thank you for your time and help Edvin.

RE: Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

Edvin — Wed, 21 May 2025 06:59:16 GMT

[quote user="Relitech-Jeroen"]GPPI one_to_one example[/quote]

Which sample is this? And is it testing the HFCLK or the LFCLK?

[quote user="Relitech-Jeroen"]but doing this gives us a high and low time of 990ms instead of 1000ms, so either our clock has a 1% inaccuracy, or more likely we are using the sample incorrectly[/quote]

Do you see the same on the nRF5340DK?

[quote user="Relitech-Jeroen"]

What would be the specifics of such a ticket? Assuming Problem Type = Hardware, Development Stage = Development, Product = nRF5340, Distributor = None?

[/quote]

I suspect you need to select a distributor to be allowed to create a private ticket, but you can test without. The rest is fine.

Best regards,

Edvin

RE: Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

Relitech-Jeroen — Tue, 20 May 2025 10:26:18 GMT

Hi Edvin,

We are currently running the GPPI one_to_one example to see how accurate our timer is. Would this sample provide us with that information? We are using an oscilloscope on a test pin (not an LED because our LED was routed to the other bank GPIO1), but doing this gives us a high and low time of 990ms instead of 1000ms, so either our clock has a 1% inaccuracy, or more likely we are using the sample incorrectly.

We have dutifully followed the recommendations of the nordic datasheet specifying configuration 3 and are using the internal load capacitors for both the high frequency and low frequency clock. Calculating the required load capacitors based on our trace and pad capacitance, plus the capacitance required by the crystal, we came to a value of 7pF for our 32kHz and 14pF (2x7) for our 32MHz clock. We have selected these as well in the config files.

CONFIG_SOC_HFXO_CAP_INT_VALUE_X2=14 CONFIG_SOC_LFXO_CAP_INT_7PF=y

Varying these values does not change the outcome, the board still fails after a connection interval change.

I will be looking more into debugging the timing values.

[quote userid="26071" url="~/f/nordic-q-a/121384/custom-board-nrf5340-configured-as-central-peripheral-hr-combo-disconnects-from-hr-devices-after-a-successful-connection-param-update/536096"]And if you haven't already, can you please create a ticket (you might want that to be a private ticket) where you upload your schematics and PCB layout files, and request a HW review,[/quote]

What would be the specifics of such a ticket? Assuming Problem Type = Hardware, Development Stage = Development, Product = nRF5340, Distributor = None?

Regards,

Jeroen

RE: Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

Edvin — Tue, 20 May 2025 07:16:37 GMT

Indeed, this is worth looking into.

And if you haven't already, can you please create a ticket (you might want that to be a private ticket) where you upload your schematics and PCB layout files, and request a HW review, to check that things (such as capacitors around the XTALs) have proper values.

Best regards,

Edvin

RE: Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

Turbo J — Mon, 19 May 2025 19:13:28 GMT

Have you checked the HFXO frequency?

We had another thread here some time (weeks?) ago where improperly sized loading capacitors caused HFXO frequency to shift outside acceptable range.

I recommend using GPIOTE and a timer/RTC peripherial in order to check both crystal frequencies.

RE: Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

Relitech-Jeroen — Mon, 19 May 2025 14:35:35 GMT

We are using the nRF52840-DK, I tried to build the example for an nRF5340DK but got a dts linker error out of the box, so switched over to the other DK as we have both lying around.

The low frequency clock accuracy should be 20ppm, according to the datasheet. We are using the ECS-.327-CDX-1082.

The above setting did not change the behaviour of our central.

[quote userid="26071" url="~/f/nordic-q-a/121384/custom-board-nrf5340-configured-as-central-peripheral-hr-combo-disconnects-from-hr-devices-after-a-successful-connection-param-update/536013"]

If that doesn't make a difference, can you also try adding:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y

[/quote]

This has caused our central device to be completely unable to keep a connection alive for more than 1 empty PDU. Which I find strange when looking at the description of the config, as it should just synthesize a LFCLK from the HFCLK, which could indicate an issue with the HFCLK?

Regards,

Jeroen

RE: Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

Edvin — Mon, 19 May 2025 13:43:04 GMT

It baffles me as well. Particularly the part where you say that it is able to keep the connection, but the sniffer is not picking it up.

[quote user="Relitech-Jeroen"]For testing we are using a watch and a heart rate band, the watch has a preferred connection interval of 330ms and the band 500ms. Setting these intervals in the zephyr example causes no issues. The connection interval is updated by our central and kept alive just fine. The bluetooth sniffer however stops receiving after the event instant for the connection param update has passed (so the connection interval specifies instant 211, and as soon as event 211 occurs, the sniffer stops receiving, while our RTT is still logging a valid connection).[/quote]

What Nordic DK is the peripheral in this case?

On your central device, what is the LFLCK accuracy?

Can you try setting this in prj.conf:
CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

If that doesn't make a difference, can you also try adding:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y

And let me know if any of those changes anything?

BR,

Edvin

RE: Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

Relitech-Jeroen — Mon, 19 May 2025 07:28:07 GMT

Hi Edvin,

[quote userid="26071" url="~/f/nordic-q-a/121384/custom-board-nrf5340-configured-as-central-peripheral-hr-combo-disconnects-from-hr-devices-after-a-successful-connection-param-update/535797"]That is correct. It is always the central sending the first packet in a connection, to which the peripheral replies.[/quote]

So to summarize, the central is responsible for keeping the connection alive, it stops trying to do this and then receives a timeout. Why would it stop trying to connect to the peripheral? Or is this a bug from the wireshark sniffer?

[quote userid="26071" url="~/f/nordic-q-a/121384/custom-board-nrf5340-configured-as-central-peripheral-hr-combo-disconnects-from-hr-devices-after-a-successful-connection-param-update/535797"]Does this happen on one specific device, or multiple custom boards? Do you have multiple custom boards to test on? Just to see if this is an issue that follows one specific chip, or if it follows the HW+SW.[/quote]

We have different custom boards of the same hardware design, but from a different batch and a different revision. They always fail at keeping the connection alive after updating the connection parameters past a certain threshold. When using a Nordic DK board as a peripheral, the connection interval becomes unstable at around 600ms. Meanwhile the 3rd party watch and 3rd party heart rate band both fail at their respective intervals of 332.5ms and 500ms, while the Nordic DK board as peripheral still works at these intervals.

Any further advice?

Regards,

Jeroen

RE: Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

Jan Willem (RT) — Fri, 16 May 2025 13:30:20 GMT

Hi Edvin,

I'm replying on behalf of my colleague, as he's not in today.

Yes, we've tried the same software with different custom boards, and these give the same behaviour.

We also tested with responding different connection parameters, which sometimes does change the behaviour that the connection remains "more stable", as in, the timeout is deferred to a later moment. This would suggest that our board has problems with keeping an accurate reference clock. However, to verify this, we tried logging information at regular intervals on our custom board which did not reveal any significant drift or wander of the clock.

As mentioned before, the strange thing is that the BLE sniffer does not report any traffic being sent after the connection parameters are changed on our custom board, the RTT logs on both the central and HR peripheral do still show ongoing communication. Until a timeout event is triggered, and the connection is dropped. This event is also logged by the BLE sniffer.

It is really baffling what is happening here, and we're not sure what options we have to investigate this further.

Regards,

Jan Willem

RE: Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

Edvin — Fri, 16 May 2025 13:12:19 GMT

[quote user="Relitech-Jeroen"]Our central meanwhile also disconnects because of a timeout, which is odd because what I can see from the wireshark it was our central who was responsible for keeping the connection alive.[/quote]

That is correct. It is always the central sending the first packet in a connection, to which the peripheral replies.

Does this happen on one specific device, or multiple custom boards? Do you have multiple custom boards to test on? Just to see if this is an issue that follows one specific chip, or if it follows the HW+SW.

It is strange. Setting the initial connection parameters to match the peripherals preferred parameters working just fine suggests that there is no timing issue. So the device is perfectly capable of maintaining a connection with these parameters. It is interesting that the sniffer falls out, though.

[quote user="Relitech-Jeroen"]RTT is still logging a valid connection[/quote]

Is that both on the central and the peripheral, or just the central?

BR,

Edvin

RE: Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

Relitech-Jeroen — Thu, 15 May 2025 10:27:05 GMT

I have been testing a bit more and found some strange results.

For testing we are using a watch and a heart rate band, the watch has a preferred connection interval of 330ms and the band 500ms. Setting these intervals in the zephyr example causes no issues. The connection interval is updated by our central and kept alive just fine. The bluetooth sniffer however stops receiving after the event instant for the connection param update has passed (so the connection interval specifies instant 211, and as soon as event 211 occurs, the sniffer stops receiving, while our RTT is still logging a valid connection).

When we disable the zephyr example and instead connect the band or the watch, the problem returns. The problem is still not visible on our DK board, which can connect with both the band and the watch.

Setting the connection interval back to 800 (1000ms) the zephyr example will also get timed out after a connection parameter update request.

@Edvin do you have any further advice?

RE: Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

Relitech-Jeroen — Thu, 15 May 2025 08:51:48 GMT

Hi Edvin,

[quote userid="145488" url="~/f/nordic-q-a/121384/custom-board-nrf5340-configured-as-central-peripheral-hr-combo-disconnects-from-hr-devices-after-a-successful-connection-param-update/535476"]I will program a HR gatt server into another nordic dev board and get back to you with a log from that.[/quote]

I have programmed a nRF52840DK with the zephyr Perihperal HR example and changed the preferred connection interval to be 800/800, which gives me the following log:

Connected
Stop blinking LED.
[00:02:26.076,751] <inf> hrs: HRS notifications enabled
HRS notification status changed: enabled
[00:02:34.578,125] <wrn> bt_conn: conn 0x200021a0: not connected
[00:02:34.578,277] <inf> hrs: HRS notifications disabled
HRS notification status changed: disabled
Disconnected, reason 0x08
[00:02:34.578,399] <wrn> bt_conn: conn 0x200021a0: not connected
Starting Legacy Advertising (connectable and scannable)
Start blinking LED...

Reason number 0x08 is a timeout, as expected.

What is interesting however, is that the example originally wanted to talk at an interval of 24/40 and our module accepted and used it just fine, so I will experiment with the connection interval for a bit to see when the parameter update is no longer propagated correctly.

RE: Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

Relitech-Jeroen — Thu, 15 May 2025 08:14:09 GMT

Hello Edvin,

Thank you for your reply!

[quote userid="26071" url="~/f/nordic-q-a/121384/custom-board-nrf5340-configured-as-central-peripheral-hr-combo-disconnects-from-hr-devices-after-a-successful-connection-param-update/535466"]Let me see if I got this right. You are the central in the connection that we are investigating now, and the issue occurs only on your custom board, but you are not able to see the behavior on a DK, right?[/quote]

Your problem description is correct.

[quote userid="26071" url="~/f/nordic-q-a/121384/custom-board-nrf5340-configured-as-central-peripheral-hr-combo-disconnects-from-hr-devices-after-a-successful-connection-param-update/535466"]Are you the developer of the peripheral device as well? Is that another nRF device? If so, according to the log, what is the disconnect reason from the peripheral? And what is the disconnect reason for the central?[/quote]

We are currently not in control of the peripheral, but from looking at the wireshark data we can see that our Central pretty much stops communicating on its own. The peripheral therefore receives a communication timeout and starts advertising itself again. Our central meanwhile also disconnects because of a timeout, which is odd because what I can see from the wireshark it was our central who was responsible for keeping the connection alive. I will program a HR gatt server into another nordic dev board and get back to you with a log from that.

It is a systemic issue, in that we always see the problem occur. Our device has never once successfully kept the communication alive after a connection param update request.

We do not manually accept the param change request in our current firmware, relying on the back-end to do so as it has been doing that in the sample code in the DK. When we added a decline I temporarily overwrote the param_change_req callback and made it return false regardless of the input.

[quote userid="26071" url="~/f/nordic-q-a/121384/custom-board-nrf5340-configured-as-central-peripheral-hr-combo-disconnects-from-hr-devices-after-a-successful-connection-param-update/535466"]If it happens all the time, can you please upload a sniffer trace of the issue noe happening on the DK?[/quote]

devzone.nordicsemi.com/.../bluetooth_5F00_sniffer_5F00_nrf_5F00_connect_5F00_with_5F00_instinct2.pcapng

The above file is a sniffer trace from a nordic module connected to nRF Connect Desktop connecting with my watch, which successfully updated the connection parameters at package number 551. If you want to see it working with our firmware on a DK, I can get a sniffer trace of that as well if required, but it looks the same.

In all files we removed references to:

Led 2 and led 3
All buttons
Arduino references
I2C
Quad SPI
GPIO forwarder
USB
Aliases for mcuboot button and led
Configs related to serial, console and UART_CONSOLE as we do not have a uart console (we use RTT)
Any references to I2C, qspi, uart1 and spi in pintctrl
Changed pins of the UART to match ours (tx at gpio0, 21 and rx at gpio0, 19)
Under the 'chosen' node, removed anything linked to the uart0 alias

In the common file we added nfct-pins-as-gpios under the &uicr node alias.

Thank you,

Jeroen

RE: Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

Edvin — Thu, 15 May 2025 07:48:47 GMT

Hello,

Thank you for the detailed description!

Let me see if I got this right. You are the central in the connection that we are investigating now, and the issue occurs only on your custom board, but you are not able to see the behavior on a DK, right?

Are you the developer of the peripheral device as well? Is that another nRF device? If so, according to the log, what is the disconnect reason from the peripheral? And what is the disconnect reason for the central?

Is this issue consistent, or does it happen occationally?

[quote user=""]What does work is that we can use the le_param_update_req callback to simply decline the connection parameter update request[/quote]

Can you show me the code where you accept it?

If it sometimes works without the disconnection, can you please upload a sniffer trace of that scenario as well? If it happens all the time, can you please upload a sniffer trace of the issue noe happening on the DK?

[quote user=""]We created two build configurations, one for our DK and one for our own hardware (the dts of which is solely based on that of the DK with DK elements removed).[/quote]

Can you specify what DK elements that was removed?

Best regards,

Edvin

RE: Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

Jan Willem (RT) — Thu, 15 May 2025 07:22:35 GMT

We've conducted some more tests and still see the same behaviour, unfortunately. What is even stranger is the fact that the same build artifacts (= hex files for CPU and NET) yield different behaviour on our hardware with respect to the nRF5340DK hardware.

This might suggest we're looking at a hardware related issue, but there is no significant difference in components (all are as per recommendation from the suggested circuit configuration).

Does anybody have any pointer in which we can continue our investigation?

RE: Custom board nrf5340 configured as central peripheral HR combo disconnects from HR devices after a 'successful' connection param update.

Relitech-Jeroen — Mon, 12 May 2025 13:37:36 GMT

I have added a capture file where the problem is encapsulated.

devzone.nordicsemi.com/.../custom_5F00_board_5F00_connection_5F00_param_5F00_update_5F00_failed_5F00_2.pcapng

The central receives a param_change request in packet number 332, packet number 336 is the control opcode stating that the parameters are to be accepted. This has the instant value of 211, so at event 211 we expect the change to be applied.

If we select packet 346 we can see that this is the last connection interval that was sent by the central which the peripheral replied to was indeed event 211. The central afterwards never sends any new connections on the new connection interval, so the peripheral gives up after 4000 milliseconds (which is the expected timeout parameter) and starts advertising itself again.

Since wireshark is filtered on the peripheral, I cannot see if the central is attempting to connect to a malformed destination. If there is a way for me to see more than just advertising packets in the nRF Sniffer I could check if the central is communicating anything else.