Table of contents

RoadTest: Nordic Bluetooth LE Audio Development Kit nRF5340 DK

Author: Fred27

Creation date: 9 Dec 2022

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: nRF5340 DK - which seems like a better option if you're not concentrating on Bluetooth LE audio

What were the biggest problems encountered?: It was very difficult to get the toolchain installed and working. I could see no instructions for using Visual Studio Code as an IDE despite the Getting Started guide saying it should be installed.

Detailed Review:

Introduction

For anyone who's into embedded development, it's a great time to be alive. (Well, maybe not right now with the semiconductor shortages, but around about now.) We're spoiled. Spoiled by incredible performance from tiny devices. Spoiled by (usually) low prices. Spoiled by a huge amount of choice. Gone are the days when you had to carefully select an 8- or 16-bit microcontroller and work out exactly how much RAM or flash you needed and what combination of peripherals. Now you can just pick from a selection of nice 32-bit ARM core - or even dual core - devices with a wide range of peripherals.

It's good for consumers, but maybe a tough playing field for the silicon manufacturers. We have a lot of choice and most of it will be more than adequate for the job at hand. Unless you’re churning out thousands of devices and really counting the pennies, price probably won't be an issue either. Speed and ease of development are really the thing that influence our choice. Whether it's just a matter of saving some of your precious hobbyist time, or it's the more tangible cost of an employee's productivity, I feel the thing that really matter when it comes to embedded development is how quick and easy it is to get started and get productive. That's what will differentiate a product that gets used from one that could certainly do the job but ends up gathering dust. So that's what I'll focus my attention on for this road test. Not "is it a capable microcontroller?" because they all are. I want to ask "is it easy and quick to get familiar and productive with?"

Hardware

An overview of the nRF5340

The nRF5340 is a dual core ARM Cortex-M33 microcontroller. One of these cores - the application processor - is "yours". It'll run at 128 or 64MHz, has 1MB for flash and 512KB of RAM and a Floating Point Unit and is USB capable.

The other core is similar - it'll only run at 64MHz and has 256kB of flash and 64kB or RAM. This is the network processor and while you're busy coding for the main application processor, this will likely be busy providing you with Bluetooth Low Energy (5.3), Bluetooth Direction Finding, Bluetooth Mesh, Thread, Zigbee, NFC, ANT, 802.15.4 or other proprietary 2.4GHz protocols. The recently announced Matter protocol is no problem either.

It's frankly an embarrassment of riches, isn't it. You're probably only going to scratch the surface of what the nRF5340 can do. And all of this comes in a tiny 7x7mm package which - if we weren't in the middle of a global hiccup of semiconductor supply - I'd probably be saying was ridiculously cheap too. The prices I see quoted in quantity right now around the $7 - $8 mark but in a normal year would likely be significantly less.

The nRF5340 (standard) development kit

The nRF5340 IC is available on a couple of user-friendly development boards. The first is the nRF5340 DK. This is your standard fare of a PCB with an array of headers, buttons, LEDs, and a built-in onboard debugger. If you’ve used any of the array of Nordic Bluetooth SoC development board (such as the nRF52840) then it will look very familiar. The nRF5340 is the latest SoC (System on a Chip) in the Nordic Bluetooth line-up and it's the best spec’d.

The only thing which might have been nice was if the dinky little nRF52840 Dongle had been updated with an nRF5340 version. Maybe it was hard to upgrade the microcontroller and still keep the cost down.

The range of Bluetooth SoC development boards can be seen here, although the nRF5340 Audio DK is strangely absent. I suppose it's new, but it doesn't seem too new to be included.

The nRF5340 Audio development kit

This road test however is not for the standard development board. This road test is for a development board that has a focus on the Bluetooth LE Audio side of things. It still has the same nRF5340 SoC but has paired it with the nPM1100 Power Management IC and a Cirrus Logic CS47L63 Audio DSP to help you get started with Bluetooth LE audio a bit more easily. The board also seems to have taken some styling cues from the Power Profiler Kit II.

You can see the top and plastic covered bottom of the nRF5340 Audio DK in the photo, alongside the larger nRF5340 DK - which doesn't have a focus on Bluetooth LE audio. One of teh development kits is power by the included 3.7V LiPo battery. It's great that a battery is supplied. I was initially concerned that the tiny 3-pin connector meant that it would be very difficult to recharge the battery once it was exhausted, but the nRF5340 DK will even recharge the battery when connected over USB-C. Talking of USB-C, this is the first development board that I've come across that uses it. I'm sure there are others, but it's the first time that I've seen it.

The documentation available for the hardware is as impressive as the board itself. There are detailed drawings. There’s a list of all the solder bridges you might want to change – all 24 of them! There’s also a comprehensive set of test points available on the board. I was amazed to find that there’s a total of 69 test points on this credit-card sized board. The six for the DSP are on the bottom, but the rest are easily reached with an oscilloscope probe on the top.

You'll find all this detailed hardware information here on the Nordic site, but he's a snippet to ilustrate the quality of the content.

Software

