I welcome you to this part of my review about Arduino Nano 33 BLE Sense. My review is split into multiple blog posts. You can find all my thoughts about this Arduino and related parts in chapters with name beginning with "Review" like this one. There are also articles describing test projects which I have done for gathering experiences with board and some tutorials. Main page of review contains summary and final score. Following Table of Contents contains links to other parts of my roadtest review.

Table of Contents

• Introduction
• Review of Development Board
• Review of Onboard Sensors
• Review of Microcontroller and BLE Module (this article)
• Review of Software
• Review of Documentation
• Tutorial 01: Accessing Sensor Values
• Tutorial 02: nRF52840 Application without Arduino IDE

• • Part 1 - Developing nRF52840 Application
  • Part 2 - Debugging nRF52840 Using Raspberry Pi

• Project 01: Gestures over BLE
• Project 02: Speach Reccognition and Machine Learning
• Summary and Score

Review of Microcontroller and BLE Module

In this part of my review I will describe nRF52840 MCU which is part of u-blox Nina B306 module which is present on roadtested Arduino board. I will also briefly discuss module.

Classification of MCU

Naming conventions of nRF52840 MCU are very simple. First digit refers to family and second digits refer to subfamily. There are two families. Family with digit 5 contains microcontrollers supporting Bluetooth and some other 2.4 GHz protocols. Family with 9 as first digit has support for LTE and GPS but has no support for BLE and other 2.4 GHz protocols. In history there were also family 2 and 8, but they are not recommended for new designs (NRND) now. Family 5 has three categories - nRF51, nRF52 and nRF53. nRF52 is middle family with Cortex-M4 clocked at 64MHz. nRF51 has support only for BLE (and no other protocols and advanced features of BLE) and it has less advanced Cortex-M0 Core clocked at 16 MHz. Lastly there are newer and more advanced nRF53 subfamily which is dual core system with two modern Cortex-M33 cores. One of them is clocked at 128 MHz and second one is clocked at 64 MHz. nRF52840 is most advanced MCU in nRF52 subfamily. There are other MCUs in this family which mainly differs in number of peripherals available and number of advanced features related to wireless protocols.

Clock subsystem

In comparison with other MCUs clock subsystem of this MCU is very simple and it is not configurable. MCU has internal oscillator or it can be clocked by external crystal oscillator. MCU is very strict to its frequency and allows only 32 MHz oscillators. Additionally, there could be connected 32.768 kHz oscillator for low frequency peripherals like RTC. There are no flexibility and no configurability. Clock system and PLLs are static and generates 1MHz, 16MHz, 32MHz, 64MHz and 32.678 kHz clocks. You cannot specify any simple or even complex dividers. In opposition it is very simple because you do not need to worry about clocks for peripherals. Every peripheral receives one of 1, 16 or 32 MHz clock and that is all. You do not need to calculate any prescalers, dividers and so one, because there are only single static known configuration and no variability. Disadvantage is that you cannot slow down clocks for reducing power consumption.

Address layout

Address layout is standard. Flash addresses are near zero, RAM addresses begin with 0x2, peripherals with 0x4 and 0x5, ARM features at 0xE. If you use external FLASH XIP memory, you should read them at addresses beginning with 0x12.

I do not like when some area is mapped directly to address 0 like FLAHS is. It is because when you dereference NULL pointer in your program, program do not crash. Instead of crash you read first value of vector table and even worst, first value in vector table is addressed to top of stack which is valid RAM address. I think vendors should do not map anything to address 0 but most vendors do that. Maybe it is limitation of ARM Core that something must be located at address 0 to work properly and vendors can’t do anything with it.

Interesting is concept of mapping peripherals to memory. Nordic numbered peripherals with IDs. You can easily determine begin address of block of configuration registers from peripheral ID. Similarly interrupt from peripherals has the same interrupt number as peripheral ID. Sometimes there are two peripherals mapped to the same space (in another words: they have same ID) and you can use only one of them at the same time. It is case of TWI (Two wire interface, usually referred as I2C) and SPI. There are two blocks (0 and 1) and you can use only one of bus per each block. This means that you can use 2× SPI and no TWI, 1× SPI and 1× TWI or 0× SPI and 2× SPI. In fact, there are additional independent SPI block but is limited to master only operation and do not support EasyDMA (I will describe EasyDMA later).

Pinout

