• State Verified Answer
  • Replies 16 replies
  • Subscribers 63 subscribers
  • Views 6534 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.

  • 0 in reply to endnode

    (I'd almost say "wtf is Ozone and why you don't stick with official SEGGER SW":) Atmel chip hosing SEGGER J-Link is not possible to JTAG (because you don't have proper binary I'm afraid) so the only way is to either use BIN images which are in download section of each nRF5 DK at main Nordic product page and drag&drop them once your board is in BOOTLOADER mode by pressing dedicated button during power on procedure or (e.g. if previous is not possible) by using SEGGER J-Link Configurator tool (or something similar) which knows how to talk to that bootloader pre-loaded to Atmel SAMxxx chip and switch the FW over USB. You could try to hack physical JTAG/SWD or other serial bootlader wires to Atmel chip but I'm afraid even if you succeed you don't have complete FW image to flash it there (and any partial reflashing will be probably locked).

  • 0 in reply to endnode

    Actually getting new DK for USD/EUR one week ago looks like cheaper solution looking on how much time we all spend on it;)))

  • 0 in reply to endnode

    For real :P

    That is unfortunate but makes sense. You never know before the week though whether you're just doing something stupid! Thanks for the info - I'll let you know how it goes.

  • 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.

  • 0 in reply to Mike W

    Glad to hear you found the real cause. It's true that the low quality (or very long) USB cable can really cause an issue. I sometimes have to have a very short one to test when needed.

Related