At the risk of repeating myself, I would still rate this awesome device as a fail if it wasn’t easy to get up and running and push some code to the shiny new development board. Let’s start where we always need to get started – installing a development environment on a PC.

A little bit of history

Now, I’ve had some past experience developing for Nordic devices – mainly the nRF5340’s predecessor the nRF52840. I remember a few years ago installing their Segger Embedded Studio IDE. It was reasonably simple to install but as far as I recall the concept of soft devices, hardware IDs and configuration didn’t click very easily with me. It all worked OK and the documentation was all there, but never felt easy. As far as I can tell, it’s still possible to use Segger Embedded Studio, but it no longer recommended.

A year or so later, after doing other things, I briefly jumped back into development with Nordic and things had changed. I remember having to use something called west on the command line. It felt different, but still not intuitive and easy to get to grips with.

After returning (yet again) to Nordic I see that things have changed again.

Getting started

The Getting Started guide for the Audio DK initially takes you through 4 steps

• Take it out of the box
• Power it via USB-C
• Turn the power switch on and see it light up
• Use the supplied battery and see it light up

I have to say that this seems like a bit of a waste of time. It might have some Bluetooth application running on there, but if it is then we’re not told this and we certainly can’t interact with it. Maybe it’s just running “blinky”?

The next step in the getting started guide is to install the latest toolchain before moving on to the documentation.

Installing the nRF Connect SDK

Nordic’s current toolchain in called the nRF Connect SDK. The installation instructions seem OK. There is the option to install the required components manually. The instructions for this seem comprehensive but fairly lengthy and potentially error prone. I decided to stick to the automatic installation. I notice that only Windows 10, Ubuntu 20.04 LTS, and MacOS 10 are fully supported, although I suspect later versions will work fine. I’m using Windows 11, so we’ll see.

So on with the “automatic” installation...

1. First you have to install nRF Connect for Desktop. It’s a small download that installs and runs from the user’s AppData folder. I’m not too keen on that setup, but OK. Nothing too tricky so far, but we’re not done yet.
2. nRF Connect for Desktop will let you install the Toolchain Manager.
3. Open up the newly installed Toolchain Manager.
4. The Toolchain manager will let you install the SDK. This is about 5GB and so takes a while.
5. The SDK will let you update the SDK or update the toolchain (if needed).
6. You need to install Visual Studio Code separately.
7. You will need to install the nRF Command Line Tools to use Visual Studio Code.
8. nRF command line tools will install Segger J-Link.
9. Visual Studio Code will let you install the nRF Connect for Visual Studio Code.
10. There is also an nRF Connect for Visual Studio Code Extension Pack you probably want too.

Well, I’m sure glad I didn’t pick the manual installation!

Building and programming using script

The next section in the Getting Started guide refers you to the Audio DK sections of Getting Started guide for the nRF Connect SDK. This guide seems comprehensive, bit it’s also very dense. The are lots of sections which assume knowledge and refer you to more sections in more guides (or even an 8-10 hour training course) for background.

https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/

Sometimes I felt like I’d been going round I circles and ending up following links back to where I started. Anyway, on with building and programming the device(s) using a python script.

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/nrf5340_audio/README.html#building-and-programming-using-script

The idea is that you find out the serial numbers of your Audio DKs, enter them into a JSON file to specify them as a gateway or earbud (left or right) and the script will program them as appropriate. If only it was that easy. Considering I’d followed the instruction for installing the required toolchain, I hit many roadblocks!

Buildprog.py failed with "No module named 'colorama'"

This was easily fixed with pip install colorama”, but this dependency shouldn’t be missing and I should be expected to know about python package management to program a microcontroller in C.

Buildprog.py failed with "No module named ‘prettytable’"

Same again. Fixed with a python module installation

'west' is not recognized as an internal or external command

After some digging it turns out that:

• The Toolchain Manager will install all Python dependencies into a local environment in the Toolchain Manager app, not the system. If you install manually, see Install additional Python dependencies for instructions on how to install the Python dependencies and Updating repositories and tools for information about how to keep them updated.
• I needed to install some things that were said to only be part of the manual installation!

Incorrect python dependency instructions

It turns out the you need to install the dependencies from the ncs/{version} folder

Restrictive path length requirements

Eventually I managed to get "python buildprog.py -c app -b debug -d both" to work. There was a large amount of text output.Luckily I read it, as buried in there was a warning about a path being too long. I’d chosen to install the SDK under “D:/Documents/Nordic” but the very large paths created under that were too much. The 19 characters I’d chosen took it too close to the 250 character limit. Hmmm… not really me doing much of that now, is it?

Incorrect programming instructions

So now I’d successfully built the code, it needed to be flashed to the devices. I followed the instructions and used "python buildprog.py -c both -b debug -d both -p --recover-on-fail". This promptly failed with unrecognised option recover-on-fail.

I tried reducing it to “-r” and my PC crashed. I tried leaving the option off and was told I needed the recover option. I tried –recover and something worked. Eventually I worked out that the option should have been --recover_on_fail (with underscores)

Building and programming using the command line

