Missing changelog for SDK 2.12.0

[scottm]

I've updated an LPC55S69 from SDK version 2.8.2 to 2.12.0, but I'm not able to find any documentation on the changes between the two versions. Or at any rate, not complete documentation. In particular, the CTIMER driver has been updated and CTIMER_SetupPwmPeriod() now takes an extra parameter. It's not explained anywhere. I think I've got that figured out, but I want to read up on all of the changes between versions.

I'm not even able to determine from this what versions of the SDK have existed. The changelog only lists driver and component level version numbers - for example, it says that the current CLOCK driver version is 2.3.6. The previous version was 2.3.5, but it doesn't say what SDK version that was. Also, looking in fsl_clock.h and fsl_clock.c, there are no version numbers provided, and the header provides no identifying information at all aside from copyright years.

The release notes say (very ungrammatically) "Change log of software components included in the package, see the MCUXpresso SDK ChangeLog_LPC55S69.pdf."

The changelog is titled "MCUXpresso SDK Release Notes Supporting lpcxpresso55s69". Is the lpcxpresso naming scheme still in use here?

CTIMER isn't listed as having changed. Ever. There's no reference to CTIMER at all in the changelog.

Does a changelog exist somewhere? If not, what's the expected way to determine differences? Are we to download previous versions and diff them for review?

Thanks,

Scott

[Alice_Yang]

Hello @scottm 

Sorry there isn't CTIMER changelog, I will report it to SDK development team.

BR

Alice

[Alice_Yang]

Hello @scottm 

Could you please tell us why do you want to compare the difference? Porting project from SDKv2.8 to SDKv12?  How about still using SDKv2.8? Or create new project on SDKv12, then development based on it.

BR

Alice

[scottm]

Could you please tell us why do you want to compare the difference?

I have to say I'm a little taken aback at the question. Is it not standard procedure for your developers to document changes? Particularly when the API changes?

Porting project from SDKv2.8 to SDKv12?  How about still using SDKv2.8? Or create new project on SDKv12, then development based on it.

By 'project' I'm referring to my application, not the 'project' in the sense of the IDE files. The application began 10 years ago on ColdFire v1 with CodeWarrior, and then Kinetis with KDS. It's used PEx and KSDK in previous versions.

When I began evaluating the LPC55S69 to replace the MK22FN1M0AVLH12 (which is still expected to be unavailable for another year and a half, last I checked) 2.8.2 was the latest SDK version. Now I'm in the process of porting the hardware support portion of the application to work with MCUX SDK, and there's no reason to do that using an old version.

In the past I've spent far too much time tracking down bugs in SDK code only to find that they were fixed in later versions. Case in point, the Freescale bare metal USB driver had a major bug in its composite device support that gave me all sorts of grief. I tracked it down to an uninitialized variable. The bug was fixed in later versions.

I'm trying to avoid that sort of problem. Every time a new SDK version comes out, I at least need to know what bugs have been fixed to see if I need to upgrade, even if there's no need to use new features.

This is not just an academic exercise. I have thousands of deployed devices to support. I spent years thinking I had a problem in my code on one product and it turned out to be a silicon flaw relating to the MCU experiencing an overclock condition upon exiting from a low power mode. There was a fix documented in an obscure erratum that I'd never received a notification about. I've learned to stay vigilant about following all hardware errata and software changes.

If I have to diff the code between SDK versions I'll do that because my livelihood depends on it but it's a little absurd to have to do that with the output of a multi-billion dollar company. Surely the SDK changes must be tracked somewhere.

Scott

[jackking]

You might get a little more insight from the GitHub repo for the SDK:   https://github.com/nxp-mcuxpresso/mcux-sdk 

[scottm]

Thanks. Is that repository official? Who maintains it?

I can only find commits back to the 2.9.0 release for the ctimer driver.

[Jmart]

