"Manage SDK Components" stops working after switching MCU

[danielholala]

Hello,

MCUXpresso IDE version has the ability to add or remove SDK components to/from a project via a the Manage SDK components wizard...

... until you switch MCU.

For example I imported the FreeRTOS USART example from the LPC5526 SDK for the LPC55S28 MCU (that's possible because the SDK includes examples for the LPCXpresso55S28 eval board).

From the Project Explorer, the context menu SDK Management > Manage SDK Components opens said wizard:

"FreeRTOS kernel" is selected. On other tabs (Drivers, ...), the included SDK components are selected, too.

Now I switch MCU to LPC5526 that has a different memory setup but is otherwise compatible with LPC55S28 MCU (with regard to this example). Then the wizard looks like this:

The IDE has completely lost track of all SDK components that are included in this project. I cannot further add/remove SDK components. Peripherals tools complains about missing SDK components.

Of course, the source files are still in the project, the project compiles. Only the meta information about the included SDK components has gone missing. Switching the MCU back to the original one does not help.

Why is all SDK meta information lost when switching MCU?

How do I restore or recreate the information about installed SDK components?

Thanks.
Daniel

PS: Tested and reproduced with MCUXpresso 11.5 and 11.4.1

[danielholala]

Hello again,

I observed that switching MCU also breaks Peripheral Tools. It shows errors and reports missing drivers:

Components view:

List of problems:

[lpcxpresso_supp]

Hi,

We reproduced the error locally and we’ll address it in a future IDE release.

Expected behavior: MCUXpresso IDE saves the components used in the current example in the .cproject file under "storageModule moduleId="com.nxp.mcuxpresso.core.datamodels"" xml node.

Error: This module is recreated when switching the MCU but SDK component information is lost. 

Workaround: Unfortunately, there is no workaround in the IDE directly, but from file system. One way to restore the information is to:

1. Before changing the MCU go to project folder, open .cproject file and copy&save the <storageModule moduleId="com.nxp.mcuxpresso.core.datamodels"> node element
2. Switch the MCU part
3. Close the project in Eclipse
4. Go back and edit .cproject file
5. Paste the saved “storageModule moduleId="com.nxp.mcuxpresso.core.datamodels"” over the existing one (which you’ll notice it has now less elements)
6. Reopen the project and check the Manage SDK Components option

Regards,

MCUXpresso IDE Support

[danielholala]

More experiments:

This is the "datamodels" storage module in .cproject after importing the example project:

<storageModule moduleId="com.nxp.mcuxpresso.core.datamodels">
		<sdkName>SDK_2.x_LPC5526</sdkName>
		<sdkExample>lpcxpresso55s28_freertos_generic</sdkExample>
		<sdkVersion>2.11.0</sdkVersion>
		<sdkComponents>middleware.freertos-kernel.cm33_nonsecure_port.LPC55S28;platform.drivers.clock.LPC55S28;middleware.freertos-kernel.heap_4.LPC55S28;platform.drivers.common.LPC55S28;platform.drivers.power.LPC55S28;device.LPC55S28_CMSIS.LPC55S28;device.LPC55S28_startup.LPC55S28;platform.drivers.flexcomm_usart.LPC55S28;platform.drivers.flexcomm.LPC55S28;platform.drivers.lpc_iocon.LPC55S28;platform.drivers.lpc_gpio.LPC55S28;platform.utilities.assert.LPC55S28;utility.debug_console.LPC55S28;component.usart_adapter.LPC55S28;component.serial_manager.LPC55S28;component.lists.LPC55S28;component.serial_manager_uart.LPC55S28;middleware.freertos-kernel.LPC55S28;middleware.freertos-kernel.extension.LPC55S28;platform.drivers.reset.LPC55S28;CMSIS_Include_core_cm.LPC55S28;platform.utilities.misc_utilities.LPC55S28;device.LPC55S28_system.LPC55S28;lpcxpresso55s28_freertos_generic;</sdkComponents>
		<boardId>lpcxpresso55s28</boardId>
		<package>LPC55S28JBD100</package>
		<core>cm33</core>
		<coreId>cm33_core0_LPC55S28</coreId>
	</storageModule>

I switch the MCU to LPC5526. Looking at .cproject, the storage module is quite void from any information:

	<storageModule moduleId="com.nxp.mcuxpresso.core.datamodels">
		<sdkName>SDK_2.x_LPC5526</sdkName>
		<sdkVersion>2.11.0</sdkVersion>
	</storageModule>

Without closing the project, I switch the package to LPC5526JBD64. The storage module is now populated with information again:

	<storageModule moduleId="com.nxp.mcuxpresso.core.datamodels">
		<sdkName>SDK_2.x_LPC5526</sdkName>
		<sdkVersion>2.11.0</sdkVersion>
		<sdkExample>lpcxpresso55s28_freertos_generic</sdkExample>
		<sdkComponents>middleware.freertos-kernel.cm33_nonsecure_port.LPC55S28;platform.drivers.clock.LPC55S28;middleware.freertos-kernel.heap_4.LPC55S28;platform.drivers.common.LPC55S28;platform.drivers.power.LPC55S28;device.LPC55S28_CMSIS.LPC55S28;device.LPC55S28_startup.LPC55S28;platform.drivers.flexcomm_usart.LPC55S28;platform.drivers.flexcomm.LPC55S28;platform.drivers.lpc_iocon.LPC55S28;platform.drivers.lpc_gpio.LPC55S28;platform.utilities.assert.LPC55S28;utility.debug_console.LPC55S28;component.usart_adapter.LPC55S28;component.serial_manager.LPC55S28;component.lists.LPC55S28;component.serial_manager_uart.LPC55S28;middleware.freertos-kernel.LPC55S28;middleware.freertos-kernel.extension.LPC55S28;platform.drivers.reset.LPC55S28;CMSIS_Include_core_cm.LPC55S28;platform.utilities.misc_utilities.LPC55S28;device.LPC55S28_system.LPC55S28;lpcxpresso55s28_freertos_generic;</sdkComponents>
		<boardId>lpcxpresso55s28</boardId>
		<package>LPC5526JBD64</package>
		<core>cm33</core>
		<coreId>cm33_core0_LPC55S28</coreId>
	</storageModule>

However, although the information is in .cproject  (i.e., <sdkComponents>), SDK Component Manager has lost all track of the components (displays bare metal project, all drivers are unselected, etc.).

Why is this?

[danielholala]

Thanks for working on this issue and providing help.

I tried your workaround and found it to be incomplete. I observed all changes to files for each step by putting the project under revision control.

As a starting point, I'm using the "FreeRTOS generic" example (based on the LPC55S28 MCU).

Immediately after changing the MCU from LPC55S28 to LPC5526, by opening "Manage SDK Components" I see that the component information has been lost.

Closing the project, editing .cproject as you described (copying over the previous <storageModule moduleId="com.nxp.mcuxpresso.core.datamodels"> section), and opening the project again, I see that the correct component information is available in "Manage SDK Components".

However, now the MCU information is incorrect (shows LPC55S28) and I can not properly set the packaging of my MCU (i.e., LPC5526JBD64).

[lpcxpresso_supp]

Hi,

It seems the changes needed to fully switch the device are too complex to be done by hand in the text file. For example, the components listed under the sdkComponents tag are specific to lpc55s28 device. So the IDs listed there have to be also updated.

We need to implement the full change in the product so we’ll keep the above mentioned logged issue to fix the entire problem.

Regards,

MCUXpresso IDE Support

[danielholala]

Hello lpcxpresso_supp,

I've yet to install MCUXpresso 11.6.1, so I wonder whether this issue has been fixed in MCUXpresso 11.6.1? I could not find anything on this issue in the release notes. So I guess, it's not fixed yet.
Thanks.
Best regards,
Dan

Update: Installed MCUXpresso IDE 11.6.1 and the issue persists.

[danielholala]

Update: Installed MCUXpresso IDE 11.7.0 and the issue persists.

[lpcxpresso_supp]

Indeed, problem is not fixed in 11.7.0. We'll reconsider it for the upcoming 11.8.0.

Regards,
MCUXpresso IDE Support

[danielholala]

TLDR: This issue seems to be fixed has improved in 11.8.0 but it is nowhere close to being resolved.

I did a quick test: created a new project for LPC5528 (SDK_2.x_LPC5528, 2.14.0) and made sure it compiles. Then I switched CPU to LPC5526 (SDK_2.x_LPC5526, 2.14.0).

That's what I found:

Indeed, "SDK Manager" retains component information when switching MCU.

However, the project does not compile any more.

First, the "main()" source file contains an include for "LPC5528.h" which needs to be changed to "LPC5526.h" manually.

Then, compiling stops with an error message:

In file included from C:\Users\Daniel\Documents\MCUXpressoIDE_11.8.0_1165\workspace\LPC5528_Project_test2\drivers/fsl_common.h:22,
from ../utilities/fsl_assert.c:10:
C:\Users\Daniel\Documents\MCUXpressoIDE_11.8.0_1165\workspace\LPC5528_Project_test2\device/fsl_device_registers.h:28:2: error: #error "No valid CPU defined!"
28 | #error "No valid CPU defined!"

This is because fsl_device_registers.h complains that neither of

defined(CPU_LPC5526JBD100) || defined(CPU_LPC5526JBD64) || defined(CPU_LPC5526JEV98)

is defined. This define stems from the compiler invocation:

arm-none-eabi-gcc -D__REDLIB__ -DCPU_LPC5528JBD100 -DCPU_LPC5528JBD100_cm33 <remaining text omitted>

This is although Project Explorer shows "LPC5526JBD100" as package. The define on the compiler command line does not change even when I apply "Change Package" using Project Explorer.

That is to say, "Change Package" is also broken.

PS: Lack of clear formatting is due to the limitations imposed by the "edit reply" editor.

[lpcxpresso_supp]

Thank you for your feedback, Daniel. Indeed, what we tried to deliver in 11.8.0 is not more than an improvement. Also, we're currently not planning to invest more time and resources to address such a use case.

Regarding your post, I notice that you shifted to a slightly different use case. You now have two different SDKs that ship everything you need, so you're not forced to use one single SDK that offers board-level support for device A and device-level support for device B. With two "complete" SDKs, I don't see any reason to do a device switch. Anyway, I'll try to add a few words about the behavior you described:

1. SDK components are retained when device is switched - but not in all cases. The IDE does its best to map the components associated to device A, to components for device B. However, depending on the SDK definition, some components might be lost from a tracking perspective (but not deleted from project).

2. The IDE will not change your "main.c". It's user code and the IDE will not touch that file. So it's expected to change a device-specific import in such a file.

3. The IDE does its best to update defines/macros that are device-specific. Again, we're depending on SDK definition and this action might succeed or fail, depending on several factors. I'm not sure how device-specific preprocessor defines are used in the SDKs you referred but I'll take a look.

4. The compiler is invoked using settings specified inside "MCU C Compiler" section of the toolchain. You can manually update settings if you need to.

5. I'll double check "Change Package" functionality on my side. This one has not been changed recently. As a side-note, device-specific defines are coming from SDKs and we might not be in sync with their (possibly new) approach.

I also suggest to take a look at ch. 14.3 from User Guide to learn more about current approach of the "change device" action. 

To conclude, the only issue that needs further investigation is the "change package" action that does not update device-specific preprocessor defines.

Regards,

MCUXpresso IDE Support

[danielholala]

Dear @lpcxpresso_supp ,

Thanks for you long answer and for explaining why things go awry with the "Edit CPU" functionality. I agree, that I'd like to see more "complete" SDKs. As an example, I don't see any reason why LPC5526 is provided in a separate SDK than LPC5528 although these two CPUs are completely identical except for the memory layout. I'm convinced that this exacerbates problems that already exist.

However, I beg to disagree. I did not shift the use case.

First, from a users perspective "Edit MCU" should  just work™ whether both CPUs are in the same SDK or not. The burden to handle haphazard complexity cannot be shifted onto the shoulders of the user. Of course, "Edit MCU" cannot switch between distant CPUs families but at least between close family members (LPC5528 and LPC5526 or even LPC5526 and LPC5536) a switch should be possible.

Second, download LPC5526 SDK and import an example based on LPC55S28. Now switch CPU to LPC5526. With IDE 11.8 the SDK components are now tracked, however, the example project will not compile. This happens although the example goes to great lengths to keep device specific definitions out of the users code. For example it does not include "LPC5528.h" in the main() file. So why does it not compile? As I mentioned in my last posting, the preprocessor macro that defines the processor is set on the command line. Because Neither "Edit CPU" nor "Change Package" touches this, the code has no valid CPU defines.

Third, don't argue with "The IDE will not change your 'main.c'.". I did not add the include for "LPC5528.h" but the New Project wizard did. Why did the New Project wizard do this? I have no idea.  This is up to the decisions made by NXP. As the examples clearly show, it's easy to keep device specific code separate from user's code, e.g., by moving those includes to, e.g., board.h. Again, don't make the users responsible for a complexity that NXP created.

Last, I know that I can manually change settings and includes, linker scripts, memory layout, etc. But that's arduous and error prone. Therefore we have an IDE. An IDE is supposed to make developer's work easier. Therefore, "Edit MCU" function exists, although I don't understand why you offer a functionality that's so obviously broken.

You write "we're currently not planning to invest more time and resources to address such a use case.". What do you mean? What is a use case where "Edit MCU" actually works?

Thanks for listening.

Daniel

[lpcxpresso_supp]

First, I can confirm that device-specific preprocessor defines are not currently updated when changing device package and using SDK 2.14. This is going to be patched in the upcoming IDE v11.8.1.

Strictly speaking about MCU editing feature, its initial design wasn't intended to be used the way it is used today. It was initially requested to allow debugging an existing project, on a different MCU (i.e. a very close derivative). So, no changes to build settings, no changes to SDK components, no changes to source files belonging to project. Incremental requests led to what we have today. If you'll inspect the user guide (ch. 14.3), you'll understand what the IDE is doing now during the device switch and what manual changes would be needed. Thanks for understanding.

Regards,

MCUXpresso IDE Support

[danielholala]

Seems a fix regarding device-specific preprocessor defines has made it into MCUXpresso IDE 11.8.1:

• Fixed: [SDK Integration] Device-specific preprocessor defines are not taken in consideration when changing device package.

I have not yet checked whether it works as expected.

[danielholala]

Hello @lpcxpresso_supp ,

Thank you for responding. I appreciate that.

I'm glad to hear that you are working to improve the "Edit MCU" feature.

It is my understanding that I never used the MCU editing feature for anything else than switching between very close derivatives (aka. MCU family members). It should be very easy to switch between LPC5526 and LPC5528 but still, as I reported, this feature failed me. 

If this feature is difficult to implement for the MCUXpresso team this is partially due to awkward design decisions. For example, if why are LPC5526 and LPC5528 in different SDKs? Why does a new project contain the include for the processor in the main file (the examples do not). etc.

[danielholala]

Thanks. I keep my fingers crossed that this will be fixed in the next release.

At least for switching to a CPU that's compatible but has a different memory layout (e.g., changing the project from LPC5528 to LPC5526), I found a workaround:

I don't use "Edit MCU" but the "Edit Memory" shortcut from the Project Explorer instead:

This way I can edit the memory layout to match the layout of the processor I'd like to compile my project for without destroying the SDK components configuration. This means, I can still use the Peripherals Tools.

Notes:

• As a template I use what "Edit MCU" displays when I switch to the processor (don't forget to uncheck "preserve memory configuration").
• Don't forget to put your Project under revision control first, so you can
  • a) revert the damages that "Edit MCU" does, and
  • b) see how the change of memory configuration is reflected in your project files (e.g,  in .cproject  and Linker files).

