--- In 6..., "Eric Engler" wrote:
>
> --- In 6..., "sburgin13" wrote:
>
> > Here's my problem: I compile a program and look at the .s19/.s29
> > file, it does not give the startup address of my program.
>
> This will work fine. My first option I gave you was to use the
> bootloader and overwrite D-BUG12. This gives you less convenience
than
> the serial monitor, but it should work fine. The
serial monitor is
> most useful to assembly language programmers because you can use it
to
> set breakpoints, single-step, and stuff like that
(using my Pluto
> debugger). The Serial Monitor is less useful to C programmers
because
> I don't have a source level debugger for C. You
could use the gdb
> debugger but that's a commandline tool that has a steep learning
curve.
>
> You can follow Wytec's instructions to write your program to flash
> using the bootloader once you prepare your program properly and
> compile it.
>
> The help file explains how to determine your starting address by
> looking at the dump file. Look at help topic "Determine the Start
> Address of your program". You don't particularly need to know the
> specific address since you can just reference the label "_start".
This
> will equate to the beginning of your text segment.
>
> The start address is the location where program execution begins.
The
> reset vector must be programmed to contain that
address.
>
> Several of my example projects have a file called "vectors.s". This
is
> an assembly language table of vectors. You could use
either C or
> assembly language to make a table of vectors - I just normally use
> assembler for that. You can add one of these to your project (just
> grab one of those files and put it in your folder and then add it to
> the project with the menu).
>
> The reset vector will have the symbol "_start" and it looks like
this:
> .word _start ; fffe (reset)
>
> That will pick up the true starting address of your program and put
it
> in the reset vector. The specific value is normally
the starting
> address of your text segment. Disregard my comment that has the
> address of the reset vector - your address will be determined based
on
> the needs of the bootloader.
>
> The entire vector table has this label to identify the memory
section:
>
> .sect .vectors
>
> And the profile specifes where "vectors" is to be located in memory.
> This is where you would put 0xEf80. This will be used to create the
> linker script named "memory.x".
>
> EGNU creates both the makefile and memory.x and it performs the
make.
> Then you'll need to D/L your program to flash
memory using the
bootloader.
>
> You shouldn't need to hand edit either the makefile or memory.x, but
> if you do decide to change them, EGNU will not overwrite your
changes.
> Sometimes people have unique requirements so I let
you tweak these
if
> you really need to. The GNU tools use only those 2
files and your
> source code files.
>
> Eric
>
Thank you SO much. I'm not saying that was the solution yet, but I
compiled here and noticed the start address in the .s19 file. I
added the vectors.s file and edited for the second vector table. I
am going home at lunch and trying it out.
Booting from Flash m9s12dg256
Started by ●April 18, 2008
Reply by ●April 23, 20082008-04-23
Reply by ●April 24, 20082008-04-24
--- In 6..., "Eric Engler" wrote:
>
> --- In 6..., "sburgin13" wrote:
>
> > Here's my problem: I compile a program and look at the .s19/.s29
> > file, it does not give the startup address of my program.
>
> This will work fine. My first option I gave you was to use the
> bootloader and overwrite D-BUG12. This gives you less convenience
than
> the serial monitor, but it should work fine. The serial monitor is
> most useful to assembly language programmers because you can use it
to
> set breakpoints, single-step, and stuff like that (using my Pluto
> debugger). The Serial Monitor is less useful to C programmers
because
> I don't have a source level debugger for C. You could use the gdb
> debugger but that's a commandline tool that has a steep learning
curve.
>
> You can follow Wytec's instructions to write your program to flash
> using the bootloader once you prepare your program properly and
> compile it.
>
> The help file explains how to determine your starting address by
> looking at the dump file. Look at help topic "Determine the Start
> Address of your program". You don't particularly need to know the
> specific address since you can just reference the label "_start".
This
> will equate to the beginning of your text segment.
>
> The start address is the location where program execution begins.
The
> reset vector must be programmed to contain that address.
>
> Several of my example projects have a file called "vectors.s". This
is
> an assembly language table of vectors. You could use either C or
> assembly language to make a table of vectors - I just normally use
> assembler for that. You can add one of these to your project (just
> grab one of those files and put it in your folder and then add it to
> the project with the menu).
>
> The reset vector will have the symbol "_start" and it looks like
this:
> .word _start ; fffe (reset)
>
> That will pick up the true starting address of your program and put
it
> in the reset vector. The specific value is normally the starting
> address of your text segment. Disregard my comment that has the
> address of the reset vector - your address will be determined based
on
> the needs of the bootloader.
>
> The entire vector table has this label to identify the memory
section:
>
> .sect .vectors
>
> And the profile specifes where "vectors" is to be located in memory.
> This is where you would put 0xEf80. This will be used to create the
> linker script named "memory.x".
>
> EGNU creates both the makefile and memory.x and it performs the
make.
> Then you'll need to D/L your program to flash memory using the
bootloader.
>
> You shouldn't need to hand edit either the makefile or memory.x, but
> if you do decide to change them, EGNU will not overwrite your
changes.
> Sometimes people have unique requirements so I let you tweak these
if
> you really need to. The GNU tools use only those 2 files and your
> source code files.
>
> Eric
>
Ok, so that works. Now when I load my program, I can't communicate
with the SCI1 port. It works in Debug. I thought this might be the
PLL setup, so I went back to debug and looked at the registers for
the PLL as they ran under Debug12. I set the registers up the same
and still nothing. Any suggestions about this?
>
> --- In 6..., "sburgin13" wrote:
>
> > Here's my problem: I compile a program and look at the .s19/.s29
> > file, it does not give the startup address of my program.
>
> This will work fine. My first option I gave you was to use the
> bootloader and overwrite D-BUG12. This gives you less convenience
than
> the serial monitor, but it should work fine. The serial monitor is
> most useful to assembly language programmers because you can use it
to
> set breakpoints, single-step, and stuff like that (using my Pluto
> debugger). The Serial Monitor is less useful to C programmers
because
> I don't have a source level debugger for C. You could use the gdb
> debugger but that's a commandline tool that has a steep learning
curve.
>
> You can follow Wytec's instructions to write your program to flash
> using the bootloader once you prepare your program properly and
> compile it.
>
> The help file explains how to determine your starting address by
> looking at the dump file. Look at help topic "Determine the Start
> Address of your program". You don't particularly need to know the
> specific address since you can just reference the label "_start".
This
> will equate to the beginning of your text segment.
>
> The start address is the location where program execution begins.
The
> reset vector must be programmed to contain that address.
>
> Several of my example projects have a file called "vectors.s". This
is
> an assembly language table of vectors. You could use either C or
> assembly language to make a table of vectors - I just normally use
> assembler for that. You can add one of these to your project (just
> grab one of those files and put it in your folder and then add it to
> the project with the menu).
>
> The reset vector will have the symbol "_start" and it looks like
this:
> .word _start ; fffe (reset)
>
> That will pick up the true starting address of your program and put
it
> in the reset vector. The specific value is normally the starting
> address of your text segment. Disregard my comment that has the
> address of the reset vector - your address will be determined based
on
> the needs of the bootloader.
>
> The entire vector table has this label to identify the memory
section:
>
> .sect .vectors
>
> And the profile specifes where "vectors" is to be located in memory.
> This is where you would put 0xEf80. This will be used to create the
> linker script named "memory.x".
>
> EGNU creates both the makefile and memory.x and it performs the
make.
> Then you'll need to D/L your program to flash memory using the
bootloader.
>
> You shouldn't need to hand edit either the makefile or memory.x, but
> if you do decide to change them, EGNU will not overwrite your
changes.
> Sometimes people have unique requirements so I let you tweak these
if
> you really need to. The GNU tools use only those 2 files and your
> source code files.
>
> Eric
>
Ok, so that works. Now when I load my program, I can't communicate
with the SCI1 port. It works in Debug. I thought this might be the
PLL setup, so I went back to debug and looked at the registers for
the PLL as they ran under Debug12. I set the registers up the same
and still nothing. Any suggestions about this?
Reply by ●April 24, 20082008-04-24
> PLL setup, so I went back to debug and looked at the
registers for
> the PLL as they ran under Debug12. I set the registers up the same
> and still nothing. Any suggestions about this?
>
You should look at the sample code on Erics web site and set up the
PLL with that code.
There is PLL code there.
> the PLL as they ran under Debug12. I set the registers up the same
> and still nothing. Any suggestions about this?
>
You should look at the sample code on Erics web site and set up the
PLL with that code.
There is PLL code there.
Reply by ●April 24, 20082008-04-24
--- In 6..., "smith.jeff28" wrote:
> > PLL setup, so I went back to debug and looked at the registers for
> > the PLL as they ran under Debug12. I set the registers up the same
> > and still nothing. Any suggestions about this?
> > You should look at the sample code on Erics web site and set up the
> PLL with that code.
> There is PLL code there.
>
See the EGNU help topic about the C32 processor. You need the custom
startup code that is used for the C32 demo project - it's in an
assembler module under the lib\src folder. But you have to check on
the RAM mapping code in the startup file - you should probably comment
that out for the processor you are using. You also need to ensure if
the SP location needs to be the same.
> > PLL setup, so I went back to debug and looked at the registers for
> > the PLL as they ran under Debug12. I set the registers up the same
> > and still nothing. Any suggestions about this?
> > You should look at the sample code on Erics web site and set up the
> PLL with that code.
> There is PLL code there.
>
See the EGNU help topic about the C32 processor. You need the custom
startup code that is used for the C32 demo project - it's in an
assembler module under the lib\src folder. But you have to check on
the RAM mapping code in the startup file - you should probably comment
that out for the processor you are using. You also need to ensure if
the SP location needs to be the same.
