- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The address of Ram varables may change between builds. Can you tell us what is the address used for?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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??
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.