Is there a way to port an SDK to another device?

[myke_predko]

My product is going to use the MK22FN1M0Axxx12 device (which has an SDK level of 2.3.1) and I am prototyping software and interfaces with the FRDM-K22F (which has an SDK at 2.7.0 for the MK22FN512xxx12 device).  I'm finding that the SDK of 2.7.0 (with drivers and other features) are quite a bit easier to work with than the 2.3.1, especially considering porting the code from 2.7.0 where there are differences in the SDK which I have to debug/work through.  The ideal would be to have an SDK 2.7.0 for the MK22FN1M0Axxx12.  

Is there a process that outlines how to port an SDK from one device to a similar one.  I believe the differences would be in processor ID, memory size, pinouts, the numbers of various peripherals and maybe a UID for validating the SDK when it gets loaded into MCUXpresso.  Is this documented?  

I'm willing to do the work as it can't think it would be any more onerous than kdiff'ing different source code levels when the code works on the SDK 2.7.0 drivers on the FRDM-K22F but fails under the SDK 2.3.1.  I would also be happy to share the results.  

Thanx!

[Sebastian_Del_Rio · Accepted solution]

Hi Myke, I hope you're doing well!

It is possible to port an SDK update from one device to another, however, some careful considerations and observations need to be made, as the two devices you're referring to, while very similar in features, do differ from one another.

Unfortunately, there's no document detailing the migration from one type of device to another in this case, so the best bet could be to compare the differences between the exact part you're using, with one of the parts that has the updated SDK, and update the necessary components while keeping the ones exclusive to the MK22FN1M0Axxx12.

These differences are mostly documented in the K Series Product Selector Guide, on page 14. From the document, the main differences I see apart from the ones you listed are: the CAN interface, the Memory Protection Unit, and the evaluation board itself (with the MK22FN1M0Axxx12 being supported by the TWR-K21F120M evaluation kit), along with specific peripheral and GPIO counts, among other smaller differences.

I'm really sorry for the inconveniences this may cause.

Please let me know if you need any more information.

Best regards,

Sebastian

[myke_predko]

Hi Sebastian,

Thanx - that's the answer I was expecting (and not hoping for).  

When the SDK and pin/clock tools are set up for a device with a Freedom/Tower board (ie 2.7.0) it really works well.  The TWR-K21F12M (with an SDK of 2.3.1 - I've been currently using it for about three months now) doesn't provide the same level as functionality as 2.7.0 for the FRDM-K22F and there are a number of differences between them.  I spent all day Saturday porting SPI code from the FRDM-K22F (SDK 2.7.0) to the MK22FN1M0Axxx12 with the SDK 2.3.1 and getting it to work.  

I can appreciate that it's difficult to keep ALL the devices at the same and latest level but there really needs to be a way to minimize the work people who prototype/develop on the Tower/Freedom boards and want to port the code to one in the same family.  

myke