GitHub SDK
The 24.12.00 GitHub SDK release offers customers the power to use Git as a source control management solution. You'll be able to work in large teams on a common shared code base. Changes from NXP are reflected in Git status notifications. NXP also uses the West meta tool to share a recipe for what Git repositories are included in official SDK releases. This also started the introduction of customer access to SDK “previews”. Two previews are published to GitHub for customers to evaluate in the months prior to each quarterly release. Customers are now able to test if patches resolve a product requirement. The preview also provides early progress in code development on new features due for the next quarterly release.
Archive SDK
For those who use the MCUXpresso SDK dashboard to build your archive/zip SDK package, the build and import flow remains the same. PDF files are no longer integrated to the zipped folder, but can be found in the SDK Documentation website.
Using SDK Release 24.12.00 onwards
This guide will focus on those who would like to migrate to the new SDK, but still prefer to use the "archive" SDK. The zipped folder which can be used across different toolchains such as MCUXpresso IDE, IAR, KEIL and VS Code.
In addition we'll go over what differences you can expect with the new SDK and how to port an existing project from an SDK older than 24.12.00.
Installing the SDK
The MCUXpresso SDK is complimentary and includes full source code under a permissive open-source license for all hardware abstraction and peripheral driver software. The Archive SDK can be installed using the MCUXpresso SDK Dashboard. Select the device and toolchain of preference you are working with. Download the zipped archive to continue. In this guide we'll focus on MCUXpresso IDE with the FRDM-MCXN236.
1. Choose your Operating System
2. Choose the toolchain
3. It is recommended to choose all of the middleware offered
4. Build SDK
Next your dashboard will appear with the Download option. Press Download, then click Download SDK Archive. Then agree to terms and conditions to download the zipped folder.
This folder can be dragged and dropped to your MCUXpresso IDE "Installed SDKs" window.
Existing application in workspace
Let's say you only want to update the SDK and you have a working application in your workspace. For example, here I have an example which is associated to an older SDK version.
Updating the associated SDK should be automatic. It may take some time after updating the SDK for it to take effect. In addition you can restart the IDE. Once ready, viewing the version it is now seen as the latest SDK I loaded.
Build and debug your application as normal if no changes are required.
Note: Updating the associated SDK does not mean that the files within your application will be changed automatically, this can be done manually by looking at the different sources you need in your application. You can also refresh the SDK components to update all the files withing your project (however not recommended as this will most likely cause conflicts, depending on the complexity of project). Adding drives using the SDK management tool, will inevitably grab the drivers from the latest SDK and prompt you to update other files that may have dependencies.
Importing application to workspace
Another scenario you may encounter, is if you already have an existing application from an older SDK but would like to import it to your current workspace with the updated SDK.
1. Go to QuickStart Panel and select Import project(s) from file system.
2. Browse your PC, for the zipped or unzipped application.
3. Click finish once your project has been selected.
Finally a warning will appear notifying that the SDK versions do not match and ask if you would like to make the new SDK persistent or not for this project. If the intention is to update to the new SDK and port over changes, then click OK. If not, then uncheck the option and continue.
Build and debug your application as normal.
Note: Updating the associated SDK does not mean that the files within your application will be changed automatically, this can be done manually by looking at the different sources you need in your application. You can also refresh the SDK components to update all the files withing your project (however not recommended as this will most likely cause conflicts, depending on the complexity of project). Adding drives using the SDK management tool, will inevitably grab the drivers from the latest SDK and prompt you to update other files that may have dependencies.
Porting Project to New SDK
The following recommendations are to provide a path to quickly resolve any conflicting issues that may arise when porting a project based on an older SDK when moving to the new SDK. When copying sources from one to another it is possible that some dependencies in drivers and middleware may cause conflict and compiling errors. As all projects are different and have a varying degree of complexity the following guidelines are flexible and can be used or disregarded accordingly.
Lets take an example OTA_ROM_SERVER example from SDK 2.16.100 and port it to SDK 25.03.00 using the archive SDK in MCUXpresso IDE. For simplicity I'll refer to the projects as "old" and "new'.
- If the old project is not already in the workspace import it. See above.
- If the new SDK package has not been imported to the workspace, do so now. See above.
- Import a project as closely related to your old project.
- In this example, I will import the same project under the new SDK. Refer to the "Explore Project Files" to view main differences between the old and new
- An alternative is to create a blank project and import the drivers and middleware you need using SDK Management tool.
- Generally, the 'Source' and 'Board' folder will contain all customized files. It is possible that you may have other folders which contain custom folder. Keep this in mind for the following suggestions.
What changes are needed?
Think about why you need to update your application to the new SDK. Is there an update in a driver you are interested in? Or new middleware component available?
- Review the changelog of the new SDK. SDK Changelog Example for FRDM-MCXN947
- Consider only the changed drivers you are using in your application.
- You can copy the drivers directly and replace them in your application.
- Resolve any conflicts.
Adding new drivers or middleware.
- Use the "Use the SDK Management" tool to add a new driver or component needed.
- Right-click your project. Select 'SDK Management', then 'Manage SDK Components'
- Browse the drivers you need
- Press Ok
- This will open a window that lists any new drivers to the project or updates.
- Press Yes
- If there is any existing file in your project that is marked to be updated. You will get a prompt that gives you the choice to replace, keep existing or check the difference. If in doubt keep existing(you can always go back and update later).
Updating the entire project
Another scenario may be that you would like to update to the new SDK regardless if you need the changes or not. Keep in mind that moving from SDK 24.12.00 to 25.03.00 will most likely have minor changes, as opposed to moving from 2.16.100 to 24.12.00 onwards. Since the new SDK was introduced in 24.12.00, major structural changes were introduced, therefore it will require a bit more effort to change your application to the new SDK.
Starting from a similar project
The main benefit of starting from a similar project, is that most of the middleware, components and drivers will already be integrated. Meaning that your main focus will be on custom board files and application specific sources.
In addition there may be preprocessor definitions or paths that if not known may make things much smoother when transitioning to the new SDK.
Starting from a blank project
On the other hand, it is also possible to start from a blank project. Use the SDK management tool to import only the necessary middleware, components or drivers you need.
This option gives you a blank canvas, but may be considered a bit more challenging as you need to add any preprocessor definitions or changes in the project settings that may be overlooked when starting with a similar project.
In this guide, we'll go over the first option, as I consider this the path of least resistance in terms of the amount of conflicts you will have to navigate through when building the new project.
Steps taken:
- Imported ota_rom_server example from SDK 25.03.00.
- Reviewed files in my source folder. I am interested in keeping my source folder as is and would not like to change my main application files. However, the only header files I will keep are the FreeRTOS related files. The reason for this is because the FreeRTOS middleware component may have many changes between these two versions and its possible that many conflicts will arise if I keep the existing version.
- I delete all other files and copy all but the FreeRTOSConfig.h.
- Next I review the Board folder as this will have custom board files. I know that the app.h and the hardware_init.c have a Board_InitHardware() function that does exactly what is in my main
- I know that the app.h and the hardware_init.c have a Board_HardwareInit() function that does exactly what is in my main. You can choose to replace the content in your main with Board_InitHardware or get rid of the files.
- I chose removing the files.
- Finally there is an additional folder in my old project which contains custom board files that contain information about the flash partitioning. That is used in the application source files. I copy the entire folder and paste it to the project.
- The folder will appear with out the blue icon, meaning that it is not yet included in paths the compiler will know where to look.
- Right-click the project and go to the properties. There are three locations that the folder and sub-folders need to be included.
- First under Settings -> Includes
- Next under Path and Symbols, in Includes and Source Location
- Now the folder will be ready.
- Build the project. At this point no conflicts should be present.
Note: If you need to add a driver or different middleware component. See above section under 'What changes are needed?'
Exploring the project files
Let's look at the differences between an example from SDK 2.16.100 and SDK 25.03.00. In this project we are not looking at the content changes with individual drivers. That can be viewed in the changelog available in the SDK Documentation per SDK version.
The changes seen below are structure changes in the project and/or files that have been added or deleted.
CMSIS:
 |
Board:
 |
Boot Util Port:
 |
Device:
 |
Drivers:
 |
Flash:
 |
Source:
 |
Utilities:
 |
Troubleshooting
Conflict inside a new middleware component
If you find that there is a conflict inside the middleware you just added or updated. It is not recommended to try and resolve conflicts my mix and matching files from old SDK with the new SDK, this may take you in an endless path often going in circles.
Instead check the following against your original application:
- Preprocessor Definitions
- Path references in your source files
- Missing macros in your source files
- Optimization levels
- Missing libraries
- Refresh SDK Component (see next bullet point)
Refresh SDK Component
Refreshing the SDK Component can be done with the SDK Management tool.
Use this tool cautiously, it is a great tool as it will update all of the components and resolve most conflicts within the new drivers and middleware. However it is also possible that it will bring up many conflicts to your application as well as ask you to keep or replace many drivers which can become an overwhelming task.
I recommend to keep this as a last resort tool and if you have exhausted all other options.
