Designing Low-Power Bluetooth LE Products

Changing the version will not affect your certificate
Design
Lesson 1 – Power consumption essentials
4 Topics | 1 Quiz
A typical Bluetooth LE product architecture
Bluetooth LE communication methods
Electrical quantities
Exercise 1 – Estimating power budget
Lesson 1 quiz
Lesson 2 – Designing with a Nordic PMIC
7 Topics | 1 Quiz
PMIC overview
System management features with Nordic PMICs
System efficiency considerations
PMIC hardware integration
PMIC software integration
Getting started with Nordic PMICs
Exercise 1 – Powering nRF54L devices from a single AA/AAA battery
Lesson 2 quiz
Measure
Lesson 3 – Tools and best practices for power measurement
5 Topics | 1 Quiz
Current measurement fundamentals
Current measurement equipment: Capabilities, limitations, and best practices
Measurement setup validation and error mitigation
Exercise 1 – Setup verification using System OFF
Exercise 2 – Bluetooth LE advertising power profiling and data extrapolation
Lesson 3 quiz
Optimize
Lesson 4 – Bluetooth LE power optimization
4 Topics | 1 Quiz
Bluetooth LE advertising parameters and power consumption
Bluetooth LE connection parameters and power consumption
Exercise 1 – Optimizing power consumption during Bluetooth LE advertising
Exercise 2 – Optimizing power consumption in a Bluetooth LE connection
Lesson 4 quiz
Lesson 5 – SoC specific power optimization I
6 Topics | 1 Quiz
Clock sources
Peripherals
Memory retention and sleep modes
Exercise 1 – Estimating and measuring how clock sources affect power consumption
Exercise 2 – Comparing current consumption of peripherals from different power domains
Exercise 3 – Measuring the impact of RAM retention settings
Lesson 5 quiz
Lesson 6 – SoC specific power optimization II
6 Topics | 1 Quiz
GPIO interrupt types on the nRF54L Series
DPPI Distributed programmable peripheral interconnect
Direct Memory Access (EasyDMA)
Exercise 1 – Measuring sleep current with different GPIO interrupt types
Exercise 2 – Reducing CPU activity by connecting peripherals with DPPI
Exercise 3 – Reducing current consumption with EasyDMA
Lesson 6 quiz
Monitor
Lesson 7 – Remote monitoring of Bluetooth LE devices with nRF Cloud
8 Topics | 1 Quiz
Why remote observability matters for low-power Bluetooth LE devices
Key data points for Bluetooth LE connection stability and power efficiency
Integrating the Memfault SDK into a Bluetooth LE peripheral application
Fleet-wide analysis and debugging with nRF Cloud
Exercise 1 – Setting up the Memfault SDK on an nRF54L Series DK
Exercise 2 – Exploring the automatically collected Bluetooth LE metrics
Exercise 3 – Observing the impact of connection parameter changes on metrics
Exercise 4 – Invoking a firmware update over Bluetooth LE (OTA)
Lesson 7 quiz
Get your certificate!
Get your certificate!
Feedback
Feedback

If you are having issues with the exercises, please create a ticket on DevZone: devzone.nordicsemi.com
Drag & Drop Files, Choose Files to Upload You can upload up to 2 files.
Loading
RegisterLog in

Current measurement fundamentals

Measuring current consumption can often be a bit tricky. In this lesson we will go through the most common pitfalls, different techniques we can use, and how to make sure that the data we get is accurate. We will learn how to prepare the hardware for current measurements, how to verify our measurement setup, and how to interpret the results.

The biggest problem when measuring current is that the results we are getting are simply wrong, but since we do not have any ways of verifying, lack of experience in identifying issues with the setup, or identifying obvious mistakes in the current profile, or consumption, we simply accept the result as it is and try to make sense out of it. We try to fit observations with our assumptions.

  • First we need to learn about different measurement techniques, what we can expect from the results, what to use in different scenarios etc.
    • This is important so that we can identify weaknesses in the methodology.
  • We need to have an idea of what is realistic in terms of current consumption. Ballpark numbers on active currents, like CPU and peripherals, vs idle current. uA vs mA.
    • This is important so that we can do an assessment of the validity of the results we get.
  • Have a plan on what you want to measure, divide measurements into separate tasks. Which technique can be used for which part.
    • This is important so that the results we get have a value, that they can actually be used to improve the design, or identify real issues with the design

Dynamic range

