Sysprogs forums › Forums › VisualGDB › Multiple MCUXpresso SDKs
- This topic has 7 replies, 2 voices, and was last updated 3 years, 9 months ago by steve.n.
-
AuthorPosts
-
February 26, 2021 at 09:31 #30003steve.nParticipant
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.
February 26, 2021 at 18:36 #30009supportKeymasterHi,
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.
March 1, 2021 at 10:07 #30035steve.nParticipantYes 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, 9 months ago by steve.n.
March 1, 2021 at 10:17 #30037supportKeymasterHi,
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).
March 1, 2021 at 10:52 #30038steve.nParticipantOk, great.
March 1, 2021 at 12:34 #30040steve.nParticipantI 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.
March 1, 2021 at 13:56 #30041supportKeymasterHi,
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.
March 2, 2021 at 06:02 #30051steve.nParticipantYes, thank you, I didn’t think of that. It works.
-
AuthorPosts
- You must be logged in to reply to this topic.