Hello,
We are currently in the process of developing a custom board containing the nrf5340, which will act as a central for HR devices and a peripheral for data transfers. During the development of the HR side we came across an issue in our custom board that doesn't occur on the discovery kit. The issue is that every time a HR device has connected to our Central, and requests an update of the connection parameters, our central accepts these new parameters but doesn't use them. Thereby causing a timeout in the connection with the peripheral.
This behaviour is visible in the image below:
The wireshark sniffer caught the following traffic:
The central does not seem to actually use the new connection parameters, as between each empty PDU (discounting the re-transmits) is still the original ~50ms interval. Our peripheral does not accept this interval and is quietly disconnected, going back into advertising mode (which is temporarily a NONCONN).
The only visible hint on what could be wrong here is in the control opcode message, which has a red error message in the protocol window, as seen in the below image:
At first we assumed this to be a software issue, where our device isn't correctly setting the new connection parameters, so we went back to the nordic samples.
The above images were all taken from the Central And Peripheral HR sample from Nordic, with the authentication, security elements and DK associations completely stripped from the sample. The only addition is a le_param_updated callback, which prints out the new connection parameters. 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). Flashing this sample to our DK we observed the expected behaviour, as seen in the image below:
Although it takes a few packages for the connection parameters to actually update, we can see that from package ID 327 and onward that the connection interval has been changed to ~330ms and the peripheral keeps notifying the device of new heart rate intervals. Curiously the above behaviour is captured after we flashed the build configuration that was actually meant for our custom hardware, yet it still works. This would mean that (as far as we are aware) the firmware of both devices is the exact same, yet on our custom hardware it seems to fail which points to it being a hardware issue (although we do find this a strange hardware symptom).
Our hardware configuration is based on configuration 3 of the datasheet (9.3.3 Circuit configuration no. 3 for QKAA aQFN94, engineering sample D (QKAAD0) ), except that we have added an antenna connector (CONUFL001) so that we can add an external antenna.
We have tried a lot of different troubleshooting options including but not limited to:
- Manually accepting the new parameters using the le_param_updage_req callback
- Flashing the build configuration meant for the DK to our custom hardware
- Changing the antenna
- Disabling the peripheral side
- Using a different HR peripheral
- Using a different SN custom board
- Changing from SDK/Toolchain 2.9.0 to 3.0.0
What does work is that we can use the le_param_update_req callback to simply decline the connection parameter update request, which keeps the communication alive as normal on the 50ms interval, however considering the low-power requirements of the peripherals we are connected with, this isn't a viable long-term solution.
We are currently out of ideas to further troubleshoot this issue, so we require advice on how to continue. The Control Opcode error in the third image might be a hint as to what is going wrong.