No current measurement equipment is actually measuring the current. What it measures is the voltage drop over a series resistor, also called shunt resistor, or measuring shunt, which is placed in series with the load/DUT.

So in practice we have a resistor in series with the DUT, and we then measure the voltage drop over this resistor and convert it into a current using Ohms law, which states that voltage and current are proportional, with a given proportionality constant. And since the proportionality constant, in our case, is the value of the shunt resistor, which again is a predefined quantity, converting from a voltage drop to a current is a trivial task. I = V/R

The shunt resistor can either be added manually, in cases where we manually measure the voltage drop, for instance if we want to use an oscilloscope. Or the shunt is integrated into the measuring equipment, like ampere meters or power analyzers.

The next step is to choose the size of this shunt resistor. At a given current, a larger resistor will result in a larger voltage drop, making it easier for the measuring equipment to capture the correct current. But when the current increases, the voltage drop will eventually be too large. This means that our goal (or the measuring tool’s goal) is to choose a resistor value which will have minimal impact on the measurements, meaning as low voltage drop as possible, but still being able to measure it accurately.

The difference between the lowest measurable current, and the highest current which will not impact the DUT too much is called the dynamic range. So how large dynamic range do we actually need? On a micro controller we often have sub 1 uA sleep current, and run currents of 1 mA up to 100 mA. Meaning that we need a dynamic range that covers maybe 100 nA up to 100 mA. This is physically impossible, with a single fixed shunt resistor.

Let’s say that we have an application that has an active current of 10 mA and an idle current of 1uA. Since we have up to 10 mA current we can choose a 10 Ohm shunt resistor. A 10 mA current will give a 100 mV voltage drop over the shunt. V = IR. 100 mV will probably not impact the DUT too much. Choosing a 100 Ohm shunt on the other hand will result in a 1 V drop, which is too much. So our 10 Ohm seems like a good choice so far, and the largest resistor we can use in this case. But what happens when the current drops from 10 mA down to a 1 uA idle current, will we still be able to measure the current accurately? The voltage drop will now be 10 uV, which is too low to measure for any equipment. So in order to measure 1 uA you would probably need at least a 10 kOhm shunt (= 10 mV drop), in order to be able to measure it accurately. This will not add up, since we already established that 10 Ohm is the largest resistor we can use, because of our 10 mA active current.

So what do we do? We have two choices:

  1. Use a tool that switches the measuring shunt automatically based on the current draw.
    • This is called automatic range switching, and is used in power analyzers/SMUs and some multimeters, often bench top multimeters.
  2. Use a fixed shunt value, and select which current range area we will focus on. Either the idle current, or the active current.
    • This will be our method if we want to use an oscilloscope or multimeters which do not have automatic range switching. Often handheld multimeters where you select the range using a wheel or similar.

Issues with automatic range switching

If we choose to use a tool with automatic range switching we should be aware that the voltage source output impedance which change when switching the shunt, and it will impact measurements. How much depends on the tool. Some equipment is really good at compensating for this in software, others not so much. What happens is that when the shunt is switched there will be a sudden drop or increase in the voltage on the rail we are measuring. This will in turn lead to an inrush current going into or out from decoupling capacitors etc, giving an overshoot when there is a positive current transient, and undershoot when there is a negative current transient.

Sample rate

In order to capture the current consumption and convert it into a plot or a reading on a display, we need to sample the voltage over the shunt resistor. One sample is basically just one voltage measurement, which is either shown directly on the display, e.g. on multimeters. Or stored in a dataset, that can later be exported or plotted on a screen, e.g. power analyzers, oscilloscope.

The sample rate is how often we do this sampling. The higher the sample rate the more details we will get out of the current consumption plot, up to a certain limit.

In electronics circuits we often have many decoupling capacitors which are used as energy reservoirs, or to filter out unwanted noise. In terms of current measurements, these capacitors acts as filters, meaning that the time wise resolution will somewhat be limited. When increasing the sample rate, you will get to a point where increasing it any further will not add any details to the plot. So there will be a limit to how detailed the plots can be. Will show examples of this below

So how high sample rate do we need? It depends on our use case, so here is an example on how high sample rate you would need in order to extract different data points out of a Bluetooth LE advertising event.

200 kSa/s300 MS/s
Bluetooth LE advertising
*200k samples per second is enough for extracting the TX/RX pairs from the event.
*Due to capacitance on VDD the 300MS/s plot does not give us any more information

