EmbeddedRelated.com
Forums

using SAM-BA to program flash

Started by Ryan December 27, 2007
Well I have given up on the ARM-USB-OCD. I think its defective. So
now I am trying to use SAM-BA to program my AT91SAM7S64-EK and I still
cant get my code to execute. Here is what I am doing.

I send my code to the start of available RAM, 0x202000. I checked the
size of my .hex file before I sent it and I entered the size in bytes
for the number of bytes to send. I can read it back and it matches.

Then I go into the .map file to get the address of _start which is
0x2020D4 and send the tcl command

TCL_Go $target(handle) 0x2020D4

and all I get back is {}, and my code doesn't run. At this point if I
read back the memory its all empty which I am assuming means I have
lost SAM-BA. Am I missing something?
--- Ryan wrote:

> ...
>
> I send my code to the start of available RAM,
> 0x202000. I checked the
> size of my .hex file before I sent it and I entered
> the size in bytes
> for the number of bytes to send. I can read it back
> and it matches.
>

I am not sure how you are creating the HEX file. There
are formats called hex that are not at all what you
want. You need a straight binary file with no headers,
checksums or anything else. Just a pure binary image
of your executable. SAM-BA will place that in flash at
the location that you specify. It is also important
that your program is linked to begin executing at the
address to which you load it. Could one of these
things be the problem ?

AW
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
yup... I load my code at 0x202000 but _start is not until 0x2020D4...
I have sent it both ihex and bin files but neither of them worked. I
guess I want the bin file huh.

--- In A..., Alexander Whiplash
wrote:
> --- Ryan wrote:
>
> > ...
> >
> > I send my code to the start of available RAM,
> > 0x202000. I checked the
> > size of my .hex file before I sent it and I entered
> > the size in bytes
> > for the number of bytes to send. I can read it back
> > and it matches.
> > I am not sure how you are creating the HEX file. There
> are formats called hex that are not at all what you
> want. You need a straight binary file with no headers,
> checksums or anything else. Just a pure binary image
> of your executable. SAM-BA will place that in flash at
> the location that you specify. It is also important
> that your program is linked to begin executing at the
> address to which you load it. Could one of these
> things be the problem ?
>
> AW
>
____________________________________________________________________________________
> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
> hi
> this is rohith.s i am doing project on porting linux to arm
> core and writing device driver to the target previously i am
> searching the software now i got software(arm gnu tool chain)
> from yagarto so eclipse is the ide what i am using it is nice
> any body using that because i am getting error when i am
> building .....
> so can you help in this matter the error is
>
> **** Build of configuration Debug for project r1 ****
>
> make all
> 'Building target: r1.exe'
> 'Invoking: GCC C Linker'
> gcc -o"r1.exe" ./lowlevel.o ./main.o
> 'gcc' is not recognized as an internal or external command,
> operable program or batch file.
> make: *** [r1.exe] Error 1
>
> please reply me i am scraching my head but it is not getting
> and also i have one doubt whether the kernel compilation can
> be done in this ide (eclipse 3.3 ide ).....
>
>
> waitig for your reply hlp me the same........
>

I fear you may be some way of having the knowledge to build or boot Linux.
Here are some notes:

+ Linux requires an MMU and lots of flash and RAM. Consider uCLinux
instead.
+ Don't try to do this from scratch, find a build that is already
configured.
+ The error is simply that the directory in which GCC is located is not in
the PATH environment of your host computer.
+ It does not look like you have configured the project to use the correct
GCC anyway - I would expect to see something line arm-elf-gcc being called,
not just GCC.
Regards,
Richard.

+ http://www.FreeRTOS.org
14 official architecture ports, 5000 downloads per month.

+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.



hi
this is rohith.s i am doing project on porting linux to arm core and writing device driver to the target previously i am searching the software now i got software(arm gnu tool chain) from yagarto so eclipse is the ide what i am using it is nice any body using that because i am getting error when i am building .....
so can you help in this matter the error is

