__rom_copy_info; where do I get more info on that??

[MPC5554_Newbee]

Hello,

I am new to the Codewarrior development suite and have had some problems to understand it. But here is one that seems to be a very fundamental and simple issue that anybody would come across at the beginning of the embedded software development.

I need to store my initialized data (.data) in flash rom and copy it upon startup from rom to ram where it will be accessed and used. I started developing the link command file (lcf)but can not find any info on how to do that!! I came accross the following items,
without any detailed description:
BIND, which is a lcf command doing what??
LOAD, which seems to be another lcf command doing something...
__rom_copy_info *dci

I know that "void __init_data(void)" which comes with Codewarrior does exactly what I need,
but I do not know how to generate the information that __init_data needs.

Any help or suggestions where to find more info will be greatly appreciated!!

Alwin

[CrasyCat]

Hello

Basically to get the linker to generate information to copy initialization value from ROM to RAM at startup, you need to generate a ROM image.

The attached technical note provides you some information on how to configure your .lcf file to get an appropriate ROM image, depending in you have 1 or several read only memory areas defined in your .lcf file.

I hope this helps.

CrasyCat

[nithinramakrish]

Hello Catherine,

     Could you kindly attach the pdf document again? I have similar issue and would like to refer the document.

I hope you still have the document after all this years.

Best Regards,

Nithin

[MPC5554_Newbee]

Hello CrasyCat,

your hint (and PDF especially) was worth gold, or at least quite a bunch of hair I did not have to pull :smileywink:

I am quite disappointed though, that my searches on the Freescale web site did not bring that one up! It should also be part of the regular distribution when you by the product. The help files that came with my MPC5554 compiler (which is a build only) version did not go in any of those details!

My follow up questions now is: If I want to run the compiler and linker from the command
line (without using the IDE) where would I find a nifty document that explains all the special command line options??

Thanks in advance!

Alwin

[CrasyCat]

Hello

The technical note has been forwarded to the CodeWarrior product team and should be part of future distribution.

If you are starting the tools from the command line, you can use the same .lcf file. You have to specify the ROM Image address using the option -romaddr when starting the linker.

There is also an option -rambuffer to specify the RAM buffer address (I do not think you need it though).

Only place I found a description of the needed linker options is

     {Install}\PowerPC_EABI_Tools\Command_Line_Tools\mwldeppc.txt.

I know it is not obvious. I will drop them a note to improve that in future release of the documentation.

Catherine

[MPC5554_Newbee]

Thanks a bunch Catherine,

I found some more info regarding command line options in the ...Help/PDF files.

One thing I would strongly recommend for future releases would be the ability to generate the command line compile & link commands from within the IDE, which would show all the options that are enabled/disabled within the "Target Settings Panel".

Better yet, an option to automatically generate a "makefile" would allow migration to command line driven setups much less of a headache!

Thanks for your help,

Alwin

[CrasyCat]

Hello

I am dreaming about something like that since a while for CodeWarrior EPPC.

Unfortunately it does not look this is going to happen in a near future

CrasyCat

[Velocirex]

This is a helpful document, thanks. It speaks to the same problem as my previous post to this list regarding rom->ram relocation. It recommends two things for running from flash:

1. use #pragma switch_tables off

As described, the default compiler/linker behavior is to locate the jump table in ram requiring a rom->ram relocation. This pragma works because it causes the compiler to implement the switch statement as a series of if/elses with all code in rom. However, this represents a performance hit and sidesteps the issue so is not ideal IMO. From reviewing my own application, it appears that the reason the default switch tables do not work is that the rom->ram relocation misplaces the jump table addresses. To be precise, the rom image of the .data section where they are placed is mislocated and the ensuing rom->ram relocation merely duplicates the problem in ram.

2. make sure all constants are located in rom

Yes, this works, but again sidesteps the issue IMO. In the case of an initialized string like this:

printf("Hello World\n");

the default location of the string "Hello World" is in the data section unless the 'make strings readonly' box is checked in the project settings dialog. When unchecked and running from rom, the string is relocated to ram by the __init_data function. In my test case, the string also falls victim to the rom->ram relocation issue and what comes out of the printf is "o World". The basic problem is that the starting address for the rom copy of the .data section is off by 4 bytes so it "misses" the "Hell" part of the string. Its the same problem that prevents the normal switch statement code to fail. Why doesn't this work properly?

If I prepare a modified version of the copy_rom function I can relocate the .data function elements to ram properly so that both the normal switch statement code and the initialized strings are copied properly. It seems to work on simple applications but I can't be certain that the relocation issue is completely repeatable.

FWIW, there is a support request in the system on this issue.

[Velocirex]

one more tidbit.

As an academic test case, if the .data section is directed to be in rom vs ram in the linker script, the .data section is located properly in the rom image, i.e. no 4 byte offset. Naturally this is academic since you can't do too much with a read-only data section but it might be a clue to the problem.