Forums

TMS320F2812 serial code load

Started by Geoffrey Mortimer September 20, 2005
Hi Everyone

We are using Code Composer c2x with an EZDSP card, debugging via the JTAG
interface.

We are working on a project in which the target has no JTAG interface, and
so we're trying to load executable code into the 2812 using the serial
interface. The code is first obtained from the COFF file as an s-record
using the Texas HexConv, then this is converted by our own (very simple)
utility into a file compatible with the boot loader. Everything works until
we try to load and run code which contains initialized global variables.

Using the JTAG debugger to examine memory after loading the code, we see
that in the case in which the serial bootloader is used to load and run the
code, no initialization takes place. If the code is loaded via JTAG, the
variables are initialized _before the code is executed_ (to verify this we
power cycle the system before executing the load command from the file menu,
then examine memory).

So it seems that no run-time initialization code is being generated, and
that the debugger is directly initializing memory before the code is run.
This is strange because the linker option for run-time autoinitialization is
selected.

Anyone have any idea what we are doing wrong?

MTIA
Geoff

gmortimer
snail
ferrari
point
it


Geoffrey Mortimer wrote:
> Hi Everyone > > We are using Code Composer c2x with an EZDSP card, debugging via the JTAG > interface. > > We are working on a project in which the target has no JTAG interface, and > so we're trying to load executable code into the 2812 using the serial > interface. The code is first obtained from the COFF file as an s-record > using the Texas HexConv, then this is converted by our own (very simple) > utility into a file compatible with the boot loader. Everything works until > we try to load and run code which contains initialized global variables. > > Using the JTAG debugger to examine memory after loading the code, we see > that in the case in which the serial bootloader is used to load and run the > code, no initialization takes place. If the code is loaded via JTAG, the > variables are initialized _before the code is executed_ (to verify this we > power cycle the system before executing the load command from the file menu, > then examine memory). > > So it seems that no run-time initialization code is being generated, and > that the debugger is directly initializing memory before the code is run. > This is strange because the linker option for run-time autoinitialization is > selected. > > Anyone have any idea what we are doing wrong? > > MTIA > Geoff > > gmortimer > snail > ferrari > point > it > >
Are you using SD Flash? I believe there is some kind of bug where only code/data linked to PAGE 0 gets loaded. Typically PAGE 0 is used as your program space so I wouldn't be surprised that you would have put your variables in PAGE 1. However, if you're using SD Flash you'll need to put them in PAGE 0. Brad
"Brad Griffis" <bradgriffis@hotmail.com> wrote in message
news:ZYWdneI5fqBDarLeRVn-3A@comcast.com...
> Geoffrey Mortimer wrote: > > Hi Everyone > > > > We are using Code Composer c2x with an EZDSP card, debugging via the
JTAG
> > interface. > > > > We are working on a project in which the target has no JTAG interface,
and
> > so we're trying to load executable code into the 2812 using the serial > > interface. The code is first obtained from the COFF file as an s-record > > using the Texas HexConv, then this is converted by our own (very simple) > > utility into a file compatible with the boot loader. Everything works
until
> > we try to load and run code which contains initialized global variables. > > > > Using the JTAG debugger to examine memory after loading the code, we see > > that in the case in which the serial bootloader is used to load and run
the
> > code, no initialization takes place. If the code is loaded via JTAG, the > > variables are initialized _before the code is executed_ (to verify this
we
> > power cycle the system before executing the load command from the file
menu,
> > then examine memory). > > > > So it seems that no run-time initialization code is being generated, and > > that the debugger is directly initializing memory before the code is
run.
> > This is strange because the linker option for run-time
autoinitialization is
> > selected. > > > > Anyone have any idea what we are doing wrong? > > > > MTIA > > Geoff > > > > gmortimer > > snail > > ferrari > > point > > it > > > > > > Are you using SD Flash? I believe there is some kind of bug where only > code/data linked to PAGE 0 gets loaded. Typically PAGE 0 is used as > your program space so I wouldn't be surprised that you would have put > your variables in PAGE 1. However, if you're using SD Flash you'll need > to put them in PAGE 0. > > Brad
Hi Brad, thanks for the answer, and the previous one. We have a copy of SD Flash, but we're not using it at the moment, instead we're using the HexConv utility to create an S-record file which we then convert to binary in bootloader format with our own utility. Of note is that the S-record is a single, contiguous block. We have not mapped any initialised variables into Page 1.
Geoffrey Mortimer wrote:
> "Brad Griffis" <bradgriffis@hotmail.com> wrote in message > news:ZYWdneI5fqBDarLeRVn-3A@comcast.com... > >>Geoffrey Mortimer wrote: >> >>>Hi Everyone >>> >>>We are using Code Composer c2x with an EZDSP card, debugging via the > > JTAG > >>>interface. >>> >>>We are working on a project in which the target has no JTAG interface, > > and > >>>so we're trying to load executable code into the 2812 using the serial >>>interface. The code is first obtained from the COFF file as an s-record >>>using the Texas HexConv, then this is converted by our own (very simple) >>>utility into a file compatible with the boot loader. Everything works > > until > >>>we try to load and run code which contains initialized global variables. >>> >>>Using the JTAG debugger to examine memory after loading the code, we see >>>that in the case in which the serial bootloader is used to load and run > > the > >>>code, no initialization takes place. If the code is loaded via JTAG, the >>>variables are initialized _before the code is executed_ (to verify this > > we > >>>power cycle the system before executing the load command from the file > > menu, > >>>then examine memory). >>> >>>So it seems that no run-time initialization code is being generated, and >>>that the debugger is directly initializing memory before the code is > > run. > >>>This is strange because the linker option for run-time > > autoinitialization is > >>>selected. >>> >>>Anyone have any idea what we are doing wrong? >>> >>>MTIA >>>Geoff >>> >>>gmortimer >>>snail >>>ferrari >>>point >>>it >>> >>> >> >>Are you using SD Flash? I believe there is some kind of bug where only >>code/data linked to PAGE 0 gets loaded. Typically PAGE 0 is used as >>your program space so I wouldn't be surprised that you would have put >>your variables in PAGE 1. However, if you're using SD Flash you'll need >>to put them in PAGE 0. >> >>Brad > > > Hi Brad, thanks for the answer, and the previous one. > > We have a copy of SD Flash, but we're not using it at the moment, instead > we're using the HexConv utility to create an S-record file which we then > convert to binary in bootloader format with our own utility. Of note is that > the S-record is a single, contiguous block. > > We have not mapped any initialised variables into Page 1. > > > >
If you're not getting the proper initialization behavior when using the debugger you better step back to there until you get that issue resolved. If your initialization values are not in the .out file then it's definitely not going to end up in your binary bootloader file. Make sure your project options are set to generate a .map file. Then take a look and see where the .cinit section is and how big it is. If it's not generating a .cinit section then make sure you've placed it appropriately in the linker command file. After loading your program through the emulator the program counter should be set to the start of _c_int00. If you look in memory at this time you should see your variables unitialized and then after doing Debug -> Go Main you should see them all initialized. Until you can get that working then don't bother with the hex conversion and all that business. Brad