What changed between KSDK 1.2.0 and KSDK 1.1.0?

[surrealist14]

Hi folks,

I realize that new versions of software come out all the time.  Some are bug fixes, some are feature enhancements, some add support for new parts, and so forth.

I have a project that has been developed using KSDK 1.1.0 and the IAR Embedded Workbench for ARM Cortex-M on a K60 processor.  However, there are some things that are not working quite as expected (e.g. ADC readings), and I am wondering if I need to move to KSDK 1.2.0.  The problem, of course, is how much time it will take to convert.

There was another thread that mentioned difficulties migrating from KSDK 1.1.0 to KSDK 1.2.0, especially having to re-code the ADC sections of their application, because the API apparently changed.

I'd like to know if there is a list of exactly what has changed between KSDK 1.1.0 and KSDK 1.2.0, and whether these changes have anything to do with bugs in KSDK 1.1.0.

Can anyone provide me with this information?  I just can't seem to find such a list, but clearly something changed enough to cause a new release and an "SDK Migration" document to be created.

Thanks,

Scott

[jeffmakes]

I have just spent a solid 1.5 weeks migrating my codebase over from 1.1 to 1.2, and I'm still dealing with the aftermath. Bloody EVERYTHING seems to have changed.

The release notes are a joke - there are plenty of new features, and we can all agree that that's nice, but there are hundreds of small changes to the names of various functions, structs, constants, etc., that are not mentioned anywhere! It's not just simple name changes either, there are some more conceptual changes, eg. some drivers used to have their own functions for registering callbacks, whereas now they should be registered via the interrupt manager. This is an improvement, I agree, but it's not the kind of thing you can quickly fix with a bit of grepping!

So proceed with caution; if you're near the end of your project I would not recommend an upgrade. Luckily for me there was a natural pause in development when a new guy joined the team, and I wanted to do some major refactoring anyway.

[DaveTonyCook]

I Totally agree.  It's might be legally okay to have a disclaimer but it morally questionable.  Please please IMPROVE YOUR RELEASE NOTES!!! Gives us a fighting chance to make the right decision about whether or not to upgrade to the latest SDK.... or even use it at all  (.... hindsight is a wonderful thing)  

[ivadorazinova]

Hello DaveTonyCook,

thank you for your feedback. I will pass it to SW development team.

Regards!

Iva

[DaveTonyCook]

Thanks for your prompt reply.  can you tell me if there are any plans to release your internal change notes / bug reports. Thanks

[ivadorazinova]

Hello DaveTonyCook,

we have changes for Release Note in other versions KSDK (higher than 1.3).

New Release Note will describe the user aware API and data structure changes also will describe bugs fixes for release drivers.

The note about KSDK APIs changes were added to feature list.

Thank you for pointing this out!

Regards!

Iva

[DaveTonyCook]

Hi Iva,

That's great news moving forward.

However, can the internal bug report for the ADC API and HAL be made available to me? ( I migrated from KSDK_1.0.0 to KSDK_1.0.0-K24FN256) I would also like the internal bug report for versions  KSDK_1.0.0-K24FN256 to  KSDK_1.2.0 if possible.

Thanks

Dave C

[ivadorazinova]

Hello DaveTonyCook,

unfortunately it is not possible to send you internal list with bugs.

Best Regards,

Iva

[ivadorazinova]

Hello DaveTonyCook,

I will ask SW team and let you know.

Best Regards,

Iva

[DaveTonyCook]

Hi Iva,

Thanks for telling us that you know about your bugs... however we don't know about your bugs so could you please share so we can make informed decision

And please don't say it in the release notes as this is not the case.

If it is Freescales policy not to share this information then please say so

Thanks for your consideration

Best regards Dave Cook

[ivadorazinova]

Hello Scott,

KSDK 1.1 and KSDK 1.2 are different also in structure, these news are described in Kinetis SDK v.1.2.0 Release Notes

No other list of concrete changes KSDK 1.1 and KSDK 1.2 does not exist.

But - I can confirm you the information - I asked our SW team and let you know.

We have created document, which describes differences between older KSDK, 1.0 and KSDK 1.2 in structure - tips for their migration.

I´m attaching you the guide.

Best Regards,

Iva

[surrealist14]

Thank you for this guide, Iva.  However, it still doesn't really tell me what has changed between KSDK 1.1 and KSDK 1.2.  I understand that the organization of files has changed, but I would also like to know about API calls that have changed, and especially about any bug fixes that have occurred.  This will help me to determine if we should take the time to convert our project over to the latest KSDK 1.2.  If there are bug fixes in modules we use, we almost certainly want to convert.  If there are cosmetic differences only, we probably will not convert.

