I am using the nrf connect desktop application on windows with a PCA10059, and have found the application to be buggy when receiving a flood of notifications, this works fine using the pca10031 dongle but I want to use data length extensions and large att mtu
George said:I think I am having the same issue
By this, do you mean that the nRF crashes sometimes when you receive a notification?
If so, it can be almost anything. Try to define debug in preprocessor definitions and monitor the log. If you don't figure out the reason for the logs in the error handler, please create a new ticket. It is almost certainly not the same issue as this one.
Oh, and if you are using an nRF52840 Dongle, please get hold of an nRF52840 DK, as they are much easier to debug.
Well, the symptoms are precisely identical so it is quite valid to assume that the issue is the same.
Above you mentioned that you had replicated the issue and made an internal report for it to be fixed so my question is: was this fixed? If so in which firmware release was it fixed?
I have a DK but if I am using the Dongle I obviously have a reason to do so. My question is specifically about using the nRF52840 Dongle to receive notifications at high rates.
I just mean that what you do in a notification and what the author of this post does in his notifications may be completely different. The term "crash" is a very diffuse term. Something stops working. I assume that you just see that the device disconnects after a while. in ~90% of the cases, this is caused by an APP_ERROR_CHECK(err_code); that receives an err_code != 0. The log should point to which APP_ERROR_CHECK() that triggered this "crash" when DEBUG is defined in your preprocessor definitions.
What APP_ERROR_CHECK() that caused this is completely application dependent. Remember that we don't know anything about your application yet.
I would recommend that you try to replicate this on a DK, or at least try to add logging so that you can see the log on the dongle.
This post is more than 1.5 years old, so I don't know whether the author here is still active. As from my side, you need to debug, and check the log. Then I suggest that you create a new ticket if it is not the same issue as in this case:
Peter Kenyon said:it looks like the slave device starts to receive a seq no error in the LL and continually resends the notification, so the two devices are stuck sending and non acking, until the slave timesout
George Are you using pc-ble-driver?
Edvin I understand that this thread is old but my question is very simple: above you mentioned that you had opened an internal ticket to investigate the bug mentioned by the author and which you had also replicated. If you remember which ticket that was, was the issue resolved? ...I'm not asking you to help me debug this and the issue does not happen on the DK just as the original author and you found out earlier.
So I just need to know what was the outcome of that internal ticket. If you don't remember which one it was that's fine (I guess you can look it up by date) but anything else is not answering my simple question.
Yes. But NB: This only covers pc-ble-driver. From the internal ticket:
"This bug is likely caused by instability in connectivity fw for nRF52840 USB. There was a new release in July 2020 that addressed these instabilities."
Connectivity FW refers to the FW that you flash on the dongle while using pc-ble-driver. Not if you have a custom application from the SDK.
