Multiple MCUXpresso SDKs

Sysprogs forums Forums VisualGDB Multiple MCUXpresso SDKs

This topic contains 7 replies, has 2 voices, and was last updated by  steve.n 1 month, 2 weeks ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #30003

    steve.n
    Participant

    Hi,

    I have would like to have multiple SDK versions of MCUXpresso SDK for the iMX RT 1064. When I check the box to allow for multiple versions, the SDK immediately disappears from the list.

    At the location of the SDK on disk, say, c:\nxp\sdk\SDK_2.9.1_MIMXRT1064xxxxA_AzureRTOS, a new folder \2.9.1 is made and the MultipleBSPVersions.txt created.

    If I then re-import at the new c:\nxp\sdk\SDK_2.9.1_MIMXRT1064xxxxA_AzureRTOS\2.9.1 folder, the process repeats. In other words, the SDK is imported fine, but the allow multiple versions is unchecked. If I check it, the SDK disappears from the list. It appears this feature MCUXpresso SDKs simply doesn’t work.

    #30009

    support
    Keymaster

    Hi,

    Indeed, the “Multiple BSP versions” flag works with the regular BSPs, but not imported BSPs like MCUXpresso.

    You can easily work around it by manually changing the PackageID attribute in the <SDK directory>\BSP.XML file to a unique value, and then either copying the SDK to %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi or creating a <arbitrary name>.bsplink file in that directory that will contain the absolute path to the SDK.

    Once you edited/moved the SDK, simply reopen the Tools->VisualGDB->Manage VisualGDB Packages window to make sure VisualGDB reloads the BSP list.

    #30035

    steve.n
    Participant

    Yes that allows multiple versions of the SDK. Thank you.

    However, there is a bigger problem I didn’t realize until now: it seems v2.9.1 doesn’t actually work. Although the Embedded Frameworks are listed, they don’t reference any files (if you click the arrow next to one of the Embedded Frameworks, the arrow turns but no files appear). When trying to build, it fails – due to missing SDK files.

    To reproduce, create a blank project based on v2.9.1. I used MIMXRT1064CVL5A. It will fail the test build in the New Embedded Project wizard. This is due to an invalid linker script file argument to ld. It passes the base directory of the BSP (without any file). You can ignore that and manually fix the linker, but the Embedded Frameworks are still not referencing any files.

    To ensure you can reproduce it, here is a link with the exact SDK builds I’ve used: https://1drv.ms/u/s!AuQSVn-fRqfI2Cp712hNIARXfuv6?e=fCoshz

    The 2.5.1 should work, the 2.9.1 does not.

    • This reply was modified 1 month, 2 weeks ago by  steve.n.
    #30037

    support
    Keymaster

    Hi,

    Indeed, the v2.9.1. internal format has slightly changed and won’t work with VisualGDB 5.5R4. We have fixed it on our side in the following build: VisualGDB-5.6.1.4033.msi (it will also go into the v5.6 Beta coming out this week).

    #30038

    steve.n
    Participant

    Ok, great.

     

    #30040

    steve.n
    Participant

    I guess I spoke too soon. I just tested  VisualGDB-5.6.1.4033.msi. The new Embedded Project Wizard completed OK, but the actual project doesn’t build. Embedded Frameworks are still also broken.

    #30041

    support
    Keymaster

    Hi,

    Most likely, you are still using the SDK imported using the old VisualGDB version. Please try deleting the entire SDK folder, and also the project, and re-creating everything from scratch.

    #30051

    steve.n
    Participant

    Yes, thank you, I didn’t think of that. It works.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.