K22F Migration

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

K22F Migration

Jump to solution
1,552 Views
nxf63973
NXP Employee
NXP Employee

On behalf of mykepredkomimetics‌:

Could you please describe the process for generatng SDKs?  

 

The variations between parts is extremely frustrating - I'm working on a product that will use the MK22FN1M0Axxx12 (SDK 2.3.1) and I'm prototyping interfaces and software on the FRDM-K22F (MK22FN512xxx12 - SDK 2.7.0).  

 

While I acknowledge that there are differences in clocking and peripheral operation between the two devices, I would have thought that bringing the MK22FN1M0Axxx12 up to SDK 2.7.0 should be a fairly easy process.  I'm guessing it's not an automated process but I would like to understand what's involved and what are the plans going forwards to bring SDK supported devices up to the latest levels?  

 

Porting software written for SDK 2.7.0 to SDK 2.3.1 is a non-trivial process especially with the differences in the USB Device libraries and in the different versions of FreeRTOS that I am dealing with.  I should also point out that creating projects under SDK 2.7.0 is significantly more advanced with less follow on work than creating projects under SDK 2.3.1.  

 

Ideally, I would like to port the code to the previous product (so we have a common code base) to our MK20FN512xxx10 based product, that that is SDK 2.2.0 and has even more challenges in porting the software.  

 

Thanx for your comments and understanding of life in the trenches.  

0 Kudos
1 Solution
1,276 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Myke Predko

   In fact, the MCUXpresso IDE wizard can select the USB, the perpherals, it is based on the SDK2.7.0 package. But MK22FN1M0AVMD12's related SDK is the SDK2.3.1, which is not in the support list now.

   I have help you check with the SDK related department, they told me, the new SDK2.8.0 which will launch in the near future is also not update the MK22FN1M0AVMD12 SDK(TWR-K21 sdk), just the FRDM-K22 is updated.

   So, maybe you can't use the MCUXPresso IDE new feature for your chip MK22FN1M0AVMD12  now.

   About your question: Can the part that I'm using (the MK22FN1M0AVMD12) be updated to SDK 2.7.x?  I'm not sure why you would ask about the K21 series.  

  If you check the doc which I recommend you:Kinetis K22_120 MHz devices 

 You will find MK22FN1M0AVMD12 is using the K21 platform SDK, the clock system, the module is the same IP as the K21, not FRDM-K22,  K22 have a lot of series, different partnumber need to refer to different board, that's why I double check it with you.

  I have a question, could you please also provide the detail MCU requirement, I want to check, whether some other new updated SDK MCU can meet your demand. What about K24, K28, K64, K66, whether these partnumber can meet your demand, these chip are also have FRDM board and update the SDK now.

From the now situation, seems the K21 SDK(also for MK22FN1M0AVMD12  ) won't update anymore. It's also difficult for you to generate the new package which also let the MCUXPresso IDE tool to recoginize it for your requirement module configuration.

Best Regards,

Kerry

View solution in original post

0 Kudos
9 Replies
1,277 Views
myke_predko
Senior Contributor III

Hi Kerry,

What I need is:

  • MINIMAL COST
  • 0.5mm MAPBGA/LQFP or larger.  No smaller geometry parts to minimize PCB/Assembly costs
  • 120MHz Operation.  This includes Flash Writing at this speed
  • 1M+ Flash
  • 128k+ SRAM
  • Full Access to the JTAG programming port (ie no other functions for these pins)
  • USB CDC Device
  • 2x ADC Channels.  3x would be nice
  • 2x SPI with DMA
  • 2x UART, one with DMA
  • 3x I2C, one with DMA
  • 4x FTM (PWM Output)
  • Wav file output (11,025 sps)
  • 70+ GPIO (DI, DO and Interrupt Sources)

I'm open to considering other parts than the MK22 but as this is late in the game I need strict guarantees that I will not have unreasonable software porting issues and that costs will not increase.  You keep pushing the MK21 but I want to point out that the MK21FN1M0AVMD12 costs $8.75 in 1k Quantities while the MK22FN1M0AVDM12 costs $8.33 in 1K Quantities.  Not that it matters as nobody will be udating the SDK for either device.  