**** Build of configuration Debug for project r1 ****

make all
'Building target: r1.exe'
'Invoking: GCC C Linker'
gcc -o"r1.exe" ./lowlevel.o ./main.o
'gcc' is not recognized as an internal or external command,
operable program or batch file.
make: *** [r1.exe] Error 1

please reply me i am scraching my head but it is not getting and also i have one doubt whether the kernel compilation can be done in this ide (eclipse 3.3 ide ).....
waitig for your reply hlp me the same........
regards rohith
----- Original Message ----
From: Ryan
To: A...
Sent: Friday, December 28, 2007 10:44:45 AM
Subject: [AT91SAM] Re: using SAM-BA to program flash

yup... I load my code at 0x202000 but _start is not until 0x2020D4...

I have sent it both ihex and bin files but neither of them worked. I

guess I want the bin file huh.

--- In AT91SAM@yahoogroups .com, Alexander Whiplash

wrote:

>

>

> --- Ryan wrote:

>

> > ...

> >

> > I send my code to the start of available RAM,

> > 0x202000. I checked the

> > size of my .hex file before I sent it and I entered

> > the size in bytes

> > for the number of bytes to send. I can read it back

> > and it matches.

> >

>

> I am not sure how you are creating the HEX file. There

> are formats called hex that are not at all what you

> want. You need a straight binary file with no headers,

> checksums or anything else. Just a pure binary image

> of your executable. SAM-BA will place that in flash at

> the location that you specify. It is also important

> that your program is linked to begin executing at the

> address to which you load it. Could one of these

> things be the problem ?

>

> AW

>

>

>

____________ _________ _________ _________ _________ _________ _

> Be a better friend, newshound, and

> know-it-all with Yahoo! Mobile. Try it now.

http://mobile. yahoo.com/ ;_ylt=Ahu06i62sR 8HDtDypao8Wcj9tA cJ

>







____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
ya the mistake is arm-elf-gcc i should give at compile and linker option but by default it is gcc so i got the error i traced out thanks for the kind reply

----- Original Message ----
From: FreeRTOS.org Info
To: A...
Sent: Friday, December 28, 2007 5:28:42 PM
Subject: RE: [AT91SAM] Re: using SAM-BA to program flash

> hi

> this is rohith.s i am doing project on porting linux to arm

> core and writing device driver to the target previously i am

> searching the software now i got software(arm gnu tool chain)

> from yagarto so eclipse is the ide what i am using it is nice

> any body using that because i am getting error when i am

> building .....

> so can you help in this matter the error is

>

> **** Build of configuration Debug for project r1 ****

>

> make all

> 'Building target: r1.exe'

> 'Invoking: GCC C Linker'

> gcc -o"r1.exe" ./lowlevel.o ./main.o

> 'gcc' is not recognized as an internal or external command,

> operable program or batch file.

> make: *** [r1.exe] Error 1

>

> please reply me i am scraching my head but it is not getting

> and also i have one doubt whether the kernel compilation can

> be done in this ide (eclipse 3.3 ide ).....

>

>

> waitig for your reply hlp me the same........

>

I fear you may be some way of having the knowledge to build or boot Linux.

Here are some notes:

+ Linux requires an MMU and lots of flash and RAM. Consider uCLinux

instead.

+ Don't try to do this from scratch, find a build that is already

configured.

+ The error is simply that the directory in which GCC is located is not in

the PATH environment of your host computer.

+ It does not look like you have configured the project to use the correct

GCC anyway - I would expect to see something line arm-elf-gcc being called,

not just GCC.

Regards,

Richard.

+ http://www.FreeRTOS .org

14 official architecture ports, 5000 downloads per month.

+ http://www.SafeRTOS .com

Certified by T as meeting the requirements for safety related systems.







____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
My thread got hijacked...

> SAM-BA will place that in flash at
> the location that you specify.