Using a handheld multimeter where you read the current on a display, the refresh rate on the display, and what is possible for the human eye to register will limit the sample rate to around 1 second.

Current and charge

When supplying a voltage to an active load, like an MCU, a current will flow which often will change over time. If we use a tool to plot the current over time, we then plot the instantaneous current, or in other words what the current is at a specific point in time.

We often talk about “current consumption” and a somewhat common misunderstanding is that we are now talking about a quantity, like saying that “my device has consumed 10mA”. But this is not correct. Current consumption is just the average instantaneous current over a given time, and the “quantity” in this case would be the average current multiplied by the time, which is the electric charge (Q, unit = Coulomb [C]). So if your device has drawn 10mA over the course of 1 hour, your device has “consumed” 36C (10mA x 3600s = 36C)

The unit for electric charge is Coulomb (C), but as we discussed above, charge is current (A) multiplied by time (s), meaning that we can also use As (ampere second) as the unit. If we then convert seconds to hours, and ampere to milliampere we get the more commonly used unit, mAh ( 1mAh = 3.6C), which might sound more familiar than coulomb. E.g. it is used by battery manufacturers to specify how much charge a fully charged battery can hold. In this lesson, however, we will use coulomb, C, instead of mAh.

So when do we use current consumption, and when do we use charge?

  1. We use current consumption if we want to express the average run current of our device (running over an indefinite time). This is convenient because we can easily estimate battery life time. E.g. if our battery has a capacity of 100mAh, and our devices draws 10mA in average. The battery will last 10 hours (100mAh / 10mA = 10h)
  2. We can measure the steady state current in different “operating modes”, like CPU run current, radio TX run current, idle current etc. We use this information to identify parts of our application that can or should be optimized. Or just to explain the current consumption in general, e.g. when evaluating different solutions.
  3. We use charge when looking at sections of a plot, e.g. when looking at one Bluetooth LE event, or one CPU event running a specific algorithm or similar. We can then use this information to decide on the Bluetooth LE interval, or how often we can wake up to do this specific CPU task, while not using too much current in average. More on this in the Periodic signal and extrapolating data section where we use the charge to find the average current at different intervals

An important aspect here is that current consumption during an active event, like a Bluetooth LE advertising event, is not a very interesting parameter. It doesn’t really give us any information, because we also need to include the time frame. But if we include the time frame, as in multiplying with time, we get the charge.

Below are two plots illustrating this point. Both show the same Bluetooth LE event; the only difference is the placement of the cursors. In the left plot we get 2.0mA in average between the cursors, while in the right plot we get 1.5mA. Only because we include a bit more of the idle current within the cursors, the average current is significantly lower. This shows that recording the average current during a event like this has no value, unless we include the time between the cursors as well. But then again, current multiplied by time equals charge, so the information we really want here is in fact the charge, which you can see is the same in both plots. This is the information we use to calculate or estimate the total average current in the end.

Average current during event: 2.0mA
Event total charge: 8.0 µC
Average current during event: 1.5mA
Event total charge: 8.0 µC

Power and energy

Although not so common, we can also use power and energy instead of current and charge. They only differ by a factor, which is the voltage.

Rate of flowQuantity
Current [A – ampere]Charge [C – coulomb]
x Voltage [V – volt]x Voltage [V – volt]
= Power [W – watt]= Energy [J – joule]

Here is a plot that shows a measurement of a Bluetooth LE advertising event with three TX packets, illustrating the relationship between the current and power.

  • Yellow = Current
  • Blue = Voltage
  • Green = Power

So as you can see power is just the current multiplied by the voltage (in this case 3.0V), and energy is the charge multiplied by voltage.

So far so good. Things start to get a bit more interesting when we change the voltage.

Here we have the same Bluetooth LE event, with the three TX packets, running at 1.8V instead:

So what information can we extract from these two plots?

After adjusting down the voltage from 3.0V to 1.8V,

 VDD = 3.0VVDD = 1.8V 
Charge8.0 µC11.9 µC49% increase
Energy24.1 µJ21.3 µJ12% decrease

Inside the nRF54L SoC there is a DC/DC regulator that regulates the VDD voltage down to the internal operating voltage of the device (0.7V to 0.9V). If the regulator was an ideal regulator, we would have seen the same power/energy going into the device, regardless of the input voltage. And we would have seen that the current/charge increased with the same factor as the voltage decreased. So in the example above, the charge would have increased from 8.0µC to 8.0µC x 3V / 1.8V = 13.3 µC, if we had an ideal regulator.

