--- 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.

--- 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..., "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.

Eric is correct that this method will not allow for any "C" debugging,
other than your own devices (i.e. flash a led etc).

If you do load SerMon, you also have the option of using NOICE for "C"
debugging or code warrior debugger, as both support sermon.

--- 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

Gee, I'm sorry but I use codewarrior.

You can down load a free version that is good up to 32k, or perhaps
Eric will come back and explain this.

Here is a link, you will need to create an account:

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=CW-HCS12X

The also have a forum, and you cold try your GNU question there.

--- In 6..., "smith.jeff28"
wrote:
>
> You can use the boot loader to flash your program, and the set the
dip
> switches to boot into your program.
> The bootloader will protect itself when you erase and flash.
>
> There are certain places you must put your vectors. I think the
> bootloader may auto relocate them as does SerMon but I don't recall
> for sure. Hunt down AN3275.pdf on the freescale site - this explains
> the bootloader. Waynes is customized, but it will follow this
> specification.
>
> Here is the link:
>
http://www.freescale.com/files/microcontrollers/doc/app_note/AN3275.pd
f?fsrch=1
>
> This is all explained in the Wytec docs available from evbplus dot
com.
> You can also email them if you still can't figure things out.
>
> If you do not mess up the bootloader, you can also re flash DBUG-12
> using the bootloader.
>
> No matter how much you mess things up, you can always fix it with a
BDM.
> However, as I said the bootloader will not over write itself, so
have
> at it.
>

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. I input
the vector address of 0xEf80 into the profile and change the data to
a flash address and compile. I was reading that I need to use the
linker option -defsym vector_addr=0xEF80, but where do I put this? I
believe this is the reason that it doesn't work. I'm not actually
getting the vector address correct, thus my start address never gets
loaded.

You can use the boot loader to flash your program, and the set the dip
switches to boot into your program.
The bootloader will protect itself when you erase and flash.

There are certain places you must put your vectors. I think the
bootloader may auto relocate them as does SerMon but I don't recall
for sure. Hunt down AN3275.pdf on the freescale site - this explains
the bootloader. Waynes is customized, but it will follow this
specification.

Here is the link:
http://www.freescale.com/files/microcontrollers/doc/app_note/AN3275.pdf?fsrch=1

This is all explained in the Wytec docs available from evbplus dot com.
You can also email them if you still can't figure things out.

If you do not mess up the bootloader, you can also re flash DBUG-12
using the bootloader.

No matter how much you mess things up, you can always fix it with a BDM.
However, as I said the bootloader will not over write itself, so have
at it.

--- In 6..., "Eric Engler" wrote:
>
> --- In 6..., "sburgin13" wrote:
>
> > I'm using a Dragon12 Plus board with Embedded GNU 1.10.
>
> It is not possible to store your program in flash memory unless you
> overwrite the d-bug12 monitor. D-bug12 is only used for RAM program
> development. As you know, RAM contents are lost when the power goes
away.
>
> In order to program the flash, you have several options:
>
> 1) use the bootloader to store your program in flash. This clobbers
> d-bug12, but so do the other options.
>
> 2) use a BDM device, or another Dragon12 board operating in the pod
mode
>
> 3) use method 2 above to replace BOTH the bootloader and D-Bug12
with
> the Serial Monitor. The SerMon lets you store your user program in
> flash without the use of a BDM.
>
> Some Dragon12 users in schools pair up so they can hook up two
boards,
> one acting as a BDM device using the pod mode. Then that board
> reprograms the other board by replacing the D-bug12 monitor with the
> Serial Monitor. The SerMon does let you download programs to flash
to
> be run upon powerup.
>
> But I don't see how the other board could then be reporgrammed,
since
> the SerMon can not operate as a BDM. So at least one board has to
stay
> unmodified. That's a good idea, anyway, since that one can restore
> d-bug12 on the others.
>
> The easiest choice would be for your instructor to reprogram all the
> student boards with the SerMon. I do NOT advise you to attempt this
> yourself without help from someone with a lot more experience. If
you
> mess this up your board may become a paperweight.
>
> Eric
>
I guess I misunderstood that I could load my program via the
bootloader that comes on the chip. I thought there is a way via code
to reprogram the start address to look at my program after I erase
debug12. When started in boot loader, I have the options to erase
flash, load flash, erase eeprom. If I erase the flash (which erases
debug12) then load it with my program, I would assume,if coded
correctly, the dragon12 should restart with my program. I just don't
know where I'm going wrong with my start address. I'm not sure if
EGNU is loading the vector table address EF80, or if it hangs at the
default. Everything I read sounds like I set it in memory.x and the
compiler will do the rest.