I am not using flash, I am sticking it in RAM.

> It is also important that your program is linked to begin executing
> at the address to which you load it.

What do you mean by that? Here is a chunk of my linker script:

MEMORY
{
stack : ORIGIN = 0x202000+56k-1k, LENGTH = 1k
heap : ORIGIN = 0x202000+56k-1k-4k, LENGTH = 4k
freeram : ORIGIN = 0x202000, LENGTH = 56k-4k-1k
}

Here is a piece of my map file:

.text 0x00202000 0x17c
*(.text .stub .text.* .gnu.linkonce.t.*)
.text 0x00202000 0x17c
C:\DOCUME~1\Ryan\LOCALS~1\Temp/cciMbaaa.o
0x0020200c init_irq_stack
0x002020b8 remap
0x002020d4 _start
0x00202014 enter_supervisor_mode
0x0020202c enter_irq_mode
0x00202044 toggle
0x00202000 irq_stack_top

So I was under the impression that the start of my program was _start
at 0x002020D4. So in SAM-BA I am sending the program to SRAM at
address 0x202000 and I am starting execution with the command

TCL_Go $target(handle) 0x2020D4

Is there something wrong with my addresses? That still seems right to me.
--- In A..., "Ryan" wrote:
>
> yup... I load my code at 0x202000 but _start is not until 0x2020D4...
> I have sent it both ihex and bin files but neither of them worked. I
> guess I want the bin file huh.
>
> --- In A..., Alexander Whiplash
> wrote:
> >
> >
> > --- Ryan wrote:
> >
> > > ...
> > >
> > > I send my code to the start of available RAM,
> > > 0x202000. I checked the
> > > size of my .hex file before I sent it and I entered
> > > the size in bytes
> > > for the number of bytes to send. I can read it back
> > > and it matches.
> > >
> >
> > I am not sure how you are creating the HEX file. There
> > are formats called hex that are not at all what you
> > want. You need a straight binary file with no headers,
> > checksums or anything else. Just a pure binary image
> > of your executable. SAM-BA will place that in flash at
> > the location that you specify. It is also important
> > that your program is linked to begin executing at the
> > address to which you load it. Could one of these
> > things be the problem ?
> >
> > AW
> >
> >
> >
>
____________________________________________________________________________________
> > Be a better friend, newshound, and
> > know-it-all with Yahoo! Mobile. Try it now.
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
Ryan,

If you use objdump -S to create an assembler listing from the .elf
file produced by the program compile, what the first part of the
listing looks like.

Typically, there is a small startup routine that gets attached to the
program. Most of these startup routines are designed to have code
offset 0 be the first thing executed. Offset 0 is the location of the
reset vector on the ARM core.

By bypassing some of this startup, you could likely be missing some
required setup for the execution state - specifically setting up the
stack. I believe this is likely as the symbol init_irq_stack comes
before the _start symbol.

John