The good thing of nRF52840 is pinout. There are 48 GPIOs and you can configure any peripheral signal to any pin you want. For example, you can configure TX of UART to P0.0. You can also configure it to P0.1, to P0.2, and so on. There are no limitations about that. The bad thing is that many pins are restricted to low speed signal because of possible interference with high frequency radio RF part of chip. I described this in more details in chapter Review of development board with list of Arduino pins which are not restricted by this on roadtested Arduino.

Performance

It is standard ARM Cortex M4 with FPU, clocked at 64 MHz. Performance depends on your needs. Usually it will be sufficient. There are hardware accelerators for cryptography operations. There are very useful and easy to understand DMA. This kind of accelerations may significantly improve performance of your application.

Note that this MCU is only single core. When you run BLE application on this MCU, core is shared with BLE (or other protocol) stack (stack is code which handles communication, session, and so on of the wireless protocol like Bluetooth Low Energy). Stacks are very timing sensitive. This usually mean that interrupts registered by stacks are configured with highest possible priority. You cannot do anything with it. If you are developing some (real-time) timing sensitive app, this may be significant performance issue for you. In this case you should prefer dual core BLE MCU like nRF5340. In this wireless stack is dedicated to one core and second core is free for your application.

Peripherals overview

As I mentioned in Address Layout section, peripherals are numbered and there are some restrictions. There are some standard peripherals like analog comparator, ADC, GPIO, I2S, PWM, RTC, UART, I2C, SPI, QSPI, USB and WDT. There are also peripherals that we can see in some newer MCUs but still not in all MCUs like PDM interface for microphone. There is also quadrature decode, random number generator and peripheral for generating interrupts from software.

Peripherals are designed in common way and usually support some data and configurations registers. Peripherals generates events which can trigger interrupts. Operations are usually triggered using registers with TASK In name. I like unified peripheral design, so I am satisfied with this.

There are some unique peripherals which I will describe in following sections. I will also describe some peripherals which I am missing.

Unique peripherals

There are multiple HW accelerators related to Bluetooth Low Energy support. Expect 2.4 GHz radio, there are accelerated address resolver and dedicated AES engine with support for CCM mode only for use in Bluetooth application. There are also peripheral for acting as NFC dynamic tag. Except AES block for BLE, there are also other dedicated cryptography engine and I assigned it also to category of unique peripherals while it is not so much unique. It is ARM CryptoCell 310. Most vendors developed their own proprietary cryptography engines, but Nordic did it differently. Nordic decided to use cryptography accelerator from ARM instead of designing own. Lastly there are one interesting concept and it is EasyDMA. Most vendors provide some generic DMA engine which can copy data from point A to point B and usually support some modes, but Nordic did it differently. They developed EasyDMA which is block which is part of peripherals that works with some data and allows to configure transfer buffers easily without need to configure some complex structures and controllers.

ARM CryptoCell 310

The first unique peripheral which I will describe is ARM CryptoCell 310 which is cryptography accelerator. Vendors can license it from ARM and use it in their microcontrollers. One of advantage should be that peripheral has always the same interface independently on MCU vendor and there should be unified API same on all microcontrollers. But this is only theory. I imagined that ARM provide some library like they do for standard peripherals like NVIC. But opposite is true. ARM did not provide any library for using CryptoCell and library is provided by Nordic. You can’t expect that even you use unified Arm CryptoCell you can migrate to other MCU with CryptoCell without need to change code. But in fact, this is not issue now, because Nordic is only vendor implementing CryptoCell. I have not seen any other vendor implementing CryptoCell. Arm offers CryptoCells, but for some reason vendors do not use it.

Documentation for CryptoCell is not published. Maybe it is available under NDA. Some details about CryptoCell can be found in product briefs and marketing materials. Also, CryptoCell is supported by MBED TLS library (from ARM) and there are some documents published. We can retrieve some details about CryptoCell from these documents. From known information we can determine that CryptoCell supports many ciphers including modern ChaCha and elliptic curves. CryptoCell 310 which is present in nRF52840 chip supports only AES-128 and there is no support for AES-192 and AES-256. Probably better CryptoCell 312 which is part of other Nordic chips supports this. CryptoCell has no secure persistent storage, it has write-only storage for key, but storage flush when you power off MCU. You must store key somewhere in flash and you must pay attention to this key. If your key leak, you are in big security risk. For example, when your application will contain buffer overflow security vulnerability, then attacker can take control over your device and can read private secret key from flash memory. In case of design with secure storage, key is permanently stored within security module and even compromising device does not mean compromising of private key, because anyone (including programmer and hacker) can’t access key directly.

