Nordic is one of the large’s Bluetooth LE chipset vendors, and their nRF52 series of BLE chipsets has become the de facto leader in BLE products. With the release of the nRF54L series, Nordic is upgrading the nRF52 and bringing lower power, more memory and capabilities and support for the recently adopted Bluetooth 6.0.
We’ve built a lot of Bluetooth enabled products over the years. Starting with the nRF8001, through the nRF51 and then nRF52. It’s easy to say that the nRF52 has become our go to device when developing BLE products. The nRF54x is a fourth generation BLE SoC that continues the long line of upgrades from Nordic, with some interesting changes in the system.
The nRF54L15 is designed to be an upgrade from the nRF52 chipset, with a lot of improvements, lower power, and Flash replaced by RRAM.
Protocol Support
Like most Multi-protocol SoCs, the nRF54x family of devices supports a variety of protocols which enable creating complex connected products
- Bluetooth 6.0 Low Energy with Support for Channel Sounding
- Thread and Matter
- Zigbee
- Proprietary 2.4 GHz protocols up to 4 Mbps
- NFC Tag
The nRF54, like other chipsets such as the nRF52, is designed to integrate with the nRF70 Wi-Fi chipsets for Dual BLE + Wi-Fi.
CPU and Processing
The nRF52 used a single Cortex-M4 processor for both the Bluetooth and Application. This reduced cost and some power, but also limited the capabilities of the device. Nordic had to move to dual cores for the nRF53 because running both the Bluetooth Stack and LC3 Codec for LE audio was not possible.
Like the nRF53, the nRF54 ships with two cores. One is an ARM Cortex-M33, while the coprocessor is a RISC-V processor, both running at 128MHz. This is an additional core compared to the nRF52. However, the RISC-V processor here is designed primarily to replace the need for external ICs to perform processing and is designed for software defined peripherals.
Offloading operations dealing with peripherals to the RISC-V core means lower power and less problems meeting timing requirements, which could be a problem with the nRF52 if you need it to manage all of that.
RF Performance
One thing we would have liked to see was some more improved sensitivity. The nRF54L has -96dBm sensitivity at 1Mbps, which is quite good but doesn’t match the nRF54H with an industry leading -100dBm sensitivity, or the nRF5340 with -98 dBm. The more sensitivity the better because it allows us to get more link margin and range on designs.
The +8dBm TX Output power matches the nRF52840 we’ve used so much.
RRAM and RAM
Practically every BLE vendor has kept increasing the Flash size in devices. Gone are the days of 256kB and 512kB and dealing with barely any space. As the Bluetooth Specification has grown, more flash was required. The nRF52840 was one of the first devices with 1MB of flash. The nRF54L completely changes the picture with a new memory called RRAM with 1.5MB of it in the nRF54L15 part. This large flash is needed to support complex protocols like Thread and Matter alongside Bluetooth LE, as well as for code for the VPR RISC-V processor.
The nRF54 family introduces a different memory called Resistive Random Access Memory (RRAM) that replaces flash in previous generations. This memory doesn’t require erasure like Flash memory does. If you’re familiar with Flash memory, you know that by default all memory is set to 0xFF. You can write data to it, which sets the bits to 0 (instead of setting bits from 0 to 1). However, to be able to write new data you have to erase it.
RRAM is very different, but it doesn’t require an erasure cycle which speeds it up
Flash erasure is complicated, introduces both latency and wear on the system. When erase is active it has to boost up the voltage in order to apply it and force the memory to erase. RRAM doesn’t require erasure, which makes it much lower power.
The datasheet shows that RRAM is specified for typical 10000 cycles of endurance. meaning, you can write to it around 10000 before expecting failure. This isn’t as good as the minimum 10000 cycles of flash memory which is essentially guaranteed. We expect Nordic may revise this specification as it performs more testing.
There’s a question of RRAM’s performance.
As you can see from the table below, flash writing is faster on the nRF52 at 41us, if we only account for a single word, and 85ms for a whole page. RRAM is slower on single words, 65us. However, for sequential address ordered writes, it drops to 22us. This is almost 50% faster when writing large amounts of data, like firmware updates or configuration which are large contiguous chunks of data.
Speeding up writes has an overall positive impact on power consumption because it allows the system to go to sleep much faster.
The lower cycles of endurance may not be a huge impact, and Nordic is likely counting on that. Firmware updates are infrequent, and the change is not big enough to impact much.
Different devices in the nRF54L have different RRAM and RAM amounts as follows:
- nRF54L15 – 1524 KB RRAM and 256 KB RAM
- nRF54L10 – 1022 KB RRAM and 192 KB RAM
- nRF54L05 – 500 KB RRAM and 96 KB RAM
Power Consumption
BLE devices are mostly battery operated devices, and lowering power consumption is critical. The nRF54L improves some of the performance with RRAM and other features.
For the Radio, the nRF54L has almost identical current of 5mA in TX at 0dBm vs 4.8mA for the nRF52.
RX current however has improved significantly, 3.2mA vs the nRF52’s 4.6mA. Since radios spend most of their time in RX mode waiting for packets, this will reduce system power consumption significantly. However it’s important to note that the nRF53 has 2.7mA in RX.
It’s interesting why some of the improvements of the
Analog Peripherals
nRF52
The nRF52 had a 12-bit 200ksps ADC. The nRF54L provides a 14-bit ADC which can achieve 31.25 ksps, or 250ksps at 12-bit, and up to 2MSPS in 10-bit.
In many designs we’ve had to attach an external ADC to achieve better readings. With 14-bit ADC you can oversample relatively quickly to achieve 16-bit effectively.
4Mbps PHY
One of the features the Bluetooth SIG is actively working on is High Data Throughput, a set of improvements to the specification that would allow up to 8Mbps, up from the 2Mbps introduced in the Bluetooth 5.0 specification.
By adding a 4Mbps PHY to chips, Nordic is likely getting ready for these changes. Once the hardware is capable of supporting it, the rest is up to the Bluetooth stack.
Why did they choose 8Mbps? I think we can take a good guess. The higher the throughput, the lower the range. This is just physics that applies to all communication systems. 6Mbps and 8Mbps would represent quite a drop in range, and would only necessarily apply to.
4Mbps represents a compromise between the complexity of the devices (and cost) and performance. Adding support for every modulation would complicate the device in various ways. Our guess is Nordic Semi figured that 4Mbps would cover a large number of practical cases without adding a huge amount of complexity. 6Mbps and 8Mbps likely represent
GRTC
You may be familiar with the RTC module in previous generations of nRF5x devices. The GRTC is the Global real-time counter that contains a security feature.
One really nice aspect of the GRTC is that instead of being just 32-bit wide, it’s 52 bits wide. This provides around 142 years before it wraps around, which avoids having to deal with a wrap around case.
LE Audio
One of the challenges the nRF52 chipset had was that it could not manage the Bluetooth stack and the LC3 Codec simultaneously. Because of this, Nordic created the nRF53 series of devices which has a CPU core. The nRF54 series is designed as an upgrade to the nRF52 chipset, and as such is not designed for LE Audio support.
If you need LE Audio, you will either need to use the nRF5340 or the nRF54H chipset
Variants
The nRF54L15 is one of three variants in the family which includes the nRF54L10 and nRF54L05.
The nRF54L05 is the smallest device with 500 kB of RRAM and 96 kB of RAM. It’s perfect for small sensors and beacons that don’t require significant capabilities, while the nRF54L10 is a middle of the road device if you don’t need all the RRAM of the nRF54L15.
Choosing a smaller device is better done when the design is well defined. It’s easier to go from a larger device to a smaller one. But feature creep and changing requirements can impact it, and we have often found that the switch doesn’t always make sense unless you are targeting very high volumes where that cost matters.
Errata
New chips are great, but it often takes some time before all the issues are hammered out. The nRF54L is still preliminary and the Objective Specification document (Datasheet) is only at version 0.8 as of the writing of this article. The chip launches Revision 1 with about 24 issues. Here’s a few of the major items. You should review the Errata to see whether
Errata #41 – RADIO: Sensitivity is degraded on n*32 MHz channels
Sensitivity is reduced by about 2dB on channels which are multiples of 32MHz in the 2400MHz band, specifically 2432MHz and 2464MHz.
This issue is almost undoubtably a leakage of the system clock onto the radio which causes loss of sensitivity and isn’t all that rare. A 2dB loss isn’t huge, and especially since it happens on two channels it should not impact the system significantly since BLE uses frequency hopping (and adaptive frequency hopping in many cases).
Errata #20 CLOCK: RADIO payload is not transmitted
This is a significant issue where the payload sent after the preamble is not transmitted and happens when the CPU and peripherals are sleeping and the Radio starts its transmission. The workaround increases power consumption
Errata #21 SPIM: MOSI line toggles after transmission ends
The chip adds an extra transition on the MOSI line at the end of the transmission, where the clock has stopped toggling. The good news is that because the clock has stopped toggling, whatever devices you’re talking to won’t clock in that extra bit.
Some devices may run into problems with this issue, and there’s no workaround because it’s in the hardware itself. It’s a bit surprising an issue like this would happen since Nordic has a long history with the SPIM module and this sounds like a digital design problem that would have been caught early in the design.
Errata #30: CLOCK, GRTC: GRTC operates incorrectly at low temperature
This issue results in the drift of the GRTC module at low temperatures when using HF