--- In A..., "Ryan" wrote:
>
> My thread got hijacked...
>
> > SAM-BA will place that in flash at
> > the location that you specify.
>
> I am not using flash, I am sticking it in RAM.
>
> > It is also important that your program is linked to begin executing
> > at the address to which you load it.
>
> What do you mean by that? Here is a chunk of my linker script:
>
> MEMORY
> {
> stack : ORIGIN = 0x202000+56k-1k, LENGTH = 1k
> heap : ORIGIN = 0x202000+56k-1k-4k, LENGTH = 4k
> freeram : ORIGIN = 0x202000, LENGTH = 56k-4k-1k
> }
>
> Here is a piece of my map file:
>
> .text 0x00202000 0x17c
> *(.text .stub .text.* .gnu.linkonce.t.*)
> .text 0x00202000 0x17c
> C:\DOCUME~1\Ryan\LOCALS~1\Temp/cciMbaaa.o
> 0x0020200c init_irq_stack
> 0x002020b8 remap
> 0x002020d4 _start
> 0x00202014 enter_supervisor_mode
> 0x0020202c enter_irq_mode
> 0x00202044 toggle
> 0x00202000 irq_stack_top
>
> So I was under the impression that the start of my program was _start
> at 0x002020D4. So in SAM-BA I am sending the program to SRAM at
> address 0x202000 and I am starting execution with the command
>
> TCL_Go $target(handle) 0x2020D4
>
> Is there something wrong with my addresses? That still seems right
to me.
> --- In A..., "Ryan" wrote:
> >
> > yup... I load my code at 0x202000 but _start is not until 0x2020D4...
> > I have sent it both ihex and bin files but neither of them worked. I
> > guess I want the bin file huh.
> >
> > --- In A..., Alexander Whiplash
> > wrote:
> > >
> > >
> > > --- Ryan wrote:
> > >
> > > > ...
> > > >
> > > > I send my code to the start of available RAM,
> > > > 0x202000. I checked the
> > > > size of my .hex file before I sent it and I entered
> > > > the size in bytes
> > > > for the number of bytes to send. I can read it back
> > > > and it matches.
> > > >
> > >
> > > I am not sure how you are creating the HEX file. There
> > > are formats called hex that are not at all what you
> > > want. You need a straight binary file with no headers,
> > > checksums or anything else. Just a pure binary image
> > > of your executable. SAM-BA will place that in flash at
> > > the location that you specify. It is also important
> > > that your program is linked to begin executing at the
> > > address to which you load it. Could one of these
> > > things be the problem ?
> > >
> > > AW
> > >
> > >
> > >
> ____________________________________________________________________________________
> > > Be a better friend, newshound, and
> > > know-it-all with Yahoo! Mobile. Try it now.
> > http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
> > >
>
--- Ryan wrote:

> yup... I load my code at 0x202000 but _start is not
> until 0x2020D4...
> I have sent it both ihex and bin files but neither
> of them worked. I
> guess I want the bin file huh.

Yes, you want the bin file. Hopefully it is really a
binary image of flash and not just a binary file with
some proprietary data embedded in it.

The program will begin execution at the first location
in the vector table, which must be linked at the
beginning of your code. The first 4 bytes of the
vector table are almost always a jump over the rest of
the vector table, to some startup code. That startup
code will be setting stack pointers, clearing some
parts of RAM, copying initialized data, and so on.

AW
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
--- Ryan wrote:
>
> Here is a piece of my map file:
>
> .text 0x00202000 0x17c
> *(.text .stub .text.* .gnu.linkonce.t.*)
> .text 0x00202000 0x17c
> C:\DOCUME~1\Ryan\LOCALS~1\Temp/cciMbaaa.o
> 0x0020200c
> init_irq_stack
> 0x002020b8 remap
> 0x002020d4 _start
> 0x00202014
> enter_supervisor_mode
> 0x0020202c
> enter_irq_mode
> 0x00202044 toggle
> 0x00202000
> irq_stack_top
>
> So I was under the impression that the start of my
> program was _start
> at 0x002020D4. So in SAM-BA I am sending the
> program to SRAM at
> address 0x202000 and I am starting execution with
> the command
>
> TCL_Go $target(handle) 0x2020D4

Running from RAM, got it. All that we discussed
earlier is still relevant.

Sorry that I cannot give you expert help with GNU for
ARM as I am using IAR. But in any case, I am
suspicious that you do not have a segment for vector
table. Also, there is code with names suggestive of
startup code at addresses below _start, so I think
that you need to actually begin execution before
_start. _start is probably just setting up the
environment for running your specific C program. The
startup code that you need to execute before that sets
up the CPU at a lower level. There is often an
assembler file, maybe crt0.s, that has this kind of
startup code. Look through your source for code that
sets up the IRQ and C stacks and sets the processor
mode, and maybe some other stuff. I'll bet that it
calls or jumps to _start after doing that setup. That
is the code that you need to jump to, not _start.

AW
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