very true... thanks for chewing up my post and forgeting the first line in
it...
the reasoning behind having the loader in ram is then any action on the
flash that fails can be caught and worked around. having both in ram and
flash adds redudancy, and allows for programmer upgrades, though it does
leave the possibility of the loader failing durring a loader reprogramming
and leaving the device in a useless state.
A second way of adding the redudancy required is to have the loader in two
places in flash... allowing one to run while the other is modified.
Honestly, i don't know how to make the device choose which one to use...
i'ld like to point out that i only have used the larger devices, and have
no experience with the smaller ones.
i'll leave the topic for people with more experence though...
thanks
Matthew
On Wed, 10 Sep 2003, Chris Liechti wrote:
> Matthew Peters wrote:
> > A ram loader would be quite simple to make, realy... the main question on
> > how to go about making one is will it ever reprogram itself.
> > If it will, you have to write an extra bit to copy the code to ram, and
> > execute from there.
>
> yes, with all its drawbacks... what happens if the reprogramming fails?
> you end up with an erased flash.
>
> there may be options to avoid that but it involves a litte effort:
> place a simple serial protocol handler, the ram flash loader and code
> for interrupt vector redirection in the topmost segments. it has to be
> the topmost segments as you cant erase the interrupt vectors while
> having the security that it can always recover even if flashing is
> interrupted.
> i'd make a table with the interrupt handlers addresses in a specific
> location in flash. e.g. righ below the fixed loader. that way the table
> is programmed with the rest of the software, the application.
>
> on startup, that fixed code listens on the serial port if it receives
> the reprogramming command. if it does not, it continues with the address
> in the redirected int vectors table. otherwise it starts the
> reprogramming subprogram.
> you can also consider that it automaticaly enters the reprogramming
> subprogram when the redirecten ints table is not valid. and otherwise
> only through a command of the application. but that last bit has the
> problem that, if he application is buggy, it may prevent you from
> entering the loader again.
>
> the reprogramming subprogram at least has commands to a) erase the rest
> of the flash, keeping the loader in place b) block write command c)
> reset cpu (to start the new software later, or to abort)
>
> i'll have to write such a loader at some time for a product too as the
> serial lines go trough optocouplers and only the Rx/Tx lines are
> wired... but i dont have any code right now.
>
> > Now, the code to work with the flash is all the mspgcc includes(though i
> > haven't accually tried using them myself), so that should make the job
> > easier... then it's pretty simple to just load from your memory device,
> > and write to the flash(after erasing the block)...
>
> the loader must not use any library functions unless they are stored in
> the protected flash area too and can be copied to the ram... (to put it
> simple: avoid them in the loader ;-)
>
> > Myself, i would make it always copy it's code to ram, since then there
> > isn't as much chance of mistakes. I'ld also write a block to copy back the
> > loader code into flash if it finds that area blank. But that is just my
> > method.
>
> ony work if you have enough ram... with 512 bytes it may be hard to
> write a serial protocol handler, flash writer that fits into the
> available space... i'd keep the serial protocol parts in the flash.
> never erasing it.
> only the flash block programming is copied to the ram (altough its not
> required. you can easily program flash while running from the same flash
> from an other bank. but with a ram programmer its faster)
>
> for a flash programmer that writes blocks from the ram into the flash,
> you can look at the (py)jtag sources. it has assembler bits to do that:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mspgcc/jtag/funclets/
> (eraseFlash.S and progFlash.S are interesting for you, you would end
> with "ret" instead of "jmp $")
>
> > the layout in the memory device should be well thought out and layed
> > out... hopefully all the code for talking with the memory, and the full
> > loader, will fit in your devices ram... if it doesn't, one option is to
> > have your loader in two places in flash while programming... but then you
> > have to keep both clear of your accual code...
>
> for the above loader i'd layout it something like that:
>
> 0xffff intvecs \
> 0xffe0 end loader } this part is never erased 1kB
> 0xfc00 begin loader /
> 0xfbff end application / redirection table 32 Bytes
> 0xxxxx rest of flash for application
>
> the redirection table has the same order as the real int vector table so
> the topmost entry is the application entry point. other entries are
> maped 1:1 except maybe the serial rx interrupt, depending on the loader
> implementation.
>
> HTH
> chris
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
