Re: Flashdriver for TC1796

[Rudi Pfister <Rudi.Pfister@informatik.stud.uni-erlangen.de>]

Hello,

I don't want to use the Flash Image System ...

I want to write programcode to the flash memory of the TC1796.
It should be possible to place the code anywhere in the flash,
e.g. to the program counter start address so the board will start
my application after a reset.

The only way to achieve this is to use the load-command with the
option -f <address> and for this operation Redboot uses the
buffer, or am I wrong ?

> The eCos design philosophy would be to use CDL.

Do you mean I should use an option to configure the size of the
buffer and only use the blocks smaller or equal to the buffer
size ?

Thanks !

	Rudi



> On Sat, Nov 18, 2006 at 04:06:45PM +0100, Rudi Pfister wrote:
> > Hello,
> >
> > I'm porting Redboot to the Tricore-architecture. In special to the
> > TC1796-variant on a Infineon-Triboard.
> >
> > The TC1796 has onchip 2 MByte of Flashmemory devided into several
> > blocks with sizes from 16 KByte up to 512 KByte.
> > The TC1796 has about 192 KByte RAM in total.
> > The Triboard has 1 MByte SRAM used by the TC1796 as external
> > Memory.
> >
> > I want to write a driver for the flash memory of the TC1796.
> >
> > If the Redboot wants to change data in the flash memory it stores
> > the block to which the data should be written to a buffer in RAM.
> > Then it changes the data in the buffer and writes it back to flash
> > memory. The size of the buffer has to be the same size as the
> > largest block in the flash memory.
> >
> > Here is my problem. The size of the buffer has to be 512 KByte, but
> > the TC1796 has less than 512 KByte in total, so there is no space to
> > create the Buffer an a TC1796.
> >
> > In my case I could use the RAM of the Triboard, which is large enough.
> > But then the the driver for the flash memory of the TC1796-variant would
> > depend on the properites of the Triboard-platform.
> > I could also use only a part of the flash of the TC1796. In special the
>
> blocks
>
> > with the size of 16 KBytes. In total I would then be able to use 128
> > Kbytes of Flashmemory, which would be enough for me.
> > But in my opinion both ways are very unsatisfying.
> >
> > Is there a better way to deal with this problem ?
> > And what is the best resolution in respect to the
> > eCos-design-philosophy ?
>
> The eCos design philosophy would be to use CDL.
>
> First off we should talk about the different uses Redboot makes of
> flash.
>
> There two configuration areas, FIS and CFG. These can be in separate
> blocks, or combined into one. Redboot keeps a working copy of these in
> RAM.
>
> The second usage of flash is to allow you to store application images
> in flash. This is the fis create command and fis load. They don't
> require a RAM copy of a flash block, you just need sufficient RAM to
> hold what ever you want move to/from flash.
>
> For FIS/CFG you want to use the smaller blocks. 16KBytes is big enough
> to hold the combined FIS/CFG.
>
> Once option is to let the flash driver report that the block size if
> 16KBytes. This will allow FIS/CFG to work optimally. However, if you
> ask FIS to find free space in the flash to place an image, it is going
> to give the wrong answer, because the block boundaries are not where
> it thinks they are. There is a danger you then put an image into the
> middle of a block, which results in the image before/after being
> corrupted when the block is erased. So long as you manually control
> the memory map, this can work.
>
> A second option is to add new code which allows you to control where
> the fis_work_block is stored. You HAL can then set this variable to
> somewhere in your external RAM.
>
>           Andrew