mjdietz2 gravatar image

Posted 2016-02-01 14:23:44 +0200

blogs->nordicers

nrfjprog, pynrfjprog - Intro, Mac OS X & Linux now supported, New Feature

Highlights

Do you want a more efficient way to program your devices than nRFgo Studio? Are you an OS X or Linux user who has struggled setting up a toolchain for nRF5x devices? Maybe you are using JLink.exe or an open source tool to program your devices or maybe you even wrote your own? If this is you READ THIS POST!

If you have already been using nrfjprog, pynrfjprog, mergehex you may want to skip to the 'Multi API' section of this post. This introduces the new feature in pynrfjprog that enables multiple devices to be controlled and selectively programmed from python (great for automated testing, scripting, workflow, etc...).

Motivation

As developers our goal is to ship a great product. We have time constraints and deadlines to meet and to efficiently build our product we need to have a good workflow in place. It is key to be able to compile, run and debug applications quickly. It is proven a shorter compile & run/debug cycle leads to cleaner, less buggy code. And added efficiency here WILL ultimately lead to a better product and make you a happier developer. If it takes you over 30 seconds to build and run/debug your applications (including erasing the chip, programming soft-device & or bootloader along with your application) then you are not operating at full efficiency. From blinky to production you will do this thousands of times - take a few minutes to get this right!

What does an ideal toolchain for nRF5x devices look like currently?

5 minute nrfjprog quick start

nrfjprog is a command line utility that allows you to erase, flash, unlock, read/write memory etc... from the command line.

