Devkit 52840 revision 3 issue : unrecognized probe serial number

[Jean-Baptiste]

Hello,

we recently faced some issues dealing with nrf52840 devkit ( no matter the revision ) dealing with some data corruption when packets larger than 64 bytes are transmistted over the  USB CDC ACM Serial Port. As stated in that nordic page Nordic nRF5x Segger J-Link — Zephyr Project Documentation (nordicsemi.com) there's a hint to disable the mass storage device functionality to avoid such kind of problems. It worked well and we were able to send long packets without any issue.

 

But now that we disabled the mass storage we randomly face issues ( that we didn't have in the past ) when we try to establish a UART connection with devkits revision 3... The other symptom is that the  nrfjprog utilitary cannot detect at all the probe id of the devkit. It returns 0, I need to unplug replug the devkit to get the correct serial number. 

 

Is that issue known ? 

Thank you for your help.

[dejans]

Hi,

Could you provide detailed steps so that I could reproduce reported issues?

Best regards,
Dejan

[dejans]

Hi,

Which version of nRF Command Line Tools do you use? Could you provide the output of "nrfjprog --version" command?

I have tried to reproduce your issue with reported 0 as the output from nrfjprog command. I have used nrfjprog version: 10.17.3 external, JLinkARM.dll version: 7.58b and J-Link Commander v7.84c. These are the steps I have taken:
- open J-Link Commander (and run following commands)
- MSDDisable
- reboot
- connect (optional)
- open command line terminal (and run nrfjprog command shown below)
- nrfjprog --ids
Please note that I have used reboot command instead of power cycling the board. I could not reproduce your issue. Could you please try the same steps and get back with the result?

Best regards,
Dejan

[Jean-Baptiste]

Hi Dejan,

thank you for your answer and support,

I used nrfjprog version 10.15.1 jlink dll version 7.64a and JlinkCommander v7.64a.

The reproduction steps are not that evident unfortunately. I followed the same steps as you did for disabling the mass storage on the devkit and the id of the debugguer was correctly displayed this time.

When I observed that bug I was already using the devkit with mass storage disabled for several days ( and I programmed the devkit with some new firmwares ) and time to time I observed that issue to access the debugger but I cannot clearly identify what are the different elements that led me to that issue... 

This issue seems to not be isolated as we also had some issues with linux machines but I need to confirm that. I'll come back with more information when I'm able to reproduce it easily ...

[dejans]

Hi,

Jean-Baptiste said:

The reproduction steps are not that evident unfortunately. I followed the same steps as you did for disabling the mass storage on the devkit and the id of the debugguer was correctly displayed this time.

It is great to hear that you managed to get the ID displayed this time.

Jean-Baptiste said:

This issue seems to not be isolated as we also had some issues with linux machines but I need to confirm that. I'll come back with more information when I'm able to reproduce it easily ...

Please come back if the issue persists and when it becomes consistently reproducible. It would be recommended to fix the issues with Linux machines first.

Best regards,
Dejan