There is the option to use the command line instead of scripts, but the guide says this is the same but more long-winded and error prone. (I certainly don’t need more of that!) It seems this is just manually running the commands that the python script would have generated for you. I’m going to pass on this.

Testing

Testing the prebuilt hardware together

OK, so now I have two devices with running Bluetooth LE Audio code. One is a gateway and one is a mono earbud.

The gateway automatically appeared as an audio output device and a microphone in Windows. All I needed to do was to select this new device, play something and pop some headphones into the audio out jack of the earbud device. It worked! The SDK part of getting here was painful, but the operation was very smooth. The devices automatically paired and just worked.

For the road test we were supplied with 2 devices so I now have a gateway and one half of a pair of earbuds. It worked, but there were some quirks that I put down to it not being a stereo pair. Obviously, I only heard the left channel, but I also found that:

• the play/pause button on the device didn’t work
• whilst the volume controls did work, they just changed the on-device volume and I saw no volume changes on the PC.

Testing with other Bluetooth LE audio hardware

Before I applied for this road test, I did a bit of research onto Bluetooth LE and the new LC3 codec that comes with it. I felt that a good way to test out Bluetooth hardware was not just to test whether some nRF5340 Audi DKs worked together, but whether they worked with other BLE devices. Unfortunately, Bluetooth LE audio is in its infancy and it seemed pretty much nothing was ready for it. One of the only things I did see, was a rumour that the just-announced-and-yet-to-be-released Google Pixel 7 Pro might support it. To cut a long story short, it felt like new phone time anyway and I pre-ordered one!

To be honest it was a long shot and I’ve seen no confirmation since it arrived, but I thought I’d give it a go. Deep in the developer settings of the phone I found a checkbox saying “Enable Bluetooth LE Audio”. So maybe it does support it! I couldn’t see any reference to the LC3 codec so I can’t be sure whether it’s being used or whether it can drop back to SBC.

I had to unpair the earbud from the gateway by pressing BTN 5 on bootup, but I could then pair it to my phone. Success! Once again, it worked with the caveats of the play/pause and volume button behaviour.

Spurred on by this success, I reprogrammed the second Audio DK as a right earbud and redid the pairing. Now I had a proper set of TWS (true wireless stereo) earbuds and could hear music from my phone in stereo. As a bonus, the play/pause now worked and the volume control (on either device) controlled both earbuds and showed the volume control changing on the phone. I now had perhaps the largest and bulkiest set of wireless earbuds you’ve ever seen!

Some audio issues

Whilst the audio quality using one earbud was great I did find that no matter what I did, I got some odd regular clicking in my right earbud. I also managed at one point to get some very odd distortion that sounded like I was underwater. This is however a development kit and being used with a developer-only feature on my phone, so I didn't worry too much. It’s not intended to be a commercial product. If I was designing one using this kit though, I’d be all over this to make sure it wasn’t a showstopper.

Trying the standard nRF5340 DK

I already had an nRF5340 (non-audio) DK before starting this road test, so I wondered if it would be possible to use this as the gateway. It has a USB connection and the same BLE radio, so in theory it could work.

I put the serial number of this DK into the python script and it quite happily flashed it with the gateway firmware. However, when plugging it in it wouldn’t appear as an audio device regardless if which USB plug I used.

I spent a while looking at whether I needed to make some changes to the device config files to ensure the build was using the right pins on the nRF5340 IC, but this led me down more paths through the SDK documentation. When I realised that the nF5340DK config files seemed missing from the board configuration in the SDK I decided it was not worth investigating further.

The SDK documentation has bits stating that “it works like this except for the nRF5340DK” and “the nRF5340 Audio DK differs from other devices in that”… It just seemed like too many rabbit holes.

Summary

As you can probably tell, I was very impressed with the hardware but then felt very let down by the software. I genuinely wrote the bit about the software and development experience being key before I found out that this was whether the nRF5340 Audio SDK was lacking.

What I also found really odd was the total lack of support for using Visual Studio Code as an IDE and for building and debugging from there. I feel that if you can't take some sample code, run it, and step though what it's doing then it doesn't really fee llike you have a grip on beling able to understand and extend these samples. I started out with embedded development using TI's MSP430 line of devices. I miss just installing a simple IDE, opening an example project and hitting F5 (I think) to compile it. flash it, and start debugging it.

I have worked with the nRF52840DK and nRF5340DK in the past and things were a little closer to that ideal, but this no longer seems possible for the nRF5340 Audio DK. I even found that once I’d upgraded my SDK that my old VS Code projects no longer worked. I’m sure they can probably be fixed, but the process felt so broken that I didn’t have much enthusiasm for it at the moment.

I didn't notice the price of the nRF5340 Audio DK until I went to answer the question about price / performance. £153 seems a bit steep when compared to the £43 non-audio nRF5340 DK. I suppose most of this price comes down to lower volumes and "if you need it, you need it". For general Bluetooth development it would be hard to recommend this board over the standard nRF5340 DK, but if you need to work with BLE Audio then it seems reasonable. I'm hoping thet the development experience improves, as the hardware has a lot of potential.