nrf51822 development using SES, S110 SoftDevice on a Mac

[ssokol]

Total noob here using SES on a Mac to build BLE peripheral (S110) firmware for an nRF51822-based device with SDK v15.

So far I've been able to get the generic portions of the application working. I can read button state changes. I can blink LEDs. I'm using the nRF5 DK board as my programmer. It connects to the target board using the debug out port and a "plug of nails" connector. The Segger debugger in SES is working. I can compile, flash, erase, debug, etc. all from SES.

But... My next challenge is to get the BLE peripheral functionality working. I'm a bit lost on how to tell SES to flash the S110 SoftDevice along with my code. I've found several messages that seem to indicate that the nRF51 line more-or-less stopped with SDK 12.x and that there is no native support for the 51 line in SES and / or in SDK v15.

Does anyone have a recipe, or any suggestions? Would I be better off abandoning SES and trying to set up a different tool chain or use a different IDE on this Mac?

Thanks in advance,

-S

[ssokol]

Hrm... Looks like my assumption of the SoftDevice is wrong - based on old information.

What is the appropriate BLE peripheral SoftDevice for use the the nRF51822 and the v15 SDK? Or is there no such thing?

[Bjørn Kvaale]

There is no support for the nRF51 device on sdk 15. The last sdk that supported the nRF51 device was SDK 12.3. You should take a look at the S130 softdevice located under components/softdevice/s130 in SDK 12.3. SES automatically loads the softdevice onto the board when you download the application to the nRF52 device. You can check this by opening a SES project, right clicking on your Project in the top left corner of SES, clicking "Edit Options..." & going down to the Loader tab. Clicking on Additional Load File[0] will show you the path to the softdevice hex file that is loaded to your device.

Do you have an nRF51 or nRF52 dev kit? If I were you, I would either get another nRF52 dev kit, use the latest SDK 15 & use SES or try using GCC to compile SDK 12.3 examples on your 51 board. You will most likely have less difficulties if you choose the first option.

We also have getting started tutorial videos with SES that could be helpful. Be sure to take a look at our Infocenter documentation here too.

[ssokol]

Hi Bjorn,

I now have SDK 12.3 and arm-none-eabi-gcc installed on the Mac. I've been able to compile the very simply program that I originally had working in SES. (I copied the "blinky" project and replaced the code in main.c with my own.) The project compiles cleanly and the "make flash" command appears to load it to my board. However, it does not appear to work - the lone LED on my board does not blink.

The same code worked as expected when compiled and installed using SES. LED blinked. Button clicks were detected.

The makefile I am using is in the pca10028 directory, and it appears to be expecting to work with a nRF51422 rather than a nRF51822. Is this possibly the problem? If so, what do I need to do to fix this?

How do I access the "printf" output from JLink (or some other tool)? The data appeared in the debug console in SES so I know that it's available somehow. I just don't know how to get to it from the shell (CLI). Any suggestions?

---

Now, a small rant with some constructive criticism:

The documentation for the nRF5 SDK indicates that it works with both the 51 and 52 variants of your products. See: https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF5-SDK

The web site also makes it appear the SES is the preferred way to develop for nRF51. See:

Note the last item in the table: SEGGER Embedded Studio IDE. If SES only works with SDK versions 14 and later, and nRF51 support stopped with 12.3, then this is wrong and misleading.

When you go to the "Downloads" tab, that page shows two options, 12 and 15. The text describing these options discusses various SoftDevices, but it makes no reference to the actual hardware that is supported by them. This is incredibly confusing to someone who is not deeply versed in Nordic's products. It would make a great deal more sense if the downloads were segmented by hardware, THEN by preferred SoftDevice image.

I have the nRF51 DK and the production units I am working to program are using the nRF51822, so there is no option to switch over to the nRF52 DK. Full stop. I'm stuck with nRF51 and I'm a Mac user.

In your response, you say, "If I were you, I would either get another nRF52 dev kit, use the latest SDK 15 & use SES" but in the previous paragraph you say, "The last sdk that supported the nRF51 device was SDK 12.3."  I take your response to mean something like:

"If you have the option of switching over to the nRF52 chip, then I would recommend that you re-design your hardware to use that chip, then get another nRF52 dev kit, use the latest SDK 15 & use SES. If not, then you're stuck with SDR 12.3 and you will need to use GCC, makefiles and all that stuff from 1997."

Is that about the size of it? Sounds like I'm going to have to go the GCC / makefile route.

If so, then it would be useful to have something in the documentation that explains how to install or build a full tool chain for each hardware platform (nRF51 and nRF52) on each development platform (Windows, Mac OS X, and Linux). Your site has some of some of these, but much of the documentation is outdated, referring to older versions of the SDKs, older IDEs that have been deprecated, and older versions of the core tool-chain components (GCC, etc.).

How about you guys put something together like:

• Tutorial: Getting Started With nRF51 Development On Windows 10
• Tutorial: Getting Started With nRF52 Development On Windows 10
• Tutorial: Getting Started With nRF51 Development On Mac OS X
• Tutorial: Getting Started With nRF52 Development On Mac OS X
• Tutorial: Getting Started With nRF51 Development On Linux
• Tutorial: Getting Started With nRF52 Development On Linux

Have the tutorials start from a blank system and walk the user through everything: installing the SDK; installing the IDE or command line tools; modifying the environment as necessary; installing the Segger tools used to program and debug; compiling the samples; and flashing the compiled, working application onto the DK board.

Doing this, and keeping it up to date, would be a HUGE benefit to your developer community.

End of rant.

[Bjørn Kvaale]

Hi ssokol,

 

Sorry for the delayed response. If you take a look at the nRF51422 & 51822 product pages, you notice that the main difference is that the 51422 supports ANT in addition to BLE, while the 51822 supports BLE & 2.4 GHz proprietary communication.

 

You can either use a UART or RTT based logging tool. For Windows I prefer tera term, but since you are using a Mac, something recommended here should work fine. For RTT based logging, you can either do this directly via the Segger Embedded Studio (SES) debug terminal or via a RTT viewer application (see link for more info). 

I would definitely recommend taking a look at our SES youtube tutorial, especially the CMSIS Configuration wizard. With the CMSIS configuration wizard installed, open it up, open the nRF_Log folder, make sure that either NRF_LOG_BACKEND_SERIAL_USES_RTT is true or NRF_LOG_BACKEND_SERIAL_USES_UART is set true. Also make sure that NRF_LOG_ENABLED is set true.

 

Regarding your constructive criticism:

 

I agree that the downloads tab should be updated to make it simpler to use. I will mention this internally. For us in tech support, it is quite intuitive, but that is only because we have worked with Nordic products for a long, long time. I fully understand that for a beginner, it would be very helpful to simplify the documentation even further. We do have a compatibility matrix here in our Infocenter for each of our devices that could be useful.

 

Sorry that I did not notice that you included the Development filter when you made the question. I was wrong about using "GCC, makefiles and all that stuff from 1997." Take a look at this link for importing Keil projects into SES. I would not recommend using gcc & eclipse for example, as many developers have had issues with this. I noticed that you have already found a blog post related to importing SES projects, which is a very good idea in my opinion.

 

I fully agree that it would be very useful to make some more development tutorials & keep them updated. We have already discussed this internally, but I will mention it again. Thank you very much for the constructive criticism!