Missing Information in map file

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

In our current project we need the addresses of variables in SRAM as chosen by the compiler.

   

As we use both PSoC 3 and PSoC 5LP we use compiler-dependent script to extract this information from the map

   

file either in Keil or in GCC format.

   

Now it seems that with PSoC Creator 3 and its move to GCC 4.73 this information is gone.

   

I have not found a command line option difference that could explain it.

   

For example, with PSoC Creator 2.0 and gcc 4.41 I find the following in the map file:

   

.bss           0x1fff82d6        0x1 .\CortexM3\ARM_GCC_441\Debug\PowerConverter.a(USBFS_1.o)
                0x1fff82d6                USBFS_1_initVar

   

 

   

This tells me that the address of the variable named "USBFS_1_initVar" is at address 0x1fff82d6 in the SRAM (which starts at 0x1fff8000). 

   

This information is missing in the map file when building with PSoC Creator 3.0.

   

I wonder whether this is due to a change of the GNU tools or a difference in the linker control file.

   

I have compared two linker control files, and there were so many differences that I cannot identify whether one of them relates to the details of the map file.

   

 

   

Andreas

0 Likes
5 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Fixing the address of variables is the job of the linker, not the compiler.

   

I can find my variables in the .map file when I use the search-function of creator. Are yoi sure that your var is not optimized out?

   

 

   

Bob

0 Likes
Anonymous
Not applicable

 The address of Ram varables may change between builds. Can you tell us what is the address used for?

0 Likes
Anonymous
Not applicable

@Bob

   

 

   

Sure, the addresses are set by the linker and the map file is created by the linker, too.

   

That's why I thought an entry in the link control file might control which details end in the map file.

   

I gave the version number of the compiler because it ends up in the path name.

   

Typically, for gcc compiler and linker come together.

   

I still can find the variable in the new map file with its size (so the information the linker collects

   

before doing its job), but not where it ends afterwards:

   

e.g.

   

(variable name, size, source)

   

pmbus_address       0x1               .\CortexM3\ARM_GCC_473\Debug\pmbus_master_hilvl.o

   

But this is now the only entry.

   

Before I also could find a line such as

   

COMMON         0x1fff8358      0x120 .\CortexM3\ARM_GCC_441\Debug\pmbus_master_hilvl.o
                0x1fff8358                pmbus_vin
                0x1fff835c                pmbus_address

   

 

   

in a part of the map file towards the end that starts with

   

".bss"

   

@H L

   

I do not like to tell why I need that for, but if it helps: 

   

We use a "Remote Direct Memory Access" (RDMA) protocol over USB, 

   

which has three functions, read, write and remote-procedure-call (RPC).

   

It is pretty compact 200 lines or so, the largest part is the case statement of the

   

RPC.

   

It allows us to mix many functions into one end-point pair and expanding the protocol as needed.

   

The functions used for RPC do not take parameters or return results, but use variables for this.

   

So I use the write function to fill the variables for the parametes, then call the function, and then read out the results.

   

Therefore, the host code (written in Python) needs to know the addresses of the variables.

   

Since, as you correctly say, the addresses change from one build to the next, the very first thing the host does is finding out the version of the firmware. For this we have one fixed variable (on PSoC5LP I need to use a linker segment) from which the build date and time can be found.

   

My python host code analyzes the map file and finds all the symbols it needs.

   

And this last step is broken now because the addresses after linking are not found anymore in the map file.

   

 

   

Andreas

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

@Andreas

   

In my map-file I can find for a variable residing in RAM on a PSoC4 (32K flash, 4K sram) with sram starting at 0x20000000

   

   

   

   

*(.data .data.* .gnu.linkonce.d.*)

   

.data 0x200000cc 0x1 .\CortexM0\ARM_GCC_473\Debug\Heater.o

0x200000cc HeaterDisabled

*fill* 0x200000cd 0x3 00

   

   

showing that the var "HeaterEnabled" is one byte in length and that its address is 0x200000cc

   

I used the standard settings for debug build configuration

   

 

   

Bob

   

PS: Are you located in Germany? Where??

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

As Bob already noted, it might be the case that the variables get optimized by the compiler (e.g. moved to a register). Then they have no address.

0 Likes