EDIT (nikolaus's comment): I've added nrfjprog (and mergehex) to Homebrew Cask, meaning they can be installed on OS X using:

brew cask install nrf5x-command-line-tools

This will automatically handle putting them in the right place, so they'll be in your PATH and immediately usable. Thanks!

  • Run 'nrfjprog' from the command line. The man page will be displayed (if its not you didn't properly add nrfjprog to your system path, but this is done by the installer in windows). Skim over this to see everything nrfjprog can do.

Note: nrfjprog and pynrfjprog relies on SEGGER's JLinkARM.dll. This means it will only work with a debugger running SEGGER firmware (all our development kits come shipped with SEGGER software so this works by default).

mergehex.exe is in the same folder as nrfjprog.exe so just run mergehex from the command line and read the man page and you will understand how to use it.

The most common nrfjprog commands: image description

5 minute pynrfjprog quick start

pynrfjprog has the same functionality of nrfjprog and more in Python! You may want to use shell scripting with nrfjprog to do many things in one command but pynrfjprog gives you finer control of the nRF5x device and gives you options like using Python's Unit Testing Framework and many of the benefits that come along with Python.

  1. Run 'pip install pynrfjprog' from the command line.
  2. Go to your equivalent: 'C:\Python27\Lib\site-packages\pynrfjprog\examples' and look at a few of the examples or even run them.
  3. You will see this in the examples above 'from pynrfjprog import API, Hex' is how you import this module.

Example of pynrfjprog in use: image description

And most of the functions available from API.py (Just open 'C:\Python27\Lib\site-packages\pynrfjprog\API.py': image description

pynrfjprog new feature: Multi API

Just a quick demo of the new feature. Very similar to what you are used to with pynrfjprog - just unlocks new possibilities. image description

Limitations:

  • Linux & OS X: Multi API class cannot be instantiated if an API class has already been instantiated and opened.
  • Windows: Scripts containing instances of Multi API must perform their activity inside if name == 'main':

Where to go from here

What tools do you use? Do you use JLink.exe? Why do you use this instead of nrfjprog? What will you use these tools for? Any suggestions? What do you want to see, what isn't necessary? Official documentation on these tools is currently being edited and will be on the infocenter soon. What other documentation do you need, examples? Do you flash your softdevice/application directly from the IDE? Why not? How is your workflow efficient? done

EDIT: Do you want our tools to be open source? How would this help you?

13 comments

nikolaus gravatar image

Posted Feb. 1, 2016, 5:34 p.m.

I've been using JLinkExe because nrfjprog wasn't available on OS X. This came at the perfect time, too—I've been testing sleep current, and nrfjprog -p lets me test a lot faster.

I would love if the tools but especially the SDK were open source. If everything were on Github, it would be much easier to track bugs and to contribute code back.

nikolaus gravatar image

Posted Feb. 1, 2016, 9:58 p.m.

I've added nrfjprog (and mergehex) to Homebrew Cask, meaning they can be installed on OS X using:

brew cask install nrf5x-command-line-tools

This will automatically handle putting them in the right place, so they'll be in your PATH and immediately usable. Thanks!

mjdietz2 gravatar image

Posted Feb. 2, 2016, 8:37 a.m.

Thank you nikolaus, thats great! I will add this to the blog post in an edit. Well keep an eye on github in late march ;)

david.garcia.polo gravatar image

Posted Feb. 2, 2016, 9:52 a.m.

We have plans to setting certain parts of the tools code in github to improve the feedback on issues and suggestions for improvement, but due to licensing issues we will not be able to open source the nrfjprog.dll since it makes use of Segger API. nrfjprog.exe (and equivalent) could be open sourced, but it makes heavy use of the dll, so the functionality is quite simple.

Regarding the SDK, the request has been forwarded to the responsible.

EarthLord gravatar image

Posted Feb. 2, 2016, 10:07 a.m.

Yes, please make as much as the tools open source friendly as possible. It'll help us tweak it as per our needs and also to help others in the community. Also please bring in features such as programming the bootloader and generating the dfu init zip files in nrfjprog.

@Nikolaus, please post the findings from your sleep current tests. :)

nikolaus gravatar image

Posted Feb. 3, 2016, 6:54 p.m.

@Michael: I'm looking forward to March! :)

@PrithviRaj: I was able to get down to about 3µA when sleeping with the radio off, which is what I was aiming for. Is there anything in particular you're eager to know?

EarthLord gravatar image

Posted Feb. 4, 2016, 9:49 a.m.

@Michael Great!

@Nikolaus Thanks. What instrument did you use for this? Sorry for going off topic. Maybe you could write a blog post about the test procedure and instrument used.

wilhelmsen gravatar image

Posted Feb. 20, 2016, 7:57 a.m.

Great package, love the MultiAPI! I would like to have a function returning what speed RTT is at, and what I can set as maximum. For example, when using the DK as debugger, what speed can I set the RTT at? Is it also depending on the processor I am debugging?

SvenKBach gravatar image

Posted Feb. 10, 2017, 12:18 p.m.

At the production tests the device is powered via programmer's VCC output line. Between that line is a current meter. We have noticed that if one burns the firmware and measures the current, it is biased since somehow the programmer(nRF 51 DK) also introduces some current due to some functionality. If one cancels the session by powering on and off the programmer and no new connections are made by the host PC, one can see the real current. Is there any API call where I could disconnect or reset the debugger so that the current introduced by the after-burning process is not accumulated into current meter's reading? The disconnect_from_emu() call does not decrease it.

david.garcia.polo gravatar image

Posted Feb. 10, 2017, 12:55 p.m.

The problem is that the debug port is not abkle in nRF51 to get out of debug interface mode, so some regulators and oscillators are kept on. A pin reset will stop those current drains. Perform a pin reset and measure again.

Note that this is only valid in nRF51 devices.

lcrocker gravatar image

Posted May 12, 2017, 6:21 p.m.

BUG REPORT:

nrfjprog version: 9.3.1 JLinkARM.dll version: 6.12g

I haven't figured out the exact way to trigger this yet, but about half the time when programming either the softdevice or bootloader from hex file, nrfjprog pre-emptively enables pinreset without being asked to in any way (no command line, and nothing in either hex file). It's quite clear--I read address 0x10001200 before the --program statement with 0xFFFFFFFF, and afterward it contains 0x00000015.

I have had to eliminate the use of nrfjprog from my Makefiles and use Segger's JLink scripts to program my device to work around this bug. But nrfjprog is handy, and I would use it if it were fixed.

david.garcia.polo gravatar image

Posted May 15, 2017, 12:57 p.m.

@Lee Daniel Crocker

nrfjprog does not enable pinreset by itself, and I am certain of that since I am the programmer. But I can think of two ways it happens:

  1. You build your project with the macro CONFIG_GPIO_AS_PINRESET defined. If that is the case, on the first run of the SW the SystemInit() function in system_nrf52.c (or system_nrf52840.c) file will write those values.
  2. Your code in some way defines a const variable placed at 0x10001200 with the value. You can open yourself the hex file and take alook at the end of the code.

If those are not the case, please tell and I can take a look at it.

lcrocker gravatar image

Posted May 15, 2017, 6:25 p.m.

It was #1, many thanks.

Sign in to comment.

User menu

    or sign up

Recent questions

Related posts by tag