• State Verified Answer
  • Replies 16 replies
  • Subscribers 62 subscribers
  • Views 6486 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 122966
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52 DK (pca10040) not seen by nrfjprog after IF update

Mike W

After spending half a day on this solution, I found out it wasn't really a solution - it devolved back to the same issue after trying to connect - please advise!

Description of System: nRF52 DK Windows 10 pro PC

Description of Problem: Basically, my DK appears bricked, and none of the established solutions work.

After flashing a couple different softdevices on the nRF52 DK, it was no longer found by the nrfjprog utility, whether in regular or bootloader modes.

At first, powering on in bootloader mode would consistently cause the BOOTLOADER drive to show up then disappear either instantly or after ten seconds or so. Trying to flash or drag/drop any FW during this time (for example the latest recommended nRF5x-OB-JLink-IF) was futile. After installing MBED drivers, it wouldn't show up at all as a drive or a COM/PORT entry in the device manager either.

Taking any of the normal steps either requires nrfjprog CLI to be working (the device shows up as recognized) or the device to show up and function properly with a drag and drop. Restarting the computer did not help. All drivers are up to date, and everything has been uninstalled and reinstalled.

My thoughts are that this is either a driver problem or a serious corruption in the board FW that disallows communication. I have an external J-Link programmer if someone could guide me through reflashing with that via the JTAG micro-header interface.

After manually uninstalling all drivers related to the J-Link then reinstalling from scratch, the drive does now show up, and I was able to then use command prompt to copy the IF onto the BOOTLOADER drive, which subsequently started to show up when not in bootloader mode as JLINK (still as BOOTLOADER when started in that mode). I am still, however, unable to see the device with nrfjprog.

Update: In the interest of trying all available options, I tried setting up and ident with Keil, no luck. Also tried sandeepmistry's arduino library - and it actually can see the device (and reads correct serial number). Turns out it will actually program the thing. So now I am beyond confused, because the last thing I expected to work - the most abstracted one - seems to work fine. Any way I can get it showing up again in nrfjprog so that I can hopefully start using this with Make and eventually Eclipse?

Thanks so much in advance.

Parents
  • 0

    I believe I've solved this problem, and it's a USB issue.

    It looks to be that there was a high resistance or high capacitance connection at the USB connector I was debugging a USB controller for another project (breadboarded) and was able to reproduce the exact same errors with a separate dev kit when I had poor capacitance control and separately with cheap higher-resistance wires.

    The explanation for this is that the USB enumeration process always starts by assuming low-speed 1.5Mbps USB until proven otherwise by the Get_Device_Descriptor response. The slow data rates for the initial device detection were able to pass through fine, but once the device enumerates as high speed, the 12Mbps rates associated with any real data transfer caused the device to not respond properly and cease to be detected.

    In the capacitance sense, this happens of course because ringing prevents a clear signal from getting back, but it's even more suspect in the resistance case because the USB controller expects different resistances for the low-speed vs full-speed USB (the 1.5k tie to 5V needs to be on the opposite data line).

    Experimenting separately with other USB devices by allowing cross-talk between the lines, increasing the resistance (or the capacitance significantly), or tying the high data line through another resistor to ground (imitating a short) all lead to similar behavior.

    Thanks to the Nordic guys for your tremendous patience in helping me get through this and I hope this solution helps others in my shoes! It's not the first time I've heard of this kind of issue online.

Reply
  • 0

    I believe I've solved this problem, and it's a USB issue.

    It looks to be that there was a high resistance or high capacitance connection at the USB connector I was debugging a USB controller for another project (breadboarded) and was able to reproduce the exact same errors with a separate dev kit when I had poor capacitance control and separately with cheap higher-resistance wires.

    The explanation for this is that the USB enumeration process always starts by assuming low-speed 1.5Mbps USB until proven otherwise by the Get_Device_Descriptor response. The slow data rates for the initial device detection were able to pass through fine, but once the device enumerates as high speed, the 12Mbps rates associated with any real data transfer caused the device to not respond properly and cease to be detected.

    In the capacitance sense, this happens of course because ringing prevents a clear signal from getting back, but it's even more suspect in the resistance case because the USB controller expects different resistances for the low-speed vs full-speed USB (the 1.5k tie to 5V needs to be on the opposite data line).

    Experimenting separately with other USB devices by allowing cross-talk between the lines, increasing the resistance (or the capacitance significantly), or tying the high data line through another resistor to ground (imitating a short) all lead to similar behavior.

    Thanks to the Nordic guys for your tremendous patience in helping me get through this and I hope this solution helps others in my shoes! It's not the first time I've heard of this kind of issue online.

Children
Related