NXP maintains and publishes the MCUXpresso SDK to https://github.com/nxp-mcuxpresso/mcux-sdk. Currently, there are some delays between the availability of the latest MCUXpresso SDK on the web and github, typically 3-4 weeks; these delays are planned to be shortened in the 2.13.0 release in January, 2023.

The MCUXpresso SDK github was first published in January of 2021, and why you're unable to find anything preceding 2.9.0.

[scottm]

It's been two weeks and I still don't have an answer on this. Where can I find a changelog for the missing components, CTIMER included?

[JimmyChen · Accepted solution]

hi scottm,

Sorry for the late feedback. i'll provide feedback for topics mentioned in this thread.

First about the CTimer changelog, for LPC55S69, the 2.12.0 release get ctimer version 2.2.2 and 2.8.0 release get ctimer version 2.0.3. i posted the full change log from 2.0.3 to 2.2.2 at bottom of this reply.

Next about the missing chapter of CTimer change log in API Reference manual. The change log for each component is always maintained during development. In the LPC55S69 case it is due to script bug that it is not picked into the SoC specific API RM as you may already observe peripheral drivers are shared among SoCs and there is a step to pick needed component change log into SoC specific document. I expect this script/pick-process issue for the API RM can be fixed soon, likely for MCUXpresso SDK release since July (2.14.0 and future versions) this year.

 Last part is about the MCUXpresso SDK github delivery. It is officially supported by NXP and maintained by us, same team creating the MCUXpresso SDK delivery in mcuxpresso.nxp.com.  From aspect of source code content, they are almost identical to latest MCUXpresso SDK release cause we sync the MCUXpresso SDK content into github repo at least twice a year. The special case is we also accepting PR from community so there may be diff for some period. Comparing to MCUXpresso SDK package which is only for one or two SoC, MSDK Github is superset. So that we can find sources code for all supported SoCs. It is in our to-do list that build the "superset" API RM in github or at least includes the raw change log doxygen content into the github release. We are waiting for available bandwidth to work on this task.  With this feature ready, user can get the full history for all components, we can check the macro of FSL_IP_DRIVER_VERSION in fsl_ip.h to get the version and find the version diff info.

/*!
@section ctimer CTIMER
  The current CTimer driver version is 2.2.2.
  - 2.2.2
    - Bug Fixes
      - Fixed SetupPwm() API only can use match 3 as period channel issue.
  - 2.2.1
    - Bug Fixes
      - Fixed use specified channel to setting the PWM period in SetupPwmPeriod() API.
      - Fixed Coverity Out-of-bounds issue.
  - 2.2.0
    - Improvements
      - Updated three API Interface to support Users to flexibly configure the PWM period and PWM output.
    - Bug Fixes
      - MISRA C-2012 issue fixed: rule 8.4.
  - 2.1.0
    - Improvements
      - Added the CTIMER_GetOutputMatchStatus() API Interface.
      - Added feature macro for FSL_FEATURE_CTIMER_HAS_NO_CCR_CAP2 and FSL_FEATURE_CTIMER_HAS_NO_IR_CR2INT.
  - 2.0.3
    - Bug Fixes
      - MISRA C-2012 issue fixed: rule 10.3, 10.4, 10.6, 10.7 and 11.9.
  - 2.0.2
    - New Features
      - Added new API "CTIMER_GetTimerCountValue" to get the current timer count value.
      - Added a control macro to enable/disable the RESET and CLOCK code in current driver.
      - Added a new feature macro to update the API of CTimer driver for lpc8n04.
  - 2.0.1
    - Improvements
      - API Interface Change
        - Changed API interface by adding CTIMER_SetupPwmPeriod API and CTIMER_UpdatePwmPulsePeriod API, which both can
          set up the right PWM with high resolution.
  - 2.0.0
    - Initial version.
*/

[scottm]

OK, but there's still no reference to CTIMER in the changelog. There was an API-breaking change and I can't find any reference to it at all. Where do I find that?

[jackking]

It is supposedly "official", run by NXP. 

I have seen inconsistencies in how it is maintained compared to the "official" release from the SDK dashboard.