Received status with code 0 PKT_SEND_MAX_RETRIES_REACHED in nRFConnect v.3.7.1.

[Vlad]

I updated nRFConnect from 3.6.1 to 3.7.1 and it started to have intermittent issues with the following error:

---

15:34:27.142

Application data folder: C:\Users\User\AppData\Roaming\nrfconnect\pc-nrfconnect-ble

15:34:27.356

Updated list of uuids with data from https://github.com/NordicSemiconductor/bluetooth-numbers-database/tree/master/v1

15:34:31.669

Device setup completed

15:34:31.670

Getting information from J-Link debugger...

15:34:32.238

Found device type: nRF52832. J-Link firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Feb 2 2021 16:47:20.

15:34:32.238

Connectivity firmware version: 4.1.2. SoftDevice API version: 5. Baud rate: 1000000.

15:34:32.240

Opening adapter connected to COM7

15:34:33.163

Successfully opened COM7. Baud rate: 1000000. Flow control: none. Parity: none.

15:34:33.173

Reset performed on adapter COM7

15:34:34.968

Received status with code 0 PKT_SEND_MAX_RETRIES_REACHED, message: 'No response from device. Tried to send packet 6 times.'

15:34:36.164

serial port COM7 closed.

15:34:36.187

Error occured when opening port. Errorcode: NRF_ERROR_TIMEOUT (0xd)

------

However when I try to connect the second time, the problem does not repeat until I close and open the nRFConnect again. 

I found similar issues with previous versions (https://devzone.nordicsemi.com/f/nordic-q-a/68261/error-nrf_error_timeout-when-using-nrf-connect) and the solution was to erase/reprogram the board (I use PCA10040). I have done this and still having this issue consistently on two laptops. I did not changed the COM port settings. The JLINK versions are 6.44e on one laptop and the latest 7.54c on another laptop.

[Vidar Berg]

Hello,

Please try to disable the mass storage class on your j-link as instructed here link and see if it improves the reliability. I've seen this issue on some Windows systems even though only macOS and Linux are mentioned. I will check internally if others have reported the same after upgrading to v3.7.1 in the meantime.

Best regards,

Vidar

[Vlad]

Hi Vidar,

Disabled the mass storage class/unplugged/plugged the device - got the same error on both versions of Jlink (6.44 and 7.54). Do you have any other ideas?

Thanks!

[Vidar Berg]

Hi,

There doesn't appear to be any known stability issues introduced in the latest nRF connect release. Could you please try to quickly revert back to the the old 3.6.1 release to confirm that it still resolves the stability issue (i.e. confirm is not related to J-link updates, etc) ?

[Vlad]

Vidar, I tested again in 3.6.1 and 3.7.1. It seems that MSDDisable command required some time to propagate - when I tested earlier I was getting the error, I unplugged and then plugged after a few seconds. Now, when I tested it I do not see the error with MS Disabled. 

I enabled MSD again (MSDEnable) and it started having the same error in both versions of nRF Connect. After disabling MSD again and waiting a few min, the error is not showing on both. 

Thus I believe now MSDDisable improves reliability. 

[Vidar Berg]

That's great news, thanks for the update! Not sure if this is what happened here, but note that the MSDDisable procedure requires that you power cycle the board at the end for the change to go into effect.