AnsweredAssumed Answered

Switching MCU type

Question asked by SCOTT MILLER on Oct 6, 2018
Latest reply on Nov 20, 2018 by SCOTT MILLER

I'm making another attempt to migrate a moderately complex existing project to the MCUX SDK and and I can't seem to get much beyond square one.


My understanding is that the only supported way to get the USB component of the SDK into a project is to import a demo project.  My target MCU is the MK22FN1M0AVLH12, but there's no board specifically for that MCU and the only supported board with any example projects in the SDK is the TWRK21F120M, which has an MK21FN1M0.  I'm starting with the dev_composite_cdc_msc_freertos demo.


I'm able to use the clocks tool to configure the project for the 12 MHz crystal my board uses, and with that set properly I'm at least able to boot and enumerate.  If I go into the pins tool, though, I see that the 64 LQFP package isn't available on this variant.  Changing to any variant gives me a warning that the processor type doesn't match, and I can't find where it expects that to be changed.  I get more errors if I go into the project settings and change the MCU type there.


Before I spend any more time chasing my tail, what is the proper way to do this?  My objective is to get a 'hello world' project set up for the MK22FN1M0AVLH12 with FreeRTOS, pins/clocks tools working properly, and SDK drivers for basically everything except flexbus, flexcan, crc, i2c, rnga, sdhc, and smartcard.


From there I plan to start bringing in the application code, resolving conflicts between the SDK and the existing drivers, and eventually rewriting the low-level code to use the SDK drivers wherever they're suitable.  I need to know I've got the project framework set up properly first, though.


If the pins and clocks tools aren't available for this MCU, is there documentation on how to migrate the project off of those tools?  The first thing I noticed is that clock_config.c has the oscillator frequency hard-coded in oscConfig_BOARD_BootClockRUN.freq, but it's also defined in the header as BOARD_XTAL0_CLK_HZ.  The fact that clock_config.c doesn't use the macro suggests that the tool-generated files were not intended to be edited by hand and it looks like I'd have to review the whole thing line by line to find that kind of duplication.