How are SDK's Developed/Updated?

cancel
Showing results for 
Search instead for 
Did you mean: 

How are SDK's Developed/Updated?

Jump to solution
241 Views
mykepredkomimet
Senior Contributor II

This is a question for the NXP MCUXpresso SDK team.  

I'm working with the MK20/MK22 and I see a wide variety of different levels to the SDKs with different include folders, options and even a different name for the (Amazon) FreeRTOS.  

With the only consistency is that Freedom (and, I presume, Tower) boards having the latest version of the SDK.  When I look at the MK20, I have SDK version 2.2 but when I look at the MK22 there is 2.2 for the MK22FN512xxx10, 2.3.1 for the MK22FN1M0Axxx12 and 2.7.0 for the MK22FN512xxx10 (the MKFN512xxx10 being used in the Freedom board).  This is problematic because it is a lot of work transferring demo apps from the Freedom boardsa to the processor I actually want to use (the MK22FN1M0Axxx12).  

What is the process for updating the SDKs for specific processors to match that of the Freedom and Tower boards and is this something that a user, like myself can do?

Thanx,

myke

Labels (1)
0 Kudos
1 Solution
64 Views
mykepredkomimet
Senior Contributor II

I think I have the answers to how the process and how it works.  

I successfully got my test board to run a USB CDC Device application (instructions here: Create K20 USB CDC Device).  

The problems I had was really one in terms of expectations - if I see that there is an SDK version 2.7.0 (the latest) for some parts that seem similar to what I want to use, I expect a) that the same/latest SDK version will be available for the part I want to use and b) the code in the SDK the part that I want to use is available for all options on the device.  

My recommendation is that when you are about to develop code for a part and want to get example code, find a Freedom/Tower board that has the same SDK as the part that you want to use/not a Freedom/Tower board that has the latest version.  This is true even if the part that provides the latest SDK seems to be a closer match to the one that you want to use instead of other Freedom/Tower boards.  Along with this, expect that you will have to copy code in manually from the example if it's not available natively from the SDK's project builder.  

This question will be marked "Solved".  

View solution in original post

0 Kudos
3 Replies
64 Views
Sabina_Bruce
NXP Employee
NXP Employee

Hello Myke,

The main objective of the SDK updates is to provide more support for the microcontrollers.There are differences between the microcontrollers that you mention above, mainly the memory capacity and I/O pins, so it is really important to know which one is the one you are working with. Generally, the decisions to update (or not update) the SDK is based on the demand for a particular microcontroller.  In addition the newer SDKs will be compatible with the new/updated versions of our supported IDEs. This is a collaborative effort from all parties involved and there is not a straight procedure in how or when these get updated. 

We always recommend to use the latest SDK and IDE version and to make esier to work with your own board, you can download the standalone SDKs that are not attached to one of our development boards.

Best Regards,

Sabina

0 Kudos
64 Views
mykepredkomimet
Senior Contributor II

Hi Sabina,

Thank you for taking the time to reply.  

I appreciate what you're trying to do and I must say that I'm impressed with what has been done with MCUXpresso IDE and the SDKs, but I'm really having trouble porting examle apps from the FRDM/TWRK SDKs (which are at the latest level) and the actual part SDKs (which are generally downlevel).  If the example projects aren't easily ported to what should be virtually identical devices (same family although different revision level as you will see below).  

I just spent the day trying to port the frdmk22f_dev_cdc_vcom_freertos and the frdm64k_dev_cdc_vcom_freertos (I did the second one because the K64 hardware seems to be closer to my target device, the MK22FN1M0AVLL12) but in both cases, while I got the ported projects to build without any warnings or errors but I ended uo with the following message when I tried to connect the board to a Windows 10 PC:

2020.01.30 - Windows 10 USB Error Message.jpg

I should point out that the ...dev_cdc_vcom_freertos code works fine on the two Freedom boards (I have one of each, so I can test the code).  The SDKs are 2.7.0 for the two Freedom boards, but the MK22 part that I am using has an SDK of 2.3.1 and many of the SDK "Components" (namely "Utilities", "Middleware", "Board Components" & "Software Components") that are available for SDK 2.7.0 are not available for the MK22 part SDK.  The porting process that I'm going through is listed below.  I should also point out that SDK 2.7.0 provides "Amazon FreeRTOS" while in SDK it is just "FreeRTOS" - I don't think this is an issue, but it could be.  

I'm not really sure where to look for the problem and the two places I'm going to focus on initially are:

1) the "A" part which isn't in the two Freedom boards.  Are there any hardware differences that I need to be aware of.  

2) what are all the options for the builds.  I thought I got the project "Properties" right, but maybe I'm missing something

3) the basic libraries provided for the parts in the SDK to see if there are any differences

4) ???  

If you have any suggestions as to how to get the code working (the USB CDC device properly enumerating with the Windows 10 machine) I'd really appreciate them.  

Thanx again for commenting,

myke

1. Create basic project. Create with:
- MK22FN1M0AVLL10
- FreeRTOS
Drivers:
- clock
- common
- uart
Utilities:
- assert
- debug_console

2. Setup clocks and USB IO Pins.

- Just USB IO Pins

- Setup 8MHz clock (like the FRDM_K22F board)

- Run as a PEE device

- Set the PLL to " / 2 * 30 " to get 120MHz

3. Build and test.

4. Create "source folders" for:
- components
- usb

5. Copy from the srouce project the contents of the "components" and "usb" folders

6. Attempt to build project
Files to copy in:
- "source/usb_device_config.h"
Folders to add to Properties "includes":
- "usb/include"
- "usb/device/include"
- "usb/device/class/cdc"
- "usb/device/source"
- "usb/device/source/khci"
- "component/lists"
- "component/osa"
- "component/uart"
Options to add to Properties "PreProcessor":
- FSL_OSA_BM_TASK_ENABLE=0
- FSL_OSA_BM_TIMER_CONFIG=0
- SERIAL_PORT_TYPE_UART=1
Copy from source project "drivers/fsl_common.h" and, aftger "kStatusGroup_ApplicatinoRangeStart", add:
kStatusGroup_IAP = 102, /*!< Group number for IAP status codes */

kStatusGroup_HAL_GPIO = 121, /*!< Group number for HAL GPIO status codes. */
kStatusGroup_HAL_UART = 122, /*!< Group number for HAL UART status codes. */
kStatusGroup_HAL_TIMER = 123, /*!< Group number for HAL TIMER status codes. */
kStatusGroup_HAL_SPI = 124, /*!< Group number for HAL SPI status codes. */
kStatusGroup_HAL_I2C = 125, /*!< Group number for HAL I2C status codes. */
kStatusGroup_HAL_FLASH = 126, /*!< Group number for HAL FLASH status codes. */
kStatusGroup_HAL_PWM = 127, /*!< Group number for HAL PWM status codes. */
kStatusGroup_HAL_RNG = 128, /*!< Group number for HAL RNG status codes. */
kStatusGroup_TIMERMANAGER = 135, /*!< Group number for TiMER MANAGER status codes. */
kStatusGroup_SERIALMANAGER = 136, /*!< Group number for SERIAL MANAGER status codes. */
kStatusGroup_LED = 137, /*!< Group number for LED status codes. */
kStatusGroup_BUTTON = 138, /*!< Group number for BUTTON status codes. */
kStatusGroup_EXTERN_EEPROM = 139, /*!< Group number for EXTERN EEPROM status codes. */
kStatusGroup_SHELL = 140, /*!< Group number for SHELL status codes. */
kStatusGroup_MEM_MANAGER = 141, /*!< Group number for MEM MANAGER status codes. */
kStatusGroup_LIST = 142, /*!< Group number for List status codes. */
kStatusGroup_OSA = 143, /*!< Group number for OSA status codes. */
kStatusGroup_COMMON_TASK = 144, /*!< Group number for Common task status codes. */
kStatusGroup_MSG = 145, /*!< Group number for messaging status codes. */
kStatusGroup_SDK_OCOTP = 146, /*!< Group number for OCOTP status codes. */
kStatusGroup_SDK_FLEXSPINOR = 147, /*!< Group number for FLEXSPINOR status codes.*/
kStatusGroup_CODEC = 148, /*!< Group number for codec status codes. */
kStatusGroup_ASRC = 149, /*!< Group number for codec status ASRC. */
kStatusGroup_OTFAD = 150, /*!< Group number for codec status codes. */

7. Build and Test

8. "#ifdef" out the "main" method in the project .c file

8. Copy from source project
- "source/usb_device_descriptor.c"
- "source/usb_device_descriptor.h"
- "source/virtual_com.c"
- "source/virtual_com.h"
- "drivers/fsl_sysmpu.c"
- "drivers/fsl_sysmpu.h"
9. In the "main" method of "virtual_com.c" comment out:
- BOARD_InitPins();
- BOARD_BootClockRUN();
And replace from the project's "main" method with:
- BOARD_InitBootPins();
- BOARD_InitBootClocks();
- BOARD_InitBootPeripherals();

10. Build and Test

0 Kudos
65 Views
mykepredkomimet
Senior Contributor II

I think I have the answers to how the process and how it works.  

I successfully got my test board to run a USB CDC Device application (instructions here: Create K20 USB CDC Device).  

The problems I had was really one in terms of expectations - if I see that there is an SDK version 2.7.0 (the latest) for some parts that seem similar to what I want to use, I expect a) that the same/latest SDK version will be available for the part I want to use and b) the code in the SDK the part that I want to use is available for all options on the device.  

My recommendation is that when you are about to develop code for a part and want to get example code, find a Freedom/Tower board that has the same SDK as the part that you want to use/not a Freedom/Tower board that has the latest version.  This is true even if the part that provides the latest SDK seems to be a closer match to the one that you want to use instead of other Freedom/Tower boards.  Along with this, expect that you will have to copy code in manually from the example if it's not available natively from the SDK's project builder.  

This question will be marked "Solved".  

View solution in original post

0 Kudos