[danielholala]

I appreciate your response.

You are correct, the "datamodels" section contains entries that encode the MCU type in their names.

This is from the same SDK, but a new project started for the LPC5526 MCU:

	<storageModule moduleId="com.nxp.mcuxpresso.core.datamodels">
		<sdkName>SDK_2.x_LPC5526</sdkName>
		<sdkVersion>2.11.0</sdkVersion>
		<sdkComponents>middleware.freertos-kernel.extension.LPC5526;CMSIS_Driver_Include.I2C.LPC5526;RTE_Device.LPC5526;CMSIS_Driver_Include.Common.LPC5526;CMSIS_Driver_Include.SPI.LPC5526;middleware.freertos-kernel.template.LPC5526;CMSIS_Driver_Include.USART.LPC5526;middleware.freertos-kernel.LPC5526;platform.drivers.power.LPC5526;platform.drivers.lpc_gpio.LPC5526;platform.drivers.clock.LPC5526;platform.drivers.reset.LPC5526;platform.drivers.flexcomm_usart.LPC5526;platform.drivers.flexcomm_i2c.LPC5526;platform.drivers.common.LPC5526;platform.drivers.flexcomm_spi.LPC5526;platform.drivers.flexcomm.LPC5526;platform.drivers.lpc_iocon.LPC5526;platform.drivers.flexcomm_i2s.LPC5526;platform.drivers.gint.LPC5526;platform.drivers.flexcomm_i2c_freertos.LPC5526;platform.drivers.anactrl.LPC5526;platform.drivers.cmp_1.LPC5526;platform.drivers.ctimer.LPC5526;platform.drivers.flexcomm_i2c_dma.LPC5526;platform.drivers.flexcomm_i2s_dma.LPC5526;platform.drivers.flexcomm_spi_dma.LPC5526;platform.drivers.flexcomm_spi_freertos.LPC5526;platform.drivers.flexcomm_usart_dma.LPC5526;platform.drivers.flexcomm_usart_freertos.LPC5526;platform.drivers.fro_calib.LPC5526;platform.drivers.iap1.LPC5526;platform.drivers.inputmux.LPC5526;platform.drivers.inputmux_connections.LPC5526;platform.drivers.lpadc.LPC5526;platform.drivers.lpc_crc.LPC5526;platform.drivers.lpc_dma.LPC5526;platform.drivers.lpc_rtc.LPC5526;platform.drivers.mrt.LPC5526;platform.drivers.ostimer.LPC5526;platform.drivers.pint.LPC5526;platform.drivers.plu.LPC5526;platform.drivers.rng_1.LPC5526;platform.drivers.sctimer.LPC5526;platform.drivers.sdif.LPC5526;platform.drivers.sysctl.LPC5526;platform.drivers.utick.LPC5526;platform.drivers.wwdt.LPC5526;CMSIS_DSP_Library.LPC5526;CMSIS_DSP_Source.LPC5526;platform.drivers.flexcomm_i2c_cmsis.LPC5526;platform.drivers.flexcomm_spi_cmsis.LPC5526;platform.drivers.flexcomm_usart_cmsis.LPC5526;utility.debug_console.LPC5526;component.serial_manager_uart.LPC5526;component.serial_manager.LPC5526;component.usart_adapter.LPC5526;platform.utilities.misc_utilities.LPC5526;component.lists.LPC5526;device.LPC5526_startup.LPC5526;CMSIS_Include_core_cm.LPC5526;device.LPC5526_CMSIS.LPC5526;device.LPC5526_system.LPC5526;project_template.LPC5526.LPC5526;</sdkComponents>
		<package>LPC5526JBD64</package>
		<core>cm33</core>
		<coreId>cm33_core0_LPC5526</coreId>
	</storageModule>

Hope you get this fixed soon. Keep the updates coming. Thanks.