Happy Friday!

I'm working with this processor: http://www.a-2.com/Datasheets/A2P3_base_datasheet_NIS.pdf I don't have a lot of data on the processor, but I'm working on it. I'm using these tools: http://www.adveda.com/ I have a user's manual, but it's at work and I can't link to it now.

Anyway, the guy who had this project before me (whereabouts unknown) had some kind of magic way of forcing variables into the exact memory addresses he wanted. The data memory is a 32KB sram mapped to starting address 0x1c000. The linker script has variable space (.bss) mapped to 0x20500. However, when I compile my program, the variables are mapped as such:

var1 => 0x21514
var2 => 0x21518
etc...

At first, I thought the software was ignoring the linker script, but after contemplating over massive amounts of beer, I decided the compiler was complying with the linker script, because the variables are indeed stored within the .bss space. So, I summize that the compiler doesn't necessarily start variable storage at the beginning of the .bss space. But as I said, the guy before me make his variables go straight into the beginning of the space. I don't have the juju, so I get a work-around thusly:

#define var1 (*(unsigned int *)(&0x20500))
#define var2 (*(unsigned int *)(&0x20504))
etc.

This seems to work well enough, but still I'd like to be able to restore the software to its former glory. Also, his declarations look like this:

unsigned var1;
unsigned var2;
...
extern unsigned var1;
extern usninged var2;
...

And he has some kind of magic linker that assigns the correct address, but I don't have any idea how to do this. I'm at a loss, does anyone have a suggestion?

 

Have you looked inside the linker script?

 

http://wiki.osdev.org/Linker_Scripts Scroll down to the MEMORY section.

 

Here is how I would do it:

unsigned short var1 @ 0x20500;

 

Here is how I would do it:

unsigned short var1 @ 0x20500;

Never saw notation like that. I'll try it out, but I have to wait till Monday.

 

Or try;
unsigned short var1 absolute 0x20500;

Your compiler should have a help file that lists keywords by alphabetical order, you can check that (or search) for keyword "absolute".

 

Have you looked inside the linker script?

As I wrote in the OP, the linker script denotes the variable storage space as starting at 0x20500, but my vairables start at 0x21514. While searching for a solution, I found out that there is some way to specify exact addresses in the linker script for variables declared as "extern." But I haven't been able to find an example. Also, is it true that linker scripts each have their own syntax? So, even if a find an good example, that doesn't mean it will work for my tool chain, right?

 

As I wrote in the OP, the linker script denotes the variable storage space as starting at 0x20500, but my vairables start at 0x21514. While searching for a solution, I found out that there is some way to specify exact addresses in the linker script for variables declared as "extern." But I haven't been able to find an example. Also, is it true that linker scripts each have their own syntax? So, even if a find an good example, that doesn't mean it will work for my tool chain, right?

I don't know. I have EE degree. I do not have CS degree. It just seemed obvious to me that if you are trying to specify a bunch of options/rules for your linker to follow, you would do it in the linker script.

You said you have the tools manual at work. I would check it for syntax and "stuff". Maybe even contact the company that made the tools and see what help they can give you. To me this topic falls under product support and if that company is any good, they should be able to help you.

 

I don't know. I have EE degree. I do not have CS degree.

Same problem here. I only need to program the processor for design verification. In the verification tools, the processor communicates with the HDL code through address specific 'registers' which have to be programmed in the firmware. The path to accomplish this seems to be specific to the tool chain, at least according to what I've discovered so far.

 

Problem solved!!! Thanks for all the suggestions. I knew that the guy before me had some kind of magic to make the addresses come out the way he wanted. Over the weekend, I did some reading and learned that the symbol table would be found in the .map file. So this morning, I looked it up, and it turns out the that variable addresses from another source file were defined at the start of the .bss section before the variables I was looking for, which displaced my variables in the address space. After seeing what file the variables were defined in, I began to realize that when I set up the project, I changed the compile order of the sources, thinking it wouldn't matter. Well, I guess the linker grabs variables from files in the order that they are specified in the project file. Changing the order back to what it was originally restored all the addresses to their correct values. Damn, that was a bug-a-boo of a problem.

 

Nice to hear you found a solution.

Does the @ address declaration work with your toolchain?

 

Thanks, Mr Chips. Sorry, I didn't try it. My first priority this morning was to figure why this worked before and wasn't working after I took it over.

 

BTW, because there were variables already defined at those addresses, my work-around from the OP wasn't going to work. I'd would have stomped on those variables.

eg:

#define var1 (*(unsigned int *)(&0x20500))
#define var2 (*(unsigned int *)(&0x20504))

 

Does the @ address declaration work with your toolchain?

This caused a compiler error. So did using "unsigned int var absolute 0x20500"