S32DS Compilation error : fatal error - cygheap base mismatch detected

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

S32DS Compilation error : fatal error - cygheap base mismatch detected

Jump to solution
5,198 Views
LuisCasado
NXP Employee
NXP Employee

Hello,

 

Customer: AED Engineering

SW: S32DS

 

Customer is having compilation error for any application created for S32DS, they have verified that they don't have that issue with private laptops but all the company PC's are getting the error. So probably is due to Windows 10 configuration but they don't know how to solve it.

As soon as they try to buid they get:

 

arm-none-eabi-gcc "@Project_Settings/Startup_Code/startup_S32K142.args" -o "Project_Settings/Startup_Code/startup_S32K142.o" "../Project_Settings/Startup_Code/startup_S32K142.S"

      4 [main] sh (20384) C:\NXP\S32DS_ARM_v2.2\S32DS\build_tools\msys32\usr\bin\sh.exe: *** fatal error - cygheap base mismatch detected - 0x612E5408/0x1045408.

This problem is probably due to using incompatible versions of the cygwin DLL.

Search for cygwin1.dll using the Windows Start->Find/Search facility

and delete all but the most recent version.  The most recent version *should*

reside in x:\cygwin\bin, where 'x' is the drive on which you have

installed the cygwin distribution.  Rebooting is also suggested if you

are unable to find another cygwin DLL.

 

What can be the cause of error?

 

Luis

Tags (3)
0 Kudos
1 Solution
830 Views
GaryRK
NXP Employee
NXP Employee

Thanks winsmen, this is the only workaround that solved the problem on my system. 

This is a recurring issue I face with S32DS 3.5. In the past it seemed to eventually resolve itself after some time (perhaps Windows or antivirus policy updates), however on this occasion I had urgent work to do and I could not force it to function via system shutdown/restart or the autorebase.bat script.

Here is the exact procedure I used:

  1. Open project properties in S32DS.
    • Presently this needs to be done for all projects that are affected (which is anything built in S32DS managed make context).
  2. Expand C/C++ Build and select Environment.
  3. Select the PATH variable and click the Edit... button.
  4. Pre-pend the path to external directory (outside of S32DS installation) containing make.exe, for example I installed a separate instance of msys64 which includes make.exe at the default path of: C:\msys64\usr\bin.GaryRK_0-1701255227446.png
  5. Click OK then Apply and Close.
  6. Attempt to repeat the build or clean operation and it should now work.

I tried to apply this workaround at S32DS workspace level by defining the PATH variable in Window -> Preferences -> C/C++ -> Build -> Environment but this does not work. It only seems to support appending of environment variables to the project-local environment, meaning the non-functional S32DS make.exe will supersede the external instance and be invoked first leading to the error. I will update this thread if I find a way to apply the workaround in a general way.

Best regards,

Gary

 

 

View solution in original post

6 Replies
2,732 Views
winsmen
Contributor II

Posted this on the other thread linked earlier here too.

Managed to get rid of this error by using an externally installed copy of make in place of the one found within the NXP folder.

In the project Properties (File > Properties, or right click on project > Properties) expand C/C++ and go to Environment. Edit (or add) the PATH variable to include the path to the bin folder of your external Make installation at the beginning of the list. This bin folder would be the one containing the make.exe executable. Apply and Close. Rebuild.

831 Views
GaryRK
NXP Employee
NXP Employee

Thanks winsmen, this is the only workaround that solved the problem on my system. 

This is a recurring issue I face with S32DS 3.5. In the past it seemed to eventually resolve itself after some time (perhaps Windows or antivirus policy updates), however on this occasion I had urgent work to do and I could not force it to function via system shutdown/restart or the autorebase.bat script.

Here is the exact procedure I used:

  1. Open project properties in S32DS.
    • Presently this needs to be done for all projects that are affected (which is anything built in S32DS managed make context).
  2. Expand C/C++ Build and select Environment.
  3. Select the PATH variable and click the Edit... button.
  4. Pre-pend the path to external directory (outside of S32DS installation) containing make.exe, for example I installed a separate instance of msys64 which includes make.exe at the default path of: C:\msys64\usr\bin.GaryRK_0-1701255227446.png
  5. Click OK then Apply and Close.
  6. Attempt to repeat the build or clean operation and it should now work.

I tried to apply this workaround at S32DS workspace level by defining the PATH variable in Window -> Preferences -> C/C++ -> Build -> Environment but this does not work. It only seems to support appending of environment variables to the project-local environment, meaning the non-functional S32DS make.exe will supersede the external instance and be invoked first leading to the error. I will update this thread if I find a way to apply the workaround in a general way.

Best regards,

Gary

 

 

5,009 Views
jiri_kral
NXP Employee
NXP Employee

Hi Luis, 

I was facing this issue in past and to be honest - never find general solution. Sometimes helps regular power OFF and ON (no reboot), sometimes helps run autorebase script:

pastedImage_1.png 

And sometimes it just disappear next day. I'll ping S32DS dev team with your issue. May be they already figured it out. 

Jiri

0 Kudos
5,009 Views
LuisCasado
NXP Employee
NXP Employee

Hi Jiri Kral ,

In this case they have tried both and is happening in all the computers at customer.

Luis

0 Kudos
5,009 Views
mikedoidge
NXP Employee
NXP Employee

Hi sito,

It seems this issue has been reported before. Please check the thread: https://community.nxp.com/message/1059626 

Hope it helps,

Mike

0 Kudos
5,009 Views
LuisCasado
NXP Employee
NXP Employee

Hi Mike Doidge ,

I already shared the community doc you mention and it doesn't fix the issue.

Luis

0 Kudos