MCUXpresso MCU settings for different build Configuration

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

MCUXpresso MCU settings for different build Configuration

3,276件の閲覧回数
eoinpauldowling
Contributor II

I have a version of project that has a different MCU part from the same family. Just a bigger flash. I create a separate build configuration that has the different part number. When I switch between build configurations the part does not change and I need to manually change it each time. 

This costs a lot of time as this causes a full rebuild of the project.  It seems like a bug to me. 

Also the Preserve memory option seems to be selected automatically. So if you switch parts you need to uncheck this first.

Also the default Link server Flash Driver does not change automatically.  All of these can create bad builds. 

MCU settings for different build Configuration not retained

 

 

 

6 返答(返信)

2,155件の閲覧回数
stefan_bgw
Contributor I

I was able to achieve this by creating custom memory linker file and define different values for base flash in it, depending on build configuration.

It turned out to be the most elegant and portable solution.

Just keep in mind that that linker file needs to be created in the linkscripts folder and it needs to have same name as auto-generated one (for my case it's memory.ldt)

As jump-start for my custom linker script I used one that MCUXpresso auto-generate, and just changed needed regions.

I attached my linkerscript as reference.

At this line <#if buildConfig?upper_case?starts_with("STANDALONE_")> we are checking if build configuration is named STANDALONE_... or not.
 

 

3,169件の閲覧回数
nxp16
Contributor III

I am having similar issues with this.  Because the MCU settings are global for the project, I can't create a build configuration that moves the app start address to a different address to make it bootloadable by our bootloader.  I.e. standalone, the app runs on the IMXRT1064 at 0x70000000 like it's supposed to, but I need to create a build configuration where it starts at 0x70020000 because our bootloader is going to start at 0x70000000 and I also have to turn off XIP defines.  When will this be fixed?  This is the 3rd time I've run into issues with this (I can't remember what the first two issues I had with this were, but this one was the last straw for me, making me want to post about it).

0 件の賞賛
返信

3,167件の閲覧回数
converse
Senior Contributor V

LPCXpresso and MCUXpresso have been like this for over 10 years, so I doubt it is going to change anytime soon.. However, you can do this with separate projects for each MCU and either

a) having your main source as a library project (and so link with the library in each project), or 

b) use "Linked resources". This works a bit like symbolic links in Linux file systems. Search for "eclipse linked resources" to see how it works

3,165件の閲覧回数
nxp16
Contributor III

I guess that would work, but it's a kind of crappy workaround.  My guess is that the MCU settings affect the configurator and everything else so this won't ever be changed.

0 件の賞賛
返信

3,261件の閲覧回数
eoinpauldowling
Contributor II

OK Thanks @ErichStyger will try that. Hopefully this can be improved.

0 件の賞賛
返信

3,264件の閲覧回数
ErichStyger
Specialist I

Hi @eoinpauldowling ,

I have been running into the same thing: using the K02 64KByte and K02 128KByte for the same project.

The missing item for the MCU settings is that it lacks the setting for the configuration, to make it configuration aware, as it is present for other CDT setting pages:

ErichS_0-1606744962969.png

I have expressed this as a need in the past and I hope this can be implemented in a future IDE version (keeping fingers crossed).

I solved it with using external folders/libraries: basically the K02_128 and the K02_64 are just the project with a main and configuration files, and everything is in the 'common' part: that way I can keep the things separate and the same time aligned. You might have a look how I did this on https://github.com/ErichStyger/MetaClockClock 

Other than that, you might consider a shell script manipulating the .cproject file depending on your needs. I did consider this, but thought my above solution is a more portable one.

I hope this helps,

Erich