SDK 2.12.0 Component Refresh problem

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SDK 2.12.0 Component Refresh problem

Jump to solution
765 Views
mrd
Contributor III

I have a c++ project for RT1176 using MCUExpresso 11.6 for development. Uses FreeRTOS with heap_4. Installed SDK 2.12.0 and performed "Refresh SDK Components". After Clean and Build, found that the application would get MemManager fault when attempted to allocate memory pool or instance an object. After some investigation, discovered the file startup_mimxrt1176_cm7.c (which is the 'c' start-up file) was put in the project's startup folder The startup folder already contained startup_mimxrt1176_cm7.cpp for a c++ project. See below, but it looks like the autogenerated ../Debug/startup/subdir.mk builds both startup_mimxrt1176_cm7.cpp and .c, but builds the .c version last, which means the 'cpp' version's .d obj file is overwritten by the 'c' verison. There are no build errors or warnings. The firmware starts up, but fails when it attempts to allocate memory off the heap for a memory pool or task. [Memory allocation for some things such as queues are okay for some reason.]

Is this adding startup_mimxrt1176_cm7.c to the startup folder a bug? Or, is there something I should do to prevent this from happening during future SDK updates? Note that I've been through updates of 2.9.x, 2.10.x, and 2.11.x prior to updating to SDK 2.12.0. Previously did not have a problem with startup_mimxrt1176_cm7.c being added to the startup folder. Let me know if this should be posted to a different board.  Thank you.

Excerpt from ...\Debug\startup\subdir.mk showing that both startup_mimxrt1176_cm7.cpp and .c are built.

################################################################################
# Automatically-generated file. Do not edit!
################################################################################

# Add inputs and outputs from these tool invocations to the build variables
CPP_SRCS += \
../startup/startup_mimxrt1176_cm7.cpp

C_SRCS += \
../startup/boot_multicore_slave.c \
../startup/startup_mimxrt1176_cm7.c <= This overwrites the .c++ version's startup file.

CPP_DEPS += \
./startup/startup_mimxrt1176_cm7.d

C_DEPS += \
./startup/boot_multicore_slave.d \
./startup/startup_mimxrt1176_cm7.d

OBJS += \
./startup/boot_multicore_slave.o \
./startup/startup_mimxrt1176_cm7.o

 

0 Kudos
1 Solution
744 Views
mrd
Contributor III

I think you follow me correctly.  I have a C++ project.  After updating to SDK 2.12.0 and doing "Refresh SDK Components", the startup_mimxrt1176_cm7.c file was put in the startup folder.  Just via its presence, it becomes part of the project and takes priority over startup_mimxrt1176_cm7.cpp that was already in the startup folder.  MemoryManager faults then occur when run the code.

Removing the unwanted startup_mimxrt1176_cm7.c from the start-up folder and rebuilding fixes the problem.

I did not have this problem when updated to previous SDK versions.

This occurred on a mature C++ project that was started months ago via the MCUXpresso wizard.  I have not gone back to test what happens on one of the demo C++ projects (of which I think there are only 1 or 2) in the SDK. 

Let me know if this doesn't clear things up for you.

Thank you.

View solution in original post

0 Kudos
4 Replies
749 Views
jeremyzhou
NXP Employee
NXP Employee

Hi @mrd ,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
To be honest, I'm not very clear on the issue, whether you mean the C++ demo project was good when works with the SDK 2.9.x, 2.10.x, or 2.11.x, however, the startup folder will exist the startup_mimxrt1176_cm7.c after updating the SDK to 2.12.0, is my understanding right?
If yes, can the issue be eliminated after removing this file?
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
745 Views
mrd
Contributor III

I think you follow me correctly.  I have a C++ project.  After updating to SDK 2.12.0 and doing "Refresh SDK Components", the startup_mimxrt1176_cm7.c file was put in the startup folder.  Just via its presence, it becomes part of the project and takes priority over startup_mimxrt1176_cm7.cpp that was already in the startup folder.  MemoryManager faults then occur when run the code.

Removing the unwanted startup_mimxrt1176_cm7.c from the start-up folder and rebuilding fixes the problem.

I did not have this problem when updated to previous SDK versions.

This occurred on a mature C++ project that was started months ago via the MCUXpresso wizard.  I have not gone back to test what happens on one of the demo C++ projects (of which I think there are only 1 or 2) in the SDK. 

Let me know if this doesn't clear things up for you.

Thank you.

0 Kudos
740 Views
jeremyzhou
NXP Employee
NXP Employee

Hi @mrd ,
Thanks for your reply.
I'd like to suggest you try another way of updating the SDK library, delete the previous SDK library at first, then download the updated SDK library and install it to MCUXpresso IDE, I think it can avoid the component refresh problem.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
738 Views
mrd
Contributor III

I don't think suggestion agrees with the 11.6.0 MCUXpresso IDE Users Manual section 4.2.3 "Obtaining and Installing an SDK via SDK Builder", but I will try it next time.  It looks like when I drag the 2.12.0 zip file to the SDK window, the  2.11.1 is automatically deleted.  I.e., 2.11.1 was not available at the time of component refresh.  

Unless you are trying to tell me I'm updating to the new SDK incorrectly, I think behavior has changed...there is a bug.

0 Kudos