You are here

Missing Information in map file | Cypress Semiconductor

Missing Information in map file

Summary: 5 Replies, Latest post by hli on 23 May 2014 05:01 AM PDT
Verified Answers: 0
Last post
Log in to post new comments.
ado's picture
23 posts

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.



user_1377889's picture
9284 posts

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?



user_460349's picture
1362 posts

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

ado's picture
23 posts



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:


(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


@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


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.



user_1377889's picture
9284 posts


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



PS: Are you located in Germany? Where??

user_78878863's picture
2553 posts

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.

Log in to post new comments.