Multiple MCUXpresso SDKs

Sysprogs forums Forums VisualGDB Multiple MCUXpresso SDKs

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 3 years, 2 months 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.