Booting from Flash m9s12dg256

I'm having major dificulties understanding how to get my c program to
run upon boot up. I know the address of where the program starts
needs to be at the reset vector interrupt, but how do I program this?
What are the steps I would need to take to change my program and load
it into flash?
Start a New Thread

--- In 6..., "sburgin13" wrote:
>
> I'm having major dificulties understanding how to get my c program to
> run upon boot up. I know the address of where the program starts
> needs to be at the reset vector interrupt, but how do I program this?
> What are the steps I would need to take to change my program and load
> it into flash?
>

Which compiler and which board are you using? Do you have a BDM device?
Start a New Thread

--- In 6..., "Eric Engler" wrote:
>
> --- In 6..., "sburgin13" wrote:
> >
> > I'm having major dificulties understanding how to get my c
program to
> > run upon boot up. I know the address of where the program starts
> > needs to be at the reset vector interrupt, but how do I program
this?
> > What are the steps I would need to take to change my program and
load
> > it into flash?
> > Which compiler and which board are you using? Do you have a BDM
device?
>

I'm using a Dragon12 Plus board with Embedded GNU 1.10. I have
assembly files that I can load and have boot on startup, but I'm not
sure of the settings for the c or the GNU. I looked at the profile
options where you can set the data, text, i/o, eeprom, vector and
stack. I thought that it the vector would be pointing to the
secondary vector table located at EF8C, and the start address would
be put there via the compiler. The startup address is supposed to go
into EFFE and EFFF. Any thoughts?
Start a New Thread

--- 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
Start a New Thread

--- 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.
Start a New Thread

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.
Start a New Thread

--- 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.
Start a New Thread

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.

Start a New Thread

--- 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
Start a New Thread

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.

Start a New Thread