It can be useful to think of power/energy being drawn inside the chip, instead of current/charge. E.g. sending a radio packet at a given TX power will always consume a given amount of energy. And all the energy needed to send this packet will have to come from the VDD supply. This means that the total energy in the plot above, the total energy going into VDD, is a sum of the energy used to send the TX packets, regardless of the VDD input voltage, and the efficiency loss inside the regulator.

And, as mentioned above, the current/charge will scale opposite to the voltage so that the same “amount” of power/energy is supplied on VDD. Since power equals current multiplied by voltage (P = I x V).

Then finally we need to take the efficiency loss inside the DC/DC regulator into account. At 3.0V we have a larger voltage drop over the regulator than at 1.8V, hence we have slightly higher energy consumption at 3.0V than at 1.8V, because of the efficiency loss. Which explains the 12% decrease in energy consumption when going from 3.0V to 1.8V in the table above.

So when designing our product, what is best? Do we want low current or low power? Since we often only talk about current consumption when evaluating and measuring different solutions, it would make sense that the current consumption is what we want to optimize. But an important aspect here is that when measuring current, we always choose the voltage first, so that it matches the target voltage of our final design. Or we just choose a common voltage (like 3.0V, as we do in the datasheet), and then convert the numbers later when we know the operating voltage of our design.

Ultimately, the total energy is what we want to optimize, so running at as low voltage as possible is best. But there are often other considerations to take. What is the operating voltage of other components on the board? Are they compatible with 1.8V? What is the battery voltage? If we use a 3.7V lithium battery we need an external regulator anyways, to regulate the voltage down to 1.8V, but will the efficiency of this regulator be as good as the internal regulator on the nRF54 when running at 3.0V? If we use a 3V coin cell battery, should we add another regulator stage to get the voltage down to 1.8V? If this regulator stage also introduces efficiency loss, we might be better of supplying the nRF54 directly from the battery at 3V. Often the supply voltage is decided by other factors in our design. But a good rule of thumb is that a lower voltage is more efficient.

Periodic signal and extrapolating data

When you have a periodic signal, instead of measuring the current over a longer time in order to obtain the average current, you can break down the measurement into smaller pieces. First you can measure the total charge of the event which occurs periodically, then measure the idle current, and use this to calculate the average current.

This can be convenient when you do not have access to a tool that can measure over a longer time period, or if you want to quickly get the average current at different periods, for example different Bluetooth LE advertising intervals, CPU processing intervals, etc.

Here is an example showing how we can use a oscilloscope to find the charge for a Bluetooth LE advertising event, and use a multimeter to measure the idle current. Then at the row below we can see that our method is giving us the correct results by comparing with measurements using a power analyzer.

Event chargeIdle currentAverage current
Oscilloscope and ampere meterI_avg = Q_event / interval + I_idle
Q_event = 6.8 uCI_idle = 2.84 uAI_avg = 6.8uC / 1s + 2.84 uA = 9.64 uA
Power analyzer
Q_event = 6.8 uCI_idle = 2.88 uAI_avg = 9.69 uA

Using this information we can create a list of the average current resulting from different advertising intervals. This is useful when we want to evaluate different options, so we don’t have to do a lot of different average current measurements.

IntervalAverage current
 avg = Q/interval + idle
20 ms343 uA
100 ms71 uA
500 ms16 uA
1000 ms9.6 uA

Finally, take note of how the cursors in the following plots are placed. The left plot will show the correct average current. While the right one is not correct. The measurement duration (in this case the distance between cursor 1 and 2) should be an integer multiple of the signal period. If you have multiple periodic signals with different periods, then the cursor distance should be an integer multiple of the least common multiple of both periods for accurate measurement.

Here the signal period is 100ms. And in the left plot we have a cursor distance of 300ms, which is a multiple of the 100ms period. Note that this number also matches our calculated number from the table above.

CorrectWrong
avg: 71 uAavg: 62 uA

Make sure to Log in or Register to save your progress

Back
Next

Nordic Developer Academy Privacy Policy

 

1. Introduction 

In this Privacy Policy you will find information on Nordic Semiconductor ASA (“Nordic Semiconductor”) processes your personal data when you use the Nordic Developer Academy.

References to “we” and “us” in this document refers to Nordic Semiconductor.

 