This has been a thoroughly discouraging and unsatisfactory exercise.  I simply wanted to point out that developing Kinetis projects with SDK 2.7.0 was a good experience, especially compared to developing projects for the SDK 2.3.1 which is for the device I want to use (and was recommended to me by my NXP FAE).  I have asked when will the SDK for the part that I want to use will be brought up to SDK 2.7.0 (the answer seems to be "never" and when I follow up and ask why is that and what is the process for updating or selecting the parts for update, I don't get an answer).  I should point out that you are giving me recommendations based on a post (Kinetis K22_120 MHz devices) that I honestly can't find using the search tools nor would I have any reason to look for it as my assumption would be that NXP treats all devices similarly in terms of software support - I never would have imagined that there is some arcane, undocumented process in which some devices are selected for SDK upgrades while others languish in downlevel hell.  

I've asked this reply be marked as "answered" as I have my answer.  If you want to continue the conversation, contact me directly there's no need for this to continue publically.  

0 Kudos
1,277 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Myke Predko,

     So sorry for the inconvenience we bring you, K22 series is really a little different.

     Could you please tell me Jose Gallegos is you FAE?

     I will contact with your FAE internally, and try to contact with our marketing department, whether your MK22FN1M0AVMD12 can be upgraded in the near future, after I contact with the SDK team, they told me the marketing determine which sdk partnumber to be updated. Now, your MK22FN1M0AVMD12  is not in the upgrade list.

    Please keep patient!

Best Regards,

Kerry

0 Kudos
1,277 Views
myke_predko
Senior Contributor III

Hi Kerry,

No, Jose is not my FAE.  

Please contact me privately.  I don't think it serves any positive purpose to continue this conversation publicly.  

0 Kudos
1,277 Views
myke_predko
Senior Contributor III

Jose,

Thank you for pulling this out and making it a discussion. 

I really like the way that the SDKs and MCUXpresso work together along with how slick SDK 2.7.0 is for creating a USB CDC device application integrated with the different peripherals designed into the devices.  I'm sure there are other, just as useful, interface libraries available that are important for other developers.  NXP has a great tool set here for a limited number of devices typically used in Tower and Freedom boards which unfortunately is a lot less great for the vast majority of NXP devices.

From the business side of things, it makes sense to prioritize the software bases devoted to the demo products, but there needs to be a strategy for bringing the SDKs for as many devices as possible up to the latest level as quickly as possible.  I'm sure I'm not the only person who is developing prototype/demo software on a Freedom/Tower board and discovering that porting/migrating the code to another device is a surprisingly difficult exercise.  

If I can make a comment; the thread subject you gave, "K22 Migration", is a misnomer.  I have been able to develop a software framework where I am placing all the SDK API calls (this is also an an issue for FreeRTOS as 2.7.0 provides version V10.2.1 and 2.3.1 provides V9.0.0 but I'm managing) in separate methods where I can compartmentalize the differences but it's a fair amount of work on my part to maintain two code bases which do the same thing AND making sure the right ones are being used on the platform builds (I want to add a third platform to the mix, but it's processor has an SDK at the 2.20 level).  Migrating my code between the SDKs isn't the issue - the *need* to do the migration is.  

Explaining the SDK creatiion process and what needs to be done in it would be helpful as would be using the community to help with the work of bringing the SDKs up to the latest level for as many devices as possible in the shortest amount of time.  

Regards,

myke

0 Kudos
1,277 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Myke Predko ,

   Do you want to use the MK22FN1M0Axxx12, right?

   If yes, you can't refer to the FRDM-K22 board, you need to refer to the TWR-K21F120M board, as K22 series have a lot of types, you can find some information from this link:

https://community.nxp.com/docs/DOC-102548

2.jpg

About the TWR-K21F120M new SDK, I will help you to report your requirement to our SDK team.

Now, if you use the SDK2.3.0 for your MK22FN1M0Axxx12, any issues about it?

Kerry

 

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
1,277 Views
myke_predko
Senior Contributor III

Hi Kerry,

Thank you for responding.  

With respect, how do you expect somebody to find the apparently random link Kinetis K22_120 MHz devices when they are starting out?  If I look at Useful Kinetis Documents, discussions and questions it's not listed nor is anything approaching this listed. 

As I embarked on this project, I did confer with my FAE to make sure I was selecting the correct device for the product (the MK22FN1M0Axxx12) and did ask what would be good for doing my hardware/software development and I was told "whatever, but use one with the latest SDK as it will be easier".  He actually recommended the FRDM-K64F and FRDM-K22F as they have SDK 2.7.0.  The TWR-K21F120M was never mentioned nor were any links discussing different options were presented.  

I'm sure that NXP/Freescale engineers have spent a lot of time on the Tower boards but for doing hardware prototyping they're terrible - at a minimum you need the side boards along with the Protoboard which is mechanically unstable and quite difficult to plug/unplug as you are working on the circuitry. In contrast, the Freedom boards can take a simple Arduino prototyping board which is very mechanically stable and reliable.  I can easily prototype the different systems and then integrate them together into the product (which is made easier by using FreeRTOS and merging the tasks together into the final product).  For these reasons, I tend to eschew Tower boards for Freedom when I'm doing prototyping.  

Here is one of the prototype circuits that I'm using for the product development:

2020.06.04 - Prototype Board.jpg

In terms of SDK 2.3.1 issues, the big one for me is USB CDC Device - using the project wizard in SDK 2.7.0, when you select "USB device" in "Middleware" Bob's your uncle all the libraries are put in place and the clock generation tool seems to have the USB hardware clocking paths enabled.  When using SDK 2.3.1, there is no selection for USB device in Middleware (but there is for CMSIS but this doesn't seem to load any hardware drivers) which meant I had to copy the driver files from the 2.3.1 FreeRTOS USB device example AS WELL AS figure out how to get clocking selected for USB.  Clocking (as you will see if you look at my posts over the past six months) was a particularly nasty problem which took me literally months to figure out how to get the USB components enabled (and I'm still not sure of the process, I just bang on the clock wizard controls until they get enabled and then select the correct multiplier/divider values).  For the most of this project, I copied clock_config.c/.h from the TWR-K21F120M example project as it was too frustrating to figure out how to get the USB paths working - I have figured it out, but it's only been in the last month or so.  

When I have to create a new project, along with selecting the libraries I want to use, copying in the .mex file, followed by changing the size of the "SRAM_UPPER"/"SRAM_LOWER" (the need for doing will be a rant for another day) the SDK 2.3.1 process requires me to add the "osa"/"usb" folders for the USB drivers, make numerous changes to the "Preprocessor" and "Includes" of the "C/C++ Build" settings - none of which are required for SDK 2.7.0.  Not a big nit, but it takes five minutes longer to create an SDK 2.3.1 project than an SDK 2.7.0 with a *lot* more opportunities for error.  

There are a number of minor annoyances that I've encountered so far (like "GPIO_SetPinsOutput" which exists in SDK 2.3.1 and not in SDK 2.7.0 and the I2C/UART/SPI drivers don't work the same way between the two SDKs) but I'm bright enough to figure them out and work around them - as I said, I've changed my software architecture to place all the direct IO methods in separate files that I can swap in and out.  

I don't want this to be thought of as a rant - I'm hoping that it is received as a valid complaint about the work required to port software across SDK versions for devices in the same Kinetis family.  You may feel the approach that I'm taking for software/hardware development (using the Freedom boards rather than the Tower board) to be the wrong one, but I do have my reasons and it's not like there's documentation that can be easily found explaining the recommended approach. I do recognize that different devices are different and some features will work differently but I would expect the SDKs to minimize those differences as much as possible so that software can be shared between devices as much as possible. 

Thank you for your consideration and understanding - in MCUXpresso with the device SDKs you have a very good set of tools.  The value proposition for this approach is to minimize software development time by providing a set platform for the developer but, unfortunately, this value is lost when the SDKs across devices are not compatible and the developer has to spend long hours learning what the differences are and creating work arounds for them.

myke

0 Kudos
1,277 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Myke Predko

   Which detail MK22FN1M0Axxx12 chip partnumber you are using? Whether it is the same package as the FRDM-K22 on board chip?

  I will check with SDK department, whether the K21 series can be updated to the SDK2.7.X in the future.

Best Regards,

Kerry

0 Kudos
1,277 Views
myke_predko
Senior Contributor III

Hi Kerry,

The part number I'm using for the product is MK22FN1M0AVMD12 (MK22, 1M Flash, 144 Pin BGA).  It is definitely not the same package as the MK22FN512VLH12 used on the FRDM-K22F.  

Can the part that I'm using (the MK22FN1M0AVMD12) be updated to SDK 2.7.x?  I'm not sure why you would ask about the K21 series.  

This really goes back to my original questions - how much work does it take to update an SDK for device family and what is the strategy for bringing all devices in a family to the same level?  

myke

0 Kudos
1,277 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Myke Predko

   In fact, the MCUXpresso IDE wizard can select the USB, the perpherals, it is based on the SDK2.7.0 package. But MK22FN1M0AVMD12's related SDK is the SDK2.3.1, which is not in the support list now.

   I have help you check with the SDK related department, they told me, the new SDK2.8.0 which will launch in the near future is also not update the MK22FN1M0AVMD12 SDK(TWR-K21 sdk), just the FRDM-K22 is updated.

   So, maybe you can't use the MCUXPresso IDE new feature for your chip MK22FN1M0AVMD12  now.

   About your question: Can the part that I'm using (the MK22FN1M0AVMD12) be updated to SDK 2.7.x?  I'm not sure why you would ask about the K21 series.  

  If you check the doc which I recommend you:Kinetis K22_120 MHz devices 

 You will find MK22FN1M0AVMD12 is using the K21 platform SDK, the clock system, the module is the same IP as the K21, not FRDM-K22,  K22 have a lot of series, different partnumber need to refer to different board, that's why I double check it with you.

  I have a question, could you please also provide the detail MCU requirement, I want to check, whether some other new updated SDK MCU can meet your demand. What about K24, K28, K64, K66, whether these partnumber can meet your demand, these chip are also have FRDM board and update the SDK now.

From the now situation, seems the K21 SDK(also for MK22FN1M0AVMD12  ) won't update anymore. It's also difficult for you to generate the new package which also let the MCUXPresso IDE tool to recoginize it for your requirement module configuration.

Best Regards,

Kerry

0 Kudos