linker script problem? [solved]

Development Boards MicroMod
1

Hi,

I tested the basicGnu example (from at91.com) and other code to run on my SAM7-EX256 (AT91SAM7X256). i designed my makefile according to the basicgnu example (see below). i adapted the linker script only in 2 lines which specify the flash/ram size of the X256.

I can compile and flash, but the code seems not to be running.

I checked the NVM bits, they are OK.

I made a copy of the original code which has been running.

if i reflash this, it’s running (flasing procedure and nvm bit settings therefore be ok).

A hint could be the following funny behaviour:

if i flash the original binary, check if it runs (it does), compile my code and flash it without erase of the flash, than the original code keeps running (i can see this, as the original code prints something on the lcd, mine not).

seems that my code gets flashed anywhere, in such a way that it can not corrupt the original bin.

could this be a problem with the linker script?

sorry for the files, but the server always responds :

Not Acceptable

An appropriate representation of the requested resource /cgi-bin/phpbb/posting.php could not be found on this server.

if i paste them here.

Is there a posibility to attatch files?

Alex

p.s.: i tried to register at at91.com using 3 different email adresses, but none of the activationkey’ arrived since hours. is this usual?

2

Hi Alex,

what program do you use to write to flash? SAM-BA? Or the OpenOCD? Remember that the OpenOCD requires plain binaries (objcopy -O binary), which is what you get when you just use OpenOCD’s “dump_binary” command, but not the default for many GNU examples I’ve seen (they produce SREC or Intel HEX or whatever).

Regarding the “funny behaviour”:

How large is the original program, and how large is your program? Maybe the part that’s running is behind the part that gets overwritten?

Regards,

Dominic

3

hi dominic,

i use --output-target=binary with objcopy, should therefore be no problem…

i can’t tell you anything about the size of the original binary. i just copied that from flash do disc. it therefore is 256k large.

i tested the make process of the cross compilation tutorial. it works.

i’m now step by step testing switching my options in order to find out where the problem is.

i’ll report on success

thx

alex

4

hey, this ‘not acceptabel’ error makes me sick!

i can’t post my linker call here :frowning:

a part of the actual problem seems to be about the linkin sequence.

i had crt.o at the end, but needs to be linked in first position. (i guess the linking sequence determins the position in flash and crt holds some lowlevel init stuff).

more to follow

5

Hi Alex.

I wrote the original tutorial “Using Open Source Tools for AT91SAM7 Cross Development” on the www.at91.com web site.

I submitted a major revision to Atmel a week ago that utilizes Michael Fischer’s YAGARTO package and demonstrates how to use Dominic Rath’s OpenOCD to program the flash memory, allbeit for the AT91SAM7S256 chip. So far they haven’t responded to the submission but I’m sure they’d have no objection to me trying to help you.

If you would like to see a sneak peek at this tutorial draft, download it from the following link:

http://www.megaupload.com/?d=XEMG0ZTP

Be advised that megaupload.com is not exactly family-friendly and you may see some racy advertisements pop-up.

I know you’re using a slightly different Atmel chip, but maybe this new tutorial will provide some illumination.

Cheers,

Jim Lynch

6

Hi Jim,

thanks for the link, I will have a look at it.

next result: I used the -Os option of gcc. this seems to disturb things…

7

hi

some of the options and the device initialisation code coming with the basignu example seem to be off-key (at least for my setup).

I changed my options and adapted the lowlevelinit provided by Jim Lynch ( thx!). Now everything is working.

you can find my makefile at

www.tec-sol.org/hpprogs/kickarm.html

download

(this is just a kick link to prevent the use of ~)

I will include some documentation in the next days…

Alex