2. Our processing of personal data when you use the Nordic Developer Academy 

2.1 Nordic Developer Academy 

Nordic Semiconductor processes personal data in order to provide you with the features and functionality of the Nordic Developer Academy. Creating a user account is optional, but required if you want to track you progress and view your completed courses and obtained certificates. If you choose to create a user account, we will process the following categories of personal data:

  • Email
  • Name
  • Password (encrypted)
  • Course progression (e.g. which course you have completely or partly completed)
  • Certificate information, which consists of name of completed course and the validity of the certificate
  • Course results

During your use of the Nordic Developer Academy, you may also be asked if you want to provide feedback. If you choose to respond to any such surveys, we will also process the personal data in your responses in that survey.

The legal basis for this processing is GDPR article 6 (1) b. The processing is necessary for Nordic Semiconductor to provide the Nordic Developer Academy under the Terms of Service.

 

2.2 Analytics 

If you consent to analytics, Nordic Semiconductor will use Google Analytics to obtain statistics about how the Nordic Developer Academy is used. This includes collecting information on for example what pages are viewed, the duration of the visit, the way in which the pages are maneuvered, what links are clicked, technical information about your equipment. The information is used to learn how Nordic Developer Academy is used and how the user experience can be further developed.

 

2.2 Newsletter 

You can consent to receive newsletters from Nordic from within the Nordic Developer Academy. How your personal data is processed when you sign up for our newsletters is described in the Nordic Semiconductor Privacy Policy.

 

3. Retention period 

We will store your personal data for as long you use the Nordic Developer Academy. If our systems register that you have not used your account for 36 months, your account will be deleted.

 

4. Additional information 

Additional information on how we process personal data can be found in the Nordic Semiconductor Privacy Policy and Cookie Policy.

‍‍ 

Nordic Developer Academy Terms of Service

 

1. Introduction

‍These terms and conditions (“Terms of Use”) apply to the use of the Nordic Developer Academy, provided by Nordic Semiconductor ASA, org. nr. 966 011 726, a public limited liability company registered in Norway (“Nordic Semiconductor”). ‍

Nordic Developer Academy allows the user to take technical courses related to Nordic Semiconductor products, software and services, and obtain a certificate certifying completion of these courses. By completing the registration process for the Nordic Developer Academy, you are agreeing to be bound by these Terms of Use.

These Terms of Use are applicable as long as you have a user account giving you access to Nordic Developer Academy.‍

‍2. Access to and use of Nordic Developer Academy

‍‍Upon acceptance of these Terms of Use you are granted a non-exclusive right of access to, and use of Nordic Developer Academy, as it is provided to you at any time. Nordic Semiconductor provides Nordic Developer Academy to you free of charge, subject to the provisions of these Terms of Use and the Nordic Developer Academy Privacy Policy.

To access select features of Nordic Developer Academy, you need to create a user account. You are solely responsible for the security associated with your user account, including always keeping your login details safe.

You will able to receive an electronic certificate from Nordic Developer Academy upon completion of courses. By issuing you such a certificate, Nordic Semiconductor certifies that you have completed the applicable course, but does not provide any further warrants or endorsements for any particular skills or professional qualifications.

Nordic Semiconductor will continuously develop Nordic Developer Academy with new features and functionality, but reserves the right to remove or alter any existing functions without notice.

‍3. Acceptable use

You undertake that you will use Nordic Developer Academy in accordance with applicable law and regulations, and in accordance with these Terms of Use.‍ You must not modify, adapt, or hack Nordic Developer Academy or modify another website so as to falsely imply that it is associated with Nordic Developer Academy, Nordic Semiconductor, or any other Nordic Semiconductor product, software or service.

You agree not to reproduce, duplicate, copy, sell, resell or in any other way exploit any portion of Nordic Developer Academy, use of Nordic Developer Academy, or access to Nordic Developer Academy without the express written permission by Nordic Semiconductor. You must not upload, post, host, or transmit unsolicited email, SMS, or \”spam\” messages.

You are responsible for ensuring that the information you post and the content you share does not;

  • contain false, misleading or otherwise erroneous information
  • infringe someone else’s copyrights or other intellectual property rights
  • contain sensitive personal data or
  • contain information that might be received as offensive or insulting.
  • Such information may be removed without prior notice.

‍Nordic Semiconductor reserves the right to at any time determine whether a use of Nordic Developer Academy is in violation of its requirements for acceptable use.

