MCF51JM128, CW 10.2 with include of stdlib causes compile errors

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

MCF51JM128, CW 10.2 with include of stdlib causes compile errors

1,052 Views
Cdn_aye
Senior Contributor I

Hi

 

I needed to use atoi in the code so added the usual #include <stdlib.h> in the code. Now I get these bizarre errors

 

Description Resource Path Location Type  identifier 'exit(int)' was originally declared as '__regabi int (int)' rap11_cw10.2_mqx3.7_51jm128  line 89, external location: C:\Freescale\Freescale MQX 3.8\lib\m51jmevb.cw10\usb\host\mqx_host.h C/C++ Problem identifier 'exit(int)' redeclared as '__regabi void (int)' rap11_cw10.2_mqx3.7_51jm128  line 157, external location: C:\Freescale\CW MCU v10.2\MCU\ColdFire_Support\ewl\EWL_C\include\cstdlib C/C++ Problem mingw32-make: *** [Sources/Tasks_c.obj] Error 1 rap11_cw10.2_mqx3.7_51jm128    C/C++ Problem

 

After searching through the net and everywhere Icould think, I noted that someone found that there is some pragma statement somewhere that changes the register used for return values in a function call. I have no idea where that is or how to change it.

 

Does anyone have a fix for this? This seems pretty basic functionality and we shouldn't have to go through this to compile normal code. This is an existing project that has been used for sometime but without the include.


Thanks in advance.

Labels (1)
0 Kudos
5 Replies

537 Views
BlackNight
NXP Employee
NXP Employee

Hello,

this one looks more like an MQX problem, so maybe the moderator needs to move this discussions to the right forum.

 

As a workaround:

you might simply add what you need as declaration to you your source files where you use atoi():

 

 

int atoi (const char*);

 

and compile with this.

 

Hope this helps,

BK

0 Kudos

537 Views
Cdn_aye
Senior Contributor I

Thank you BlackNight

 

I think you could be right about MQX, we are using MQX 3.8.0 with the K20.... patches. But I tried the declaration as you suggested but without the include we don't get the linkage.

 

So I then even added the source for the atoi from K & R. We are getting the correct calculation for the string to integer withinit the function, but the wrong value passed back upon return. So I think the registers are messed up.

 

I should add we are using Win 7, x 64, SP1. So I am in the process of installing on XP on an older machine to see if this is a processor/compiler issue. What a pain.... I have seen the Win 7 compiler not up to standard before and have found errors in the load files; there is not thorough testing on the Win 7 x64 systems from what I have seen. Usually the XP x32 systems work. But this is a lot of work to go through for what is supposed to be a production ready product, ie CW10.2.

 

Thanks for replying.

0 Kudos

537 Views
BlackNight
NXP Employee
NXP Employee

Your problem does not sound like a host OS (Win7 vs XP) problem. I doubt that using XP will make a difference.

What is specific to Win7 (as well Vista) is (depending on the settings) files in the c:\program files folder protected.

So if you have installed CodeWarrior or MQX into the default program folder, that might cause all sorts of problems.

That's why always install things inside my own folder outside program files (e.g. c:\freescale).

 

About atoi() itself: yes, looks like this is indeed a register/parameter passing problem.

I suggest that you file a service request in any case so someone from the support team could have a look at your issue.

 

BK

0 Kudos

537 Views
Cdn_aye
Senior Contributor I

BlackNight

I forgot to mention, that you are correct about the install directory. We learned that quickly when 10.0 came out. You can't use the standard program directory because of protection priviledges. We used the usual C:\Freescale\CW MCU v10.2\

 

That works but the pragma that is messing up the libraries remains to be found....

0 Kudos

537 Views
Cdn_aye
Senior Contributor I

I agree this is probably not an OS problem but there are differences in the compilers for the different OS's. We found early releases of WIn 7 x64 cw10.1 systems that produced incorrect s19 flles. This was verified by support.

 

As to using support, that is a 2 week to 1 month process and often with no success. There is a backlog and we have had requests in the queue for weeks now with no resolution. Usually we change the design or solve them ourselves and they just atrophy naturally. In the last few months something has changed within the FSL support group. My guess is that they have added amajor customer and support has definitely seriously gone down hill for the horde of the great unwashed... me at least. I have been working with Motorola and then FSL support since 1999.

 

The CW10.2 update on XP just crashed with a 'missing artifact' whatever that is.

 

Without a compiler this is going to be a hard road to go down.

0 Kudos