SDK 2.12.0 Component Refresh problem

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

SDK 2.12.0 Component Refresh problem

ソリューションへジャンプ
788件の閲覧回数
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 件の賞賛
1 解決策
767件の閲覧回数
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 件の賞賛
4 返答(返信)
772件の閲覧回数
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 件の賞賛
768件の閲覧回数
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 件の賞賛
763件の閲覧回数
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 件の賞賛
761件の閲覧回数
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 件の賞賛