Wrong memory model in .obj file of library?

MikeH said:

Is there a way to look at the object code to determine if indeed the memory model is 2?

Yes, use ofd55 on the object (or the library) and look for the line which says "Memory Model."  It will spell out the memory model with words.

In the error message:

2 is large memory model

3 is huge memory model.

Is that file an assembly source file?  Are you remembering to compile it with the --memory_model=huge option?

Aha! A dedicated employee....:)

Yes, use ofd55 on the object (or the library) and look for the line which says "Memory Model."  It will spell out the memory model with words.

String Table File Offset: 0x00000fa7
TI-COFF f_flags: 0x00000230
Memory Model: huge
Control Data Endian: little endian

Is that file an assembly source file?

The file (file.obj) is an compiled file from C source.

 Are you remembering to compile it with the --memory_model=huge option?

Yes. I have the entire project set to huge.

I run into the same error when trying to link this huge library from two different application files. Wierd.

MikeH said:

A dedicated employee

I am committed, or should be.

Are you sure the copy of file.obj in library_C5515.lib is the most recent copy? How are you constructing library_C5515.lib?

Are you sure the copy of file.obj in library_C5515.lib is the most recent copy

Yes, its file time stamp shows that it is the same as all other .obj files and they are the most recently built.

 How are you constructing library_C5515.lib?

To construct the .lib

===================================

Library Project->clean

Library Project-> build

To get the error message

===================================

Application Project->clean

Application Project->build.

That doesn't help me much; I'd need to see the console output window.

The OFD output you showed me claims the file is huge model, but the linker claims it is large model.  Clearly that can't be true.  Those two tools use the same code to read object files, so it doesn't seem likely that one is right and one is wrong.  I cannot explain that.

For sanity, please unpack file.obj from library_C5515.lib and run ofd55 on that copy to verify it has the right memory model.

In a fresh directory, unpack file.obj with the command "ar55 x \wherever\library_C5515.lib file.obj"

I seem to have a similar problem that I don't know how to fix... I get the following error message:

fatal error #16004: file "C:\DAQUnit\Utilities\ezdsp5535_v1\lib\ezdsp5535bsl.lib<ezdsp5535_spiflash.obj>"
has a Tag_Memory_Model attribute value of "2" that is different than one
previously seen ("3"); combining incompatible files

Now from what you were saying, i need to use the ofd55.exe to view the object file, however this file appears to be embedded in the ezdsp5535bsl.lib library file, so I don't know how to get access to it?  I managed to get the code to compile and link if I used the memory model "large" and rts55x instead of rts55h...  However I believe that the advice on the ezdsp5535 kit is to go for the huge memory model.

Can you please tell me how I can achieve this?

Regards,

Sean

ofd55 can read the library, and will print results for each component object file, one at a time.

You can also unpack the library using the command "ar55 x ezdsp5535bsl.lib", but be prepared for a lot of files.

Thanks for the prompt reply.  But once I read the library or unpack it, how do I fix the problem? 

Cheers

Sean

We need to identify the source of the problem first.  The solution is to not mix object files with different memory models.  We need to identify why this is happening.

Excuse my ignorance here but I am still not getting a solution to my problem...  I am new to DSP, hence the reason for the development kit, to try and learn more about the c5500 series and get up to speed fairly quickly, to see if we can implement DSP into one of our new potential projects.

I ran the "ar55 x ezdsp5535bsl.lib" in dos prompt on window 7 and got it to spit out all the obj files that are associated to the library file.  This part was fine.... I then ran the "ofd55 ezdsp5535_spiflash" again in the dos prompt and got a stream of information, this i believe you can get outputed into a file some how, but as of yet not been able to get that right.  Assistance on that would be appreciated....

Next once I have the file what do I do with it?  Please keep in mind that this is a whole new environment to me (compiler, language and hardware) so it would be safe not to assume that once you give me the answer I would know what to do with it...

Much appreciated!

Sean 

Sorry, I thought it was clear from the previous discussion.  The error you are getting means you are mixing object files with different memory models, which is forbidden for C55x.  Let's back up a moment and address this comment:

Sean Quilliam said:

 I managed to get the code to compile and link if I used the memory model "large" and rts55x instead of rts55h...  However I believe that the advice on the ezdsp5535 kit is to go for the huge memory model.

If it works compiled as large model, there's no need to change to huge model.  Libraries are compiled for one model or another; if you want to change to huge model, you'll have to get a different version of ezdsp5535bsl.lib, or recompile it yourself.  If I were you, I'd leave it as large model until your data gets too big to fit in large model.