Violation of the at any time applicable requirements for acceptable use may result in termination of your account. We will take reasonable steps to notify you and state the reason for termination in such cases.

‍4. Routines for planned maintenance

‍Certain types of maintenance may imply a stop or reduction in availability of Nordic Developer Academy. Nordic Semiconductor does not warrant any level of service availability but will provide its best effort to limit the impact of any planned maintenance on the availability of Nordic Developer Academy.

5. Intellectual property rights

‍Nordic Semiconductor retains all rights to all elements of Nordic Developer Academy. This includes, but is not limited to, the concept, design, trademarks, know-how, trade secrets, copyrights and all other intellectual property rights.

Nordic Semiconductor receives all rights to all content uploaded or created in Nordic Developer Academy. You do not receive any license or usage rights to Nordic Developer Academy beyond what is explicitly stated in this Agreement.

‍6. Liability and damages

‍Nothing within these Terms of Use is intended to limit your statutory data privacy rights as a data subject, as described in the Nordic Developer Academy Privacy Policy. ‍You acknowledge that errors might occur from time to time and waive any right to claim for compensation as a result of errors in Nordic Developer Academy. When an error occurs, you shall notify Nordic Semiconductor of the error and provide a description of the error situation.

You agree to indemnify Nordic Semiconductor for any loss, including indirect loss, arising out of or in connection with your use of Nordic Developer Academy or violations of these Terms of Use. ‍Nordic Semiconductor shall not be held liable for, and does not warrant that (i) Nordic Developer Academy will meet your specific requirements, (ii) Nordic Developer Academy will be uninterrupted, timely, secure, or error-free, (iii) the results that may be obtained from the use of Nordic Developer Academy will be accurate or reliable, (iv) the quality of any products, services, information, or other material purchased or obtained by you through Nordic Developer Academy will meet your expectations, or that (v) any errors in Nordic Developer Academy will be corrected.

You accept that this is a service provided to you without any payment and hence you accept that Nordic Semiconductor will not be held responsible, or liable, for any breaches of these Terms of Use or any loss connected to your use of Nordic Developer Academy. Unless otherwise follows from mandatory law, Nordic Semiconductor will not accept any such responsibility or liability.

‍7. Change of terms

‍Nordic Semiconductor may update and change the Terms of Use from time to time. Nordic Semiconductor will seek to notify you about significant changes before such changes come into force and give you a possibility to evaluate the effects of proposed changes. Continued use of Nordic Developer Academy after any such changes shall constitute your acceptance of such changes. You can review the current version of the Terms of Use at any time at https://academy.nordicsemi.com/terms-of-service/

‍8. Transfer of rights

‍Nordic Semiconductor is entitled to transfer its rights and obligation pursuant to these Terms of Use to a third party as part of a merger or acquisition process, or as a result of other organizational changes.

‍9. Third Party Services

‍‍To the extent Nordic Developer Academy facilitates access to services provided by a third party, you agree to comply with the terms governing such third party services. Nordic Semiconductor shall not be held liable for any errors, omissions, inaccuracies, etc. related to such third party services.

‍10. Dispute resolution

‍‍The Terms of Use and any other legally binding agreement between yourself and Nordic Semiconductor shall be subject to Norwegian law and Norwegian courts’ exclusive jurisdiction.

 

Switch language?

Progress is tracked separately for each language. Switching will continue from your progress in that language or start fresh if you haven't begun.

Your current progress is saved, and you can switch back anytime.

Log in
Don’t have an account? Register an account

Forgot your password?
Register an account
Already have an account? Log in
(All fields are required unless specified optional)

  • 8 or more characters
  • Upper and lower case letters
  • At least one number or special character

Forgot your password?
Enter the email associated with your account, and we will send you a link to reset your password.

Back to Log in

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.

      Change summary

      What's new in the latest version

      General updates

      General updates

      •Support for nRF54LS05 DK (Available through the early access sampling program)
      •Support for the nRF54LM20B with Axon NPU for Edge AI applications
      Bluetooth LE updates

      Bluetooth LE updates

      •Quality of Service module is now production-ready.
      •New experimental features for RF testing (Direct Test Mode) and low-latency packet handling (LE Flushable ACL).
      MCUboot & Partition Manager

      MCUboot & Partition Manager

      •Single-Slot DFU and RAM Load mode are both promoted to fully supported
      •Partition Manager is officially deprecated in favor of Zephyr's devicetree-based partitioning.