Looking forward to information from your SW team.  I appreciate the help!

Scott

[ivadorazinova]

Hello Scott,

yes - I fully understand your question.

The main advantage which new version brought is definitely new added devices (you can compare Release Note for KSDK 1.1 and KSDK 1.2), added peripheral support (AOI, ENC, FLEXBUS, FLEXIO, LMEM, VREF, XBAR, PWM), changes in folder structure like:

• SOC header files, extension header files, feature header files are moved from <install_dir>/platform/CMSIS/Inclulde/device/<soc_name> to <install_dir>/platform/device/<soc_name>/Include.
• Linker files are moved from <install_dir>/platform/linker/<soc_name> to <install_dir>/platform/device/<soc_name>/linker.
• startup codes are moved from <install_dir>/platform/startup/<soc_name> to <install_dir>/platform/device/<soc_name>/startup.
• board configuration files are moved from <install_dir>/boards/<board_name> to <install_dir>/examples/<board_name>.
• demo projects are moved from <install_dir>/demos to <install_dir>/examples/<board_name>/demo_apps.
• <install_dir>/filesystem and <install_dir>/tcpip are moved to <install_dir>/middleware.
• usb projects are moved from <install_dir>/usb/example to <install_dir>/examples/<board_name>/demo_apps/usb.

and other changes.

All important changes are in Release Note​.

However, we know about our bugs, these bugs are repaired and by the end of September we expect KSDK 1.3.

Best Regards,

Iva

[DaveTonyCook]

Hi

I've written an adc driver based on the sdk v1.0.0 and have since upgraded to v 1.1.0.  My adc driver has stopped working. Investigation has uncovered the changes detailed below.

It seems the two most significant changes that effect me are the changes to the state_ptr and how this is now handled. Also I notice that the ADC_CONV_SIGN32_MASK has changed which leads me to believe that the mask in v1.0.0 is incorrect and this will show as a bug when reading results from diff mode conversion. (I might be wrong in this assumption)

I'm using v1.1.0 but have copied v1.0.0 adc hal and driver code into the 1.1.0 sdk.  What is your advice in using v1.0.0 adc code? are there any bugs I should be aware of.  Can somebody please explain what the changes are for. What was broken? 

The changes:

#include "fsl_adc_features.h" removed, so no support for multiple devices?

#include "fsl_adc_common.h" removed not figured this out?

#define ADC_CONV_SIGN32_MASK    (0x80000000U) Mask changed to 0xFFFF0000

static adc_state_t *volatile g_adcStatePtr[HW_ADC_INSTANCE_COUNT]; Removed.  This is the biggest change. What's wrong with this method of doing things?

The functions below have been replaced with  Removed replaced with  ADC16_DRV_StructInitUserConfigDefault(adc16_user_config_t *userConfigPtr)

ADC_DRV_StructInitUserConfigForIntMode(adc_user_config_t *userConfigPtr)

ADC_DRV_StructInitUserConfigForBlockingMode(adc_user_config_t *userConfigPtr) Removed

ADC_DRV_StructInitUserConfigForOneTimeTriggerMode(adc_user_config_t *userConfigPtr) Removed

adc_state_t *userStatePtr has been removed therefore from the function below so Internal context g_adcStatePtr[instance] = userStatePtr; is not now supported.

ADC_DRV_Init(uint32_t instance, adc_user_config_t *userConfigPtr, adc_state_t *userStatePtr)

What is the significance of this?

how is this done in the adc16 driver

Why has the function below been moved to  fsl_adc_irq.c

uint16_t ADC_DRV_GetConvValueRAWInt(uint32_t instance, uint32_t chnGroup)

The mask ADC_CONV_SIGN32_MASK used in the conversion routine below has changed why?

int32_t ADC_DRV_ConvRAWData(uint16_t convValue, bool diffEnable, adc_resolution_mode_t mode)

The callback registration mechanism has been removed and it is now upto the user of the sdk to write his/her own. Removed and moved to fsl_adc_irq.c

adc_status_t ADC_DRV_InstallCallback(uint32_t instance, uint32_t chnGroup, adc_callback_t userCallback)

You guys must have check-in logs to your repository that explains the reason for the change to each file. Could you please post this information so that we can make informed decision regarding the use of the drivers that you have kindly provided for us.

Thanks