• State Verified Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 91 subscribers
  • Views 1019 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 285592
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nRF52840 DK User Program not persistent through a power-cycle

Ted Keller

I have received a newer DK board (2.1.0) and have a problem.

The newer board wants to update the FW constantly when I run a test.  That appears to be resolved by disabling the readback protection (nrfjprog --recover) after updating the JLink FW (via BOOTLOADER drag-and-drop).  The JLink FW is the latest on the NORDIC web site (j-link-ob-sam3u128-v2-nordicsemi-170724.bin).

Now when I program my user test code to the JLINK device, the user code does not persist through a power-cycle.  The user FW must be reloaded after each power-up to run.

Another engineer has the newer DK too, he did not update the JLink FW on his but did disable the readback protection; his board retains the user FW through a power-cycle.

Any ideas about what might be happening on the newer board?  Or, is there a way to get the factory FW that came on the board?

Thanks

  • 0

    Hello Ted,

    That sounds odd.

    5127.zephyr.hex

    So if you flash this blinky hex file by either dropping it into the JLINK Storage Device, or with the commandline, the LED on the DK stops blinking after being reset? Do you even see it blinking at any point?

    Could you give me a picture of the board?

    Regards,

    Elfving

  • 0 in reply to Elfving

    Elfving,

    I agree, this is odd.

    The blinky file does run after a power-cycle; but the test code that multiple people use on two versions of the board does not (as explained in the first post).  The test code does run and persist on a 2.1.0 board that did not update the JLink FW.  Could I get a copy of the factory FW that came on the board?

    The system does not appear to accept pictures.

    Also, are there known issues with any versions of JLink running on Ubuntu 20.4 when communicating with the 52840?  When connected to my system running JLink V7.62b they exhibit the behavior described; when connected to JLink V7.58 they behave normally.

    Thanks,

    Ted

  • +1 in reply to Ted Keller

    Hey again!

    Ted Keller said:
    The blinky file does run after a power-cycle; but the test code that multiple people use on two versions of the board does not

    So there are examples that do run after a cycle. Would you mind telling me more about this code?

    Ted Keller said:
    Could I get a copy of the factory FW that came on the board?

    You can, but I don't think the new FW is the issue. We can get back to this if nothing else works

    Ted Keller said:

    The system does not appear to accept pictures.

    It should be possible to simply paste it here or insert it as a file.

    Are the switches on your DK in the right positions btw? (SW9 on DVV and SW6 on DEFAULT) And I assume the smaller switches like SW10 haven't been used?

    Ted Keller said:

    Also, are there known issues with any versions of JLink running on Ubuntu 20.4 when communicating with the 52840?  When connected to my system running JLink V7.62b they exhibit the behavior described; when connected to JLink V7.58 they behave normally.

    But yet again, this is only the case with your test code?

    No, I don't know of any known issues regarding this at the moment. Though ideally you should use the j-link that is bundled with the nrf command line tools, since that is the one that have been tested. I am for instance using version 7.60g with nrfjprog version 10.15.4. 

    I assume you've tried connecting your DK with your coworkers machine which has a version that is making your DK function when reset? Or did you downgrade to JLink V7.58? 

    Regards,

    Elfving

Related
Terms of service