Assuming you want to switch to huge model, and you think your library and all of your files are compiled for huge model, but the linker disagrees, then we need to use ofd55.  ofd55 will help us determine which file is large model and which file is huge model.  ofd55 outputs a file header for each input file. In part, this header looks like:

    File Name:                 hello.obj                
    [..]            
    Memory Model:              large

or

    File Name:                 hello.obj                
    [..]            
    Memory Model:              huge

This is how you know which file is large model and which is huge model. You're best off looking at the ofd55 dump for the whole archive, because (in strange cases) multiple files with same name may be in the archive, and extracting the entire archive will overwrite some input files.

You can capture the output of a command into a file with the ">" redirection operator:

C:\> ofd55 file.obj > file.txt

Sean Quilliam said:

I then ran the "ofd55 ezdsp5535_spiflash" again in the dos prompt and got a stream of information, this i believe you can get outputed into a file some how, but as of yet not been able to get that right.

Try to avoid keeping ofd55 output.  Filter it instead.  Here is an example ...

You can do that on a library too.  Just change "file.obj" to the name of the library.  That can create lots of output.  You can capture it to a file by putting "> log.txt" at the end of the command.  Change log.txt to whatever file name you like.

The whole game is get everybody to agree on what the memory model is.  My guess is this library only comes in large memory model, and you are presently building with huge memory model.  If that is right, then you need to change your build to use large memory model.

Thanks and regards,

-George

No need  to  apologize, trust me it is me and my ignorance with CCS V5 and the C5500 series that is the problem here.  The reason for my original question was that I could not get things to link because there was a ptrdiff problem during linking.  I surfed the net many hours to try and figure this one out and by pure chance got things to work when I changed from the huge to the large memory model.  I then since have found new problems and in trying to solve this found that all I needed to do to solve my original ptrdiff problem was go into the compile settings and choose the run time model options in CCS for ptr size from 16 to 32 and wallah all my problems should have disappeared, but instead I adopted this new problem, where the memory models were conflicting.  The thing that confuses me is that I am using the library functions that come with the ezdsp5535 kit and in the code that I am writing I am using the OLED library, the SD library the SPI_Flash library, but it is only the SPI_Flash that is giving me the problems when I go from large to huge, all the other libraries compile and generate obj files OK??? In the documentation that I have read it appears that I should be using the Huge memory model, hence my reason for trying to change it back to huge....

In all honesty I have no idea what the difference is between the two (Large and Huge) and don't even know when I will need to change from one to the other?  Is there any way that I can see how much memory is left??? I am use to the micro-controller way of life.  You get  so much memory and once it is up it is up!  There is no option to change from large to huge... If you don't mind what is the difference when you select large to huge?   I cant imagine that you all of a sudden get an extra few megabytes out of fresh air, I assume it is..... Hell I have no idea.... Please enlighten me....

As for my original inquiry I am happy to change my memory model back from huge to large, and if I do run out will then worry about it another time...  Is there anyway one can see how much memory is left over?

Once again many thanks for your support in this steep learning curve of DSP and memory management....

Cheers

Sean    

Memory models are documented in section 6.1 Memory in the C55x compiler manual.  

The documentation for the libraries you are using should indicate which memory model they use.  

Sean Quilliam said:

Is there anyway one can see how much memory is left over?

This information is contained in the linker map file.  The map file has the same name and directory as the final executable .out file, but the extension is changed to .map.  It is an ordinary text file.

Thanks and regards,

-George

Hello,

I have the same Problem.

I use C5535, CCS5 and the new DSPLIB 3.00.

After a partial rebuild of twiddle32 this message was shown in CCS:

                               fatal error #16004: file "C:/Program Files (x86)/TI/ccsv5/tools/compiler/c5500/lib/55xdspx.lib<twiddle32.obj>" has a

                               Tag_Memory_Model attribute value of "1" that is different than one

                               previously seen ("2"); combining incompatible files

How can I change the memory model in this case?

This means the library 55xdspx.lib is built with small memory model, and some other module the linker saw earlier on the command line is built with large memory model.  The some other module is probably from your source code.  The choices you have are ...

• Use the large memory model version of 55xdspx.lib, if it is available.
• Rebuild 55xdspx.lib for large memory mode, if the accompanying documentation describes how to do that.
• Build your own code for small memory model.  The risk is everything may not fit in small memory model.

Thanks and regards,

-George

Hello,

I understand what is the reason for this message. I think, the only way for me is to rebuild the 55xdspx.lib.

I would do that with the partial rebuild.

I will use a self generated 8192 Point twiddle table, so there is no existing Version available.

How can I do that?

I haven't found a solution for the Problem, but I have rebuild it with the Batch file Blt55xx_r3.bat.

The fft is now working with the 8192 Point twiddle table. All files are now memory model large