I looked at performance and try to compare with some proprietary accelerators. I did a test, that I request to calculate SHA256 checksum of 128 KiB of data (MCUs memory does not allow store much more data). I tried it on CryptoCell, on proprietary HW accelerator on PSoC 62 platform from Cypress and on ESP32 from Espressif. I configured to run processors at similar clock frequency like nRF52840 for making comparison more objective. I used standard libraries provided by vendor and did not do any optimizations on this level. Because libraries are different, their overhead also differs. Lastly, I tried ESP32, but I did not find any library which supports HW acceleration on this platform. Most tutorials mention MbedTLS and some users says that MbedTLS support HW acceleration on ESP32 but never trust random guys on internet. I went through library internals by following function calls and have seen fully software implemented SHA256 algorithm. No acceleration was utilized on this platform and results shows it. I tried to clock ESP32 as near as possible but nearest clock speed were 80 MHz. While CPU speed was faster it took much more time to calculate hash. As you can see, performance of CryptoCell was very similar to proprietary HW accelerator and I can’t say that ARM solution is significantly better. The difference may be caused by different overhead of libraries. I classify accelerators as comparable. But CryptoCell (and proprietary solution also) is still much better than any soft implementation exactly as expected.

I think CryptoCell has potential, but it must be integrated by other vendors and Arm must develop unified platform independent library for it and promote benefit of this solution. This condition may be considered as already resolved by MbedTLS library, but I think this is not a fully independent library. MbedTLS depends on MBED and on TLS usecase. I likely to see generic cryptography library because TLS is not only use case of cryptography (and CryptoCell). For now, CryptoCell has no significant advantage in comparison with proprietary solutions which we can see in other MCUs.

EasyDMA

Second unique concept which I very like on this MCU is EasyDMA. EasyDMA is block which is integrated in many peripherals in this MCU and allow you to easily configure DMA buffer transfers between peripheral and memory. Registers for configuring EasyDMA are part of peripherals which supports this, and configurations is easy. It is just two registers. One for storing pointer to buffer and second register for storing number of entries (not bytes!) which should be read or written to buffer. After completion peripheral triggers peripheral specific event which can be configured to triggering interrupt. It is very easy to use EasyDMA. In opposition it does not support advanced features like generating interrupts when half of buffer is filled or read, complex structured transaction, and so on. It also does not support accessing FLASH memory, so you for example cannot transfer USB descriptor to peripheral and you must copy them (manually) to RAM before. Then you must enable EasyDMA transfer from RAM.

NFC Tag

Another unique feature is that there are peripheral for acting as dynamic NFC tag. NFC tags should be passive with EEPROM or dynamic tags with content controlled by MCU. Dynamic tags are usually implemented using external chips with I2C interface and MCU (or other system which can drive I2C). MCU can configure content of tag by any data it wants. Some dynamic tags are offered by NXP (NTP53x2 family for example) and ST (ST25DV family for example). But Nordic integrated this logic into nRF52840 MCU so if you are developing application using nRF52840, you do not need to utilize external chip and you can use peripheral of this MCU directly. Arduino Nano 33 BLE Sense exposes pins for connecting NFC antenna for utilizing this feature but I have not tried this as part of roadtest (I plan to try this later because this feature sounds very cool).

Missing peripherals

There are also some peripherals which we can see on other MCU platforms, but they are missing on nRF52840. One of them is CRC calculation unit. There are CRC accelerators as part of peripherals. They are used for checking integrity of BLE packets, NFC packets and USB packets but there are no generic CRC unit for user data. If you need calculate CRC for some reason (for example you want to verify integrity of data from sensor which support CRC), you must implement it in software.

I personally classify MCU as mid-range, so naturally there are no peripherals for driving advanced buses like ethernet or SDIO. There is no CAN bus driver. In opposition there are QSPI controller with XIP support mainly designed for expanding integrated flash memory by external one. There are no camera interface and no interface for driving any (modern or old segment) LCD display. In some newer MCUs we can also see DAC (digital to analog convertor) which is not available in this MCU also.

Review of BLE Module

