topic Is there a relatively painless way to upgrade a project based on KSDK 1.1.0 to 1.2.0? in Kinetis Software Development Kit

Is there a relatively painless way to upgrade a project based on KSDK 1.1.0 to 1.2.0?

christophertsch — Fri, 29 May 2015 17:44:14 GMT

I tried exporting and importing an archive but that didn't seem to do what I wanted as it would not let me select the directory. Then I tried opening the existing project and got the below warning about how I should have the KSDK installed. So I went looking for a best practice and could find nothing.

Re: Is there a relatively painless way to upgrade a project based on KSDK 1.1.0 to 1.2.0?

Alice_Yang — Mon, 01 Jun 2015 03:04:10 GMT

Hello christ,

The file structure of KSDK 1.2 is different from KSDK 1.1, so do not recommend directly porting .

I recommend you create a new project on KSDK 1.2 , then only port the application code .

Hope it helps

Alice

Re: Is there a relatively painless way to upgrade a project based on KSDK 1.1.0 to 1.2.0?

ivadorazinova — Mon, 01 Jun 2015 06:53:48 GMT

Hello christophertschappatt,

thank you for the question.

Because there were some structure changes between KSDK 1.1 and KSDK 1.2, I recommend work separately with these files (e.g. for KSDK 1.1 use KDS 2.0 and for KSDK 1.2 use KDS 3.0), because hand in hand goes KDS release and its MCU support.

Please, keep in mind that for every KDS release you need separate workspace and installed Eclipse updates.

If you have larger project, it is better to migrate it by this way, I attach you a procedure.

I hope this helps,

Best Regards,

Iva

Re: Is there a relatively painless way to upgrade a project based on KSDK 1.1.0 to 1.2.0?

christophertsch — Tue, 02 Jun 2015 17:35:20 GMT

So the real answer should be NO. There is no relatively painless way of migrating existing code.

I ended up taking Alice Yang's advice and creating a new project and then meticulously adding the various components one by one and visually changing the settings from one project to the other. Then I had to re-code a number of things, like ADC's because of changes to the API. For example it used to be necessary to call ADC16_DRV_ConfigConvChn to change the channel being converted but now it is necessary to call that plus ADC16_DRV_SetChnMux since the former handles channel only and not the MUX A or MUX B thought.

Bottom line, if you are short on time stick with the tool/sdk you have until you can re-test everything.