With this in mind, in this exercise we will learn how to update the firmware of an nRF9160 DK or nRF91x1 DK over a cellular connection (LTE-M or NB-IoT). MCUboot and the swapping of firmware is the same here as we learned in the theory part of this section, so all we need to do is move the new firmware to the mcuboot_secondary slot in the flash memory of the nRF91 Series.
We will split the “travel” of the firmware package into two steps:
Download firmware into the mcuboot_secondary slot
Hosting the firmware in the cloud
Download firmware into the mcuboot_secondary slot
The nRF Connect SDK FOTA Download library is used to download firmware from a URL. If this update is an MCUboot update, it will automatically be downloaded into the mcuboot_secondary slot. After the download is complete, it is automatically tagged as “test” by the library.
The FOTA Download library may be called directly from our application. However, several of the cloud libraries in the nRF Connect SDK has FOTA support built-in where FOTA Download is called automatically from the cloud library. See specific documentation for each cloud library for how they handle FOTA.
Hosting the firmware in the cloud
To download the firmware to the device, we must have uploaded the firmware somewhere. As with the previous exercises, we will use build/l9_e6/zephyr/l9_e6.signed.bin as our new firmware image. The FOTA Download library does not really care where this file is, as long as it has an URL and a filename. Because of this, it is possible to upload l9_e6.signed.bin to a public page and download it directly from this page, as done by our HTTP Update sample.
However, this solution does not scale very well. With multiple different devices connected to the internet, we want a way to get an overview over our devices and a way to push updates to subsets of the devices. The different cloud providers have FOTA solutions which give us such functionality. Because of this, we will learn how to use the Device Management in nRF Cloud to host our FOTA firmware updates in this exercise. Other cloud providers will have similar functionality.
Exercise steps
Open the code base of the exercise by navigating to Create a new application in the nRF Connect for VS Code extension, select Copy a sample, and search for Lesson 9 – Exercise 6.
This exercise contains a slimmed-down version of the cloud connection part of our Cellular: nRF Cloud multi-service sample. The provided code contains the source code needed to connect to nRF Cloud with MQTT using the nRF Cloud library. The application does not need any source code to receive updates via nRF Clouds. Instead, when we enable CONFIG_NRF_CLOUD_FOTA in the application, the library will automatically receive FOTA for us.
Disclaimer: If you want to base your own code on this exercise, we recommend comparing the exercise sample on our Cellular: nRF Cloud multi-service sample to learn the differences between them. The nRF Cloud multi-service sample also has overlays for other settings, such as using external flash or CoAP. So remember this sample if you later want some different settings for your FOTA.
1. Build the application and flash it to your board.
Build the sample for nrf9160dk_nrf9160_ns, nrf9161dk_nrf9161_ns or nrf9151dk_nrf9151_ns and flash it to the board. Observe that the sample successfully connects to nRF Cloud from the logs.
5.1 First, we will have to add the nRF91 Series device to a group in the nRF Cloud. Since the device has already been provisioned to nRF Cloud, we should see it in the Devices tab:
5.2 Next up, we will add a new firmware bundle containing the firmware we will upload. Go to Device Management → Firmware Updates and select the “Add Bundle” button under Bundles:
In the following Create Update Bundle window, upload build/dfu_application.zip. This file is an automatically created zip containing DFU files such as l9_e6.signed.bin. nRF Cloud will have logic unzip dfu_application.zip, read the manifest and then FOTA the correct files to the nRF91.
Then fill out the rest of the fields. We can choose what we want for the name and version, but it is a good idea to make something that makes sense and that we can increment later.
5.3 We will now create an update. For this, we use the “Create FOTA Update” button at the top of the Firmware Updates page:
In the Create Update window, we fill in a name and description for the update. Then we choose the bundle that we just created and finally choose our DK:
Leave “Deploy now” unchecked and press “Create Update”.
5.4 Connect the nRF Terminal to the nRF91 device so we can watch the logs when the update starts.
5.5 After step 5.3, we get to a page for the Update:
Next up, we can deploy the update by pressing the “large “Deploy Update” button. Then we wait a little, and we should be able to see all device queued for the update:
When the update has been deployed, nRF Cloud will publish an MQTT message to the device to tell it to start the download. Then all we have to do is wait, and the update should happen automatically. You can see that the update happens both in the status bar at nRF Cloud and in the logs from the nRF91 device.
5.6 When the update is finished, we can see the following logs:
As we can see, we must restart the device to apply the update. Reset the nRF91 Series DK and observe the swap. The nRF Cloud library will then see that it has a pending update again, but when it realizes that its update is already completed, it will confirm the update so as not to swap back on its next reboot.
With this, we have successfully updated the nRF91 Series DK application with FOTA. We can confirm that by selecting our device in “Device Management -> Devices” page.
6. Get notifications from the FOTA update.
We want to get notifications from the FOTA update, and we can handle these in src/cloud_connection.c and the function cloud_event_handler().
6.1 To show what can be implemented, we can set the device to automatically restart after FOTA.
6.1.1 Add the following line in cloud_connection.c
Copy
#include<zephyr/sys/reboot.h>
C
6.1.2 Add the following line in cloud_connection.c
Copy
sys_reboot(SYS_REBOOT_COLD);
C
Add sys_reboot() inside the NRF_CLOUD_EVT_FOTA_DONE case.
6.2 Follow steps 4 and 5 again to test this, and observe that the device will now automatically reboot after the FOTA update.
7. Update the modem firmware over FOTA.
It is also possible to update the modem firmware using this exercise. This is possible for modem delta updates without external flash. For full modem updates, external flash must be added. See the source code for the nRF Cloud multi service sample if you need to enable full modem updates.
7.1 First, we check the current modem firmware version. To do this in nRF Cloud, we select the device from the Devices menu:
Then we can find the modem version information under Device Info:
7.2 If the device needs updating, add a modem firmware update and deploy it, as we did in step 5.3.
This time, we won’t upload the dfu file. Please choose the MFW delta update file that fits your current modem firmware version and the target version you want to upgrade to.
7.3 As with the application update, an MQTT message should be received by the nRF91 Series device, automatically starting the modem delta update.
The solution for this exercise can be found in the GitHub repository l9/l9_e6_sol.
With this in mind, in this exercise we will learn how to update the firmware of an nRF9160 DK or nRF91x1 DK over a cellular connection (LTE-M or NB-IoT). MCUboot and the swapping of firmware is the same here as we learned in the theory part of this section, so all we need to do is move the new firmware to the mcuboot_secondary slot in the flash memory of the nRF91 Series.
We will split the “travel” of the firmware package into two steps:
Download firmware into the mcuboot_secondary slot
Hosting the firmware in the cloud
Download firmware into the mcuboot_secondary slot
The nRF Connect SDK FOTA Download library is used to download firmware from a URL. If this update is an MCUboot update, it will automatically be downloaded into the mcuboot_secondary slot. After the download is complete, it is automatically tagged as “test” by the library.
The FOTA Download library may be called directly from our application. However, several of the cloud libraries in the nRF Connect SDK has FOTA support built-in where FOTA Download is called automatically from the cloud library. See specific documentation for each cloud library for how they handle FOTA.
Hosting the firmware in the cloud
To download the firmware to the device, we must have uploaded the firmware somewhere. As with the previous exercises, we will use build/l9_e6/zephyr/l9_e6.signed.bin as our new firmware image. The FOTA Download library does not really care where this file is, as long as it has an URL and a filename. Because of this, it is possible to upload l9_e6.signed.bin to a public page and download it directly from this page, as done by our HTTP Update sample.
However, this solution does not scale very well. With multiple different devices connected to the internet, we want a way to get an overview over our devices and a way to push updates to subsets of the devices. The different cloud providers have FOTA solutions which give us such functionality. Because of this, we will learn how to use the Device Management in nRF Cloud to host our FOTA firmware updates in this exercise. Other cloud providers will have similar functionality.
Exercise steps
Open the code base of the exercise by navigating to Create a new application in the nRF Connect for VS Code extension, select Copy a sample, and search for Lesson 9 – Exercise 6.
This exercise contains a slimmed-down version of the cloud connection part of our Cellular: nRF Cloud multi-service sample. The provided code contains the source code needed to connect to nRF Cloud with MQTT using the nRF Cloud library. The application does not need any source code to receive updates via nRF Clouds. Instead, when we enable CONFIG_NRF_CLOUD_FOTA in the application, the library will automatically receive FOTA for us.
Disclaimer: If you want to base your own code on this exercise, we recommend comparing the exercise sample on our Cellular: nRF Cloud multi-service sample to learn the differences between them. The nRF Cloud multi-service sample also has overlays for other settings, such as using external flash or CoAP. So remember this sample if you later want some different settings for your FOTA.
1. Build the application and flash it to your board.
Build the sample for nrf9160dk_nrf9160_ns, nrf9161dk_nrf9161_ns or nrf9151dk_nrf9151_ns and flash it to the board. Observe that the sample successfully connects to nRF Cloud from the logs.
5.1 First, we will have to add the nRF91 Series device to a group in the nRF Cloud. Since the device has already been provisioned to nRF Cloud, we should see it in the Devices tab:
5.2 Next up, we will add a new firmware bundle containing the firmware we will upload. Go to Device Management → Firmware Updates and select the “Add Bundle” button under Bundles:
In the following Create Update Bundle window, upload build/dfu_application.zip. This file is an automatically created zip containing DFU files such as l9_e6.signed.bin. nRF Cloud will have logic unzip dfu_application.zip, read the manifest and then FOTA the correct files to the nRF91.
Then fill out the rest of the fields. We can choose what we want for the name and version, but it is a good idea to make something that makes sense and that we can increment later.
5.3 We will now create an update. For this, we use the “Create FOTA Update” button at the top of the Firmware Updates page:
In the Create Update window, we fill in a name and description for the update. Then we choose the bundle that we just created and finally choose our DK:
Leave “Deploy now” unchecked and press “Create Update”.
5.4 Connect the nRF Terminal to the nRF91 device so we can watch the logs when the update starts.
5.5 After step 5.3, we get to a page for the Update:
Next up, we can deploy the update by pressing the “large “Deploy Update” button. Then we wait a little, and we should be able to see all device queued for the update:
When the update has been deployed, nRF Cloud will publish an MQTT message to the device to tell it to start the download. Then all we have to do is wait, and the update should happen automatically. You can see that the update happens both in the status bar at nRF Cloud and in the logs from the nRF91 device.
5.6 When the update is finished, we can see the following logs:
As we can see, we must restart the device to apply the update. Reset the nRF91 Series DK and observe the swap. The nRF Cloud library will then see that it has a pending update again, but when it realizes that its update is already completed, it will confirm the update so as not to swap back on its next reboot.
With this, we have successfully updated the nRF91 Series DK application with FOTA. We can confirm that by selecting our device in “Device Management -> Devices” page.
6. Get notifications from the FOTA update.
We want to get notifications from the FOTA update, and we can handle these in src/cloud_connection.c and the function cloud_event_handler().
6.1 To show what can be implemented, we can set the device to automatically restart after FOTA.
6.1.1 Add the following line in cloud_connection.c
Copy
#include<zephyr/sys/reboot.h>
C
6.1.2 Add the following line in cloud_connection.c
Copy
sys_reboot(SYS_REBOOT_COLD);
C
Add sys_reboot() inside the NRF_CLOUD_EVT_FOTA_DONE case.
6.2 Follow steps 4 and 5 again to test this, and observe that the device will now automatically reboot after the FOTA update.
7. Update the modem firmware over FOTA.
It is also possible to update the modem firmware using this exercise. This is possible for modem delta updates without external flash. For full modem updates, external flash must be added. See the source code for the nRF Cloud multi service sample if you need to enable full modem updates.
7.1 First, we check the current modem firmware version. To do this in nRF Cloud, we select the device from the Devices menu:
Then we can find the modem version information under Device Info:
7.2 If the device needs updating, add a modem firmware update and deploy it, as we did in step 5.3.
This time, we won’t upload the dfu file. Please choose the MFW delta update file that fits your current modem firmware version and the target version you want to upgrade to.
7.3 As with the application update, an MQTT message should be received by the nRF91 Series device, automatically starting the modem delta update.
The solution for this exercise can be found in the GitHub repository l9/l9_e6_sol.
v3.0.0
There are multiple ways to create applications for the nRF91 Series. Two of the main choices a developer must make are:
Which cloud provider to use, for example, nRF Cloud, AWS, or Azure.
Which communication protocol to use, for example, MQTT, CoAP, or HTTP.
With this in mind, in this exercise we will learn how to update the firmware of an nRF9160 DK or nRF91x1 DK over a cellular connection (LTE-M or NB-IoT). MCUboot and the swapping of firmware is the same here as we learned in the theory part of this section, so all we need to do is move the new firmware to the mcuboot_secondary slot in the flash memory of the nRF91 Series.
We will split the “travel” of the firmware package into two steps:
Download firmware into the mcuboot_secondary slot
Hosting the firmware in the cloud
Download firmware into the mcuboot_secondary slot
The nRF Connect SDK FOTA Download library is used to download firmware from a URL. If this update is an MCUboot update, it will automatically be downloaded into the mcuboot_secondary slot. After the download is complete, it is automatically tagged as “test” by the library.
The FOTA Download library may be called directly from our application. However, several of the cloud libraries in the nRF Connect SDK has FOTA support built-in where FOTA Download is called automatically from the cloud library. See specific documentation for each cloud library for how they handle FOTA.
Hosting the firmware in the cloud
To download the firmware to the device, we must have uploaded the firmware somewhere. As with the previous exercises, we will use build/zephyr/app_update.bin as our new firmware image. The FOTA Download library does not really care where this file is, as long as it has an URL and a filename. Because of this, it is possible to upload app_update.bin to a public page and download it directly from this page, as done by our HTTP Update sample.
However, this solution does not scale very well. With multiple different devices connected to the internet, we want a way to get an overview over our devices and a way to push updates to subsets of the devices. The different cloud providers have FOTA solutions which give us such functionality. Because of this, we will learn how to use the Device Management in NRF Cloud to host our FOTA firmware updates in this exercise. Other cloud providers will have similar functionality.
Exercise steps
Open the code base of the exercise by navigating to Create a new application in the nRF Connect for VS Code extension, select Copy a sample, and search for Lesson 8 – Exercise 4.
Alternatively, in the GitHub repository for this course, go to the base code for this exercise, found in l8/l8_e4 or l8/v2.5.x/l8_e4.
Note
There exists two code bases for this exercise.
nRF Connect SDK v2.6.x: l8/l8_e4.
nRF Connect SDK v2.5.x: l8/v2.5.x/l8_e4.
This exercise contains a slimmed-down version of the cloud connection part of our Cellular: nRF Cloud multi-service sample. The provided code contains the source code needed to connect to nRF Cloud with MQTT using the nRF Cloud library. The application does not need any source code to receive updates via nRF Clouds. Instead, when we enable CONFIG_NRF_CLOUD_FOTA in the application, the library will automatically receive FOTA for us.
Disclaimer: If you want to base your own code on this exercise, we recommend comparing the exercise sample on our Cellular: nRF Cloud multi-service sample to learn the differences between them.
1. Build the application and flash it to your board.
Build the sample for nrf9160dk_nrf9160_ns, nrf9161dk_nrf9161_ns or nrf9151dk_nrf9151_ns and flash it to the board. Observe that the sample successfully connects to nRF Cloud from the logs.
Change something in the application, so we can confirm that the firmware has been updated, for example, add a print statement. Build the application again, but do not flash it to the DK.
5.1 First, we will have to add the nRF91 Series device to a group in nRF Cloud. Since the device has already been provisioned to nRF Cloud, we should see it in the Devices tab:
From here, click “Manage Group” and type in the name of a device group to create a new group. Then click “Save”.
5.2 Next up, we will add a new firmware bundle, with the firmware we will upload. Go to Device Management → Firmware Updates and select the “+” symbol under Bundles:
In the following Create Update Bundle window, upload build/zephyr/app_update.bin or build/zephyr/dfu_application.zip. Then fill out the rest of the fields. We can choose what we want for the name and version, but it is a good idea to make something that makes sense, and that we can increment later.
5.3 We will now create an update. For this we use the “Create Update” button at the top of the Firmware Updates page:
In the Create Update window, we fill in a name and description for the update. Then we choose the bundle that we just created and finally choose the group which we have our DK in:
Leave “Deploy now” unchecked and press “Create Update”.
5.4 Connect the nRF Terminal to the nRF91 device so we can watch the logs when the update starts.
5.5 After step 5.3, we get to a page for the Update:
Next up, we can deploy the update by pressing the large green button. Then we wait a little, and we should be able to see all devices in the group being queued for the update:
When the update has been deployed, nRF Cloud will publish an MQTT message to the device to tell it to start the download. Then all we have to do is wait, and the update should happen automatically. You can see that the update happens both in the status bar at nRF Cloud and in the logs from the nRF91 device.
5.6 When the update is finished, we can see the following logs:
As we can see, we must restart the device to apply the update. Reset the nRF91 Series DK and observe the swap. The nRF Cloud library will then see that it has a pending update again, but when it realizes that its update is already completed, it will confirm the update, as to not swap back on its next reboot.
With this, we have successfully updated the nRF91 Series DK application with FOTA.
6. Get notifications from the FOTA update.
We want to get notifications from the FOTA update, and we can handle these in src/cloud_connection.c and the function cloud_event_handler().
6.1 To show what can be implemented, we can set the device to automatically restart after FOTA.
6.1.1 Add the following line in cloud_connection.c
Copy
#include<zephyr/sys/reboot.h>
C
6.1.2 Add the following line in cloud_connection.c
Copy
sys_reboot(SYS_REBOOT_COLD);
C
Add sys_reboot() inside the NRF_CLOUD_EVT_FOTA_DONE case.
6.2 Follow steps 4 and 5 again to test this, and observe that the device will now automatically reboot after the FOTA update.
7. Update the modem firmware over FOTA:
It is also possible to update the modem firmware using this exercise. This is possible for modem delta updates without external flash. For full modem updates, external flash must be added. See the source code for the nRF Cloud multi service sample if you need to enable full modem updates.
7.1 First, we check the current modem firmware version. To do this in nRF Cloud, we select the device from the Devices menu:
Then we can find the modem version information under Device Info:
7.2 If the device needs updating, add a modem firmware update and deploy it, as we did in step 5.
7.3 As with the application update, an MQTT message should be received by the nRF91 Series device, automatically starting the modem delta update.
The solution for this exercise can be found in the GitHub repository, l8/l8_e4_sol or l8/v2.5.x/l8_e4_sol.
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.