In case of roadtested Arduino Nano 33 BLE Sense MCU is part of module. Module is u-blox Nina B306. Structure of module is simple. There are MCU, 32 MHz crystal oscillator and antenna. There are three variants of module with the same MCU. They differ in type of antenna. Roadtested unit have onboard PCB antenna and there are available variants with metal antenna and no antenna. In case of no antenna you must connect external antenna, but you can select whatever antenna you want.

u-blox Nina B306 is not only module with nRF52840 chip. For example there are previous roadtest of Panasonic PAN 1780 Bluetooth LE Eval Kit which is development board evaluating PAN1780 module with the same MCU.

Modules differs in dimensions, number of exposed GPIOs, technique of exposing pins (some modules has pins exposed from the bottom and some modules has exposed GPIOs as castellated holes on sides), power regulator and sometimes there are additional peripherals on module.

u-blox Nina B306 has 40 GPIOs exposed from the bottom side of module. If you need all 48 pins of MCU, you can choose PAN1780. Both modules have pins from the bottom side, so they are not hobbyist-friendly. If you look for some hobbyist-friendly module you must accept limited amount of GPIOs because it is not possible to place all 48 pins on sides of so small board. Example of module with castellated holes is Proteus-III from Würth Elektronik. It has exposed only 10 GPIO pins but module is small and can be easily soldered. If you need castellated holes, more GPIOs and accept little bit larger module, you can choose DK-9179B from DEXATEK. It exposes 24 GPIO pins. This is one of module which have also additional peripheral except standard two crystals and antenna (which are present on almost all modules). It has external flash memory connected to QSPI bus. On this platform you can use internal 1 MiB flash and additional 1 MiB external flash for storing your firmware. This results into twice large storage for your firmware. You also can use this external flash memory for storing some application data if you want. Disadvantage of this module is size.

Comparison with other Nordic MCUs

I briefly described families offered by Nordic at the beginning of this chapter. There are three families which is possible to compare. I will describe differences between models within nRF52 family and then I compare with lower nRF51 family and with more advanced nRF53. Later, I will describe possibility to migrate within nRF52 family and across subfamilies.

Comparison with other nRF52 MCUs

nRF52 family has 7 microcontrollers. Roadtested nRF52840 is most advanced of them. All microcontrollers in this family has same Cortex-M4 core clocked at same frequency of 64 MHz. They differ in memories capacity, supported advanced connectivity features and number of available peripherals. nRF52840 is only MCU with ARM CryptoCell in this family. It is also only MCU with QSPI bus driver. It has the most serial bus drivers for I2C, SPI and UART. The single limitation of this device is it does not support BLE direction finding. There are three other models in nRF52 family which supports BLE direction finding but they does not support some other feature like USB, or already mentioned ARM CryptoCell. If you want BLE direction finding and CryptoCell at once, you must go to higher nRF53 family.

Comparison with other Nordic MCUs

If you think nRF52 is overkill for you, you can go one family lower to nRF51. There are only three models and all of them are very basic. All three models have same Cortex-M0 core clocked at maximum frequency of only 16 MHz. All of them supports BLE and proprietary 2.4 GHz protocols. One model also supports ANT wireless protocol. These MCUs have very limited number of peripherals. Otherwise concepts like EasyDMA are also used in these MCUs.

nRF53 family contains currently only single model nRF5340. nRF5340 has two newer Cortex-M33 cores. One of them is clocked at 128 MHz and secondary core is clocked at 64 MHz. nRF540 is very similar to nRF52840 but brings you more peripherals, more memory, more CPU cores, more advanced ARM CryptoCell (CryptoCell 312 in comparison with 310 used in nRF52840. It also supports AES-192 and AES-256. In comparison, CryptoCell 310 supports only AES-128) and TrustZone security feature which is benefit of newer Arm cores. In section about ARM CryptoCell 310 I mentioned that nRF52840 has no secure storage for storing private keys (I also mentioned why is this storage important). nRF53840 has this storage and secure storage design looks very well. Except storing one-time programmable keys, it also supports revoking these keys. Private keys from this unit can be securely fed to CryptoCell and cannot be retrieved from CPU. This is main purpose of this key storage and it is fine that some vendors including Nordic support this. Second purpose of this secure storage offered by nRF5340 is support for something like secure boot.

In fact, when you are designing with Nordic platform, I recommend starting with nRF53 instead of nRF52 or nRF51 unless you do some very basic application. Use this lower families only in case you really know that you do not need newer features brought by nRF53. Note that many real-time applications when you need some interrupt with highest priority you cannot develop on nRF52 or nRF51 because they are only single core and interrupt with highest priority is reserved for wireless stacks which makes your application less predictive. In case of nRF53 this is resolved naturally because it is dual core MCU and wireless stack runs on only one core while second core is completely free for your (real-time) application.

Migration between Nordic MCUs

Migration depends on library used. If you are using nRF5 SDK you can migrate easily between all MCUs in nRF52 family and to nRF51 unless you use some feature which is not present in target model. You can’t upgrade to nRF53 because nRF5 SDK does not supports nRF53. In opposition, when you are suing nRF connect SDK, you can migrate between nRF52 models and also upgrade to nRF53, but you can’t downgrade to nRF51 which is not supported by nRF connect SDK.

Migration between non-Nordic MCUs

When you use some environment like MBED, you can try this. But in most cases I consider it mostly impossible because there are many very platform specific things and Nordic-specific libraries.

Comparison with other MCUs

Over years many big MCU vendors implemented support for BLE to their MCUs. BLE MCUs which I have found and briefly looked are:

• STM32WB family from ST
• PSoC 4 and PSoC 6 subfamilies from Cypress
• CC2xxx subfamilies from Texas Instruments
• ERF32 subfamilies from Silicon Labs (one of this MCUs is present on roadtested board Silicon Labs BLE Explorer Kit, so you can read more detailed review)
• some MAX326xx from Maxim also support BLE
• DA1469x family from Dialog Semiconductor
• BC32F7611 MCU from Holtek
• aBLE serie from ABOV Semiconductor

There are also some non-Arm MCU. For example:

• ESP32 from Espressif
• RX23W from Renesas

If you are interested in any of these MCUs always check at least:

• Number of cores when you develop real-time application. If you do that, you need at least dual-core MCU.
• Memory. You need to store full BLE stack (and usually some other related large libraries) in flash memory.
• Security features. When you develop BLE app, you probably will need to encrypt some data or even better do some asymmetric cryptography. Accelerators and other security features are always welcome in this category of MCUs.
• Availability of modules. It is hard to design board with antenna and pass all required certifications. Usage of module very simplify this process.

I will not describe all of them because there are lot of them and because they are mostly very similar. But there are some significant pros of Nordic platform. Nordic has excellent support for non-BLE protocols like Zigbee, Thread or ANT. Very few other vendors support all these protocols. Mostly they are limited to Bluetooth Low Energy. But in opposition some of them can bring you some unique peripheral which is not present on nRF52840 (and mostly on any other mentioned platform). For example, PSoC 4, 6 from Cypress and RX23W from Renesas can bring you capacitive sensing for touch control. DA1469x family has integrated battery charger and LRA/ERM driver for making vibrations. DA1469x can be useful when you need vibrations for some notifications to user. ESP32 also supports Wi-Fi.

I did not find any ultimate best microcontrollers which fits all needs and supports everything, I recommend trying search by requirement to most advanced and specific peripheral. Many applications can be resolved by any of mentioned (or even non-mentioned) MCU.

Availability and Price

Raw nRF52840 is priced at 6.98 USD when you buy 1 piece and 5.25 USD when you buy 100 pcs on Newark at the time of writing this article. At the time of writing this review it is unavailable and it is expected to arrive in four months but note that at time of writing this review we are facing large IC components outage on the market. I think price is acceptable for this MCU. I also like that buying single piece does not add so much worth. Other MCUs usually goes up to twice the price when you buy order single piece in comparison with comparison to buying 100pcs. But this is not the case of nRF52840. Lowest listed price is 4.8 USD for 250 PCS and single piece price is 1.45x more which is pretty good. 10 pieces cost 1.33x more. I consider these coefficients as good.

BLE Module is not available at Newark, but competitor store lists it as 13.4 USD for one piece and 7.98 USD for 500 pcs. At the time of writing this chapter it is also out of stock. Lead time is 26 weeks. I consider these prices as acceptable but there is opportunity to get another module cheaper. Because most nRF52840 are very similar, it is good idea to check list of actual available modules at Nordic website before buying.

Summary

nRF52840 is good MCU featuring some interesting concepts, good cryptography engine and excellent support for 2.4 GHz wireless connectivity.