Flash memory and DM642EVM

Jeff, Greg--

Thanks for your time and patience.

I stopped using FlashBurn, as the free version only allowed me to
start writing Flash memory from address 0x9000 0000 on (the Flash Boot
Sector region is from 0x90000000 to 0x90000400). Instead, I tried to
use the EVMDM642_flash_write/read/erase functions (bsl) for writing
into Flash Memory (at my desired address). It worked and there was no
problem with the program from SDRAM this time.

So the problem was certainly writing in the flash boot sector.

For more information:
http://c6000.spectrumdigital.com/evmdm642/V3/docs/bsp/bsl_flash.html

Thanks again everyone,
David.

On Fri, May 30, 2008 at 5:24 AM, Jeff Brower wrote:
> David-
>
>> Sorry about my bad understanding, but everything regarding DSPs is
>> completely new to me.
>>
>> My flashBurn version is 3.11 SDK (the free version) from Software
>> Design Solutions, it does support the DM642 EVM version 2 (720Mhz)
>> board, and the Flash type of this board is a 4MB AMD Am29LV033C, so
>> everything seems correct to me.
>>
>> I created a .dat file with only 32 Bytes and wrote that to the Flash
>> using Flash Burn utility (it is being written to 0x9000 0000, which is
>> the boot section of Flash).
>>
>> It was successfully written. But again my SDRAM program didnt work.
>>
>> Now I am trying to modify the FBTC (Flash Burn target Component)
>> program in order to write outside the Flash Boot sector...
>
> Ok, that sounds good. I would suggest to try to find a "benign" area of Flash mem, one not involved in boot (either
> DSP or FPGA), and write small amounts of data to it, until things start to work / become clear.
>
> Then you'll have clear sailing -- for a while, until the next bug :-)
>
> -Jeff
>
>> On Thu, May 29, 2008 at 1:26 PM, Jeff Brower wrote:
>>> David-
>>>
>>>> The problem of the program is in the following line of the output
>>>> process: FVID_exchange(disChan, &disFrameBuf); (used for displaying a
>>>> frame) The second(!) time this "FVID_exchange" function is executed in
>>>> the output task, the program crashes. But both disChan and disFrameBuf
>>>> are outside the Flash memory address range...
>>>>
>>>> The only way to get the board back to work is doing the following
>>>> steps (which are the steps for programming the FPGA using FlashBurn)
>>>> - Use FlashBurn to erase the flash
>>>> - Burn the file osd_fpga_rev4_ahex.hex
>>>> - Burn the file fpga_load_ahex.hex (on top of osd_fpga_rev4_ahex.hex,
>>>> without erasing in between)
>>>> - Close FlashBurn and Code Composer
>>>> - Reset the EVM - observe that the yellow DS9 LED is on.
>>>>
>>>> The map file seems ok, there is nothing in the Flash memory address range.
>>>> Powering on/off the board also seems useless...
>>>
>>> Again, as I have mentioned, it seems that Flashburn screws something up on the board,
>>> probably the FPGA, possibly due to writing to incorrect addresses in CE1 space.
>>>
>>> The posts you're getting seem to be saying that you need to understand better the
>>> nature of Flash memory, whether Flashburn is actually correct for your version of the
>>> EVM DM642 board (v1/2 or 3?), the type of Flash device on the board, etc.
>>>
>>> What if you create a .dat file that just has one 32-bit word, and write that to
>>> Flash? Start with that, if it works, then expand on it.
>>>
>>> -Jeff
>>> --
>> David Gonzalez Gutierrez
>> Computer Science and Information Systems
>> Sanyo Electric Co. Ltd., Automotive Research
>> d...@gmail.com
>> Tel (Spain): (+34) 93 640 26 15
>> Tel (Japan): (+81) 070 6640 4885
>>

--
David Gonzalez Gutierrez
Computer Science and Information Systems
Sanyo Electric Co. Ltd., Automotive Research
d...@gmail.com
Tel (Spain): (+34) 93 640 26 15
Tel (Japan): (+81) 070 6640 4885 Start a New Thread

David-

> Thanks for your time and patience.
>
> I stopped using FlashBurn, as the free version only allowed me to
> start writing Flash memory from address 0x9000 0000 on (the Flash Boot
> Sector region is from 0x90000000 to 0x90000400). Instead, I tried to
> use the EVMDM642_flash_write/read/erase functions (bsl) for writing
> into Flash Memory (at my desired address). It worked and there was no
> problem with the program from SDRAM this time.
>
> So the problem was certainly writing in the flash boot sector.
>
> For more information:
> http://c6000.spectrumdigital.com/evmdm642/V3/docs/bsp/bsl_flash.html

Hey glad to hear it's working. So that's something useful for a lot of people -- knowing limitations of FlashBurn.
For some boards it might not make as much difference as it does for EVM DM642.

So for now you're Ok, since you are writing data to Flash. There is still the issue of what happens should you want
to put a DSP boot program into Flash, for example to get the EVM to boot and run your application in "stand alone"
mode.

-Jeff

> On Fri, May 30, 2008 at 5:24 AM, Jeff Brower wrote:
>> David-
>>
>>> Sorry about my bad understanding, but everything regarding DSPs is
>>> completely new to me.
>>>
>>> My flashBurn version is 3.11 SDK (the free version) from Software
>>> Design Solutions, it does support the DM642 EVM version 2 (720Mhz)
>>> board, and the Flash type of this board is a 4MB AMD Am29LV033C, so
>>> everything seems correct to me.
>>>
>>> I created a .dat file with only 32 Bytes and wrote that to the Flash
>>> using Flash Burn utility (it is being written to 0x9000 0000, which is
>>> the boot section of Flash).
>>>
>>> It was successfully written. But again my SDRAM program didnt work.
>>>
>>> Now I am trying to modify the FBTC (Flash Burn target Component)
>>> program in order to write outside the Flash Boot sector...
>>
>> Ok, that sounds good. I would suggest to try to find a "benign" area of Flash mem, one not involved in boot (either
>> DSP or FPGA), and write small amounts of data to it, until things start to work / become clear.
>>
>> Then you'll have clear sailing -- for a while, until the next bug :-)
>>
>> -Jeff
>>
>>> On Thu, May 29, 2008 at 1:26 PM, Jeff Brower wrote:
>>>> David-
>>>>
>>>>> The problem of the program is in the following line of the output
>>>>> process: FVID_exchange(disChan, &disFrameBuf); (used for displaying a
>>>>> frame) The second(!) time this "FVID_exchange" function is executed in
>>>>> the output task, the program crashes. But both disChan and disFrameBuf
>>>>> are outside the Flash memory address range...
>>>>>
>>>>> The only way to get the board back to work is doing the following
>>>>> steps (which are the steps for programming the FPGA using FlashBurn)
>>>>> - Use FlashBurn to erase the flash
>>>>> - Burn the file osd_fpga_rev4_ahex.hex
>>>>> - Burn the file fpga_load_ahex.hex (on top of osd_fpga_rev4_ahex.hex,
>>>>> without erasing in between)
>>>>> - Close FlashBurn and Code Composer
>>>>> - Reset the EVM - observe that the yellow DS9 LED is on.
>>>>>
>>>>> The map file seems ok, there is nothing in the Flash memory address range.
>>>>> Powering on/off the board also seems useless...
>>>>
>>>> Again, as I have mentioned, it seems that Flashburn screws something up on the board,
>>>> probably the FPGA, possibly due to writing to incorrect addresses in CE1 space.
>>>>
>>>> The posts you're getting seem to be saying that you need to understand better the
>>>> nature of Flash memory, whether Flashburn is actually correct for your version of the
>>>> EVM DM642 board (v1/2 or 3?), the type of Flash device on the board, etc.
>>>>
>>>> What if you create a .dat file that just has one 32-bit word, and write that to
>>>> Flash? Start with that, if it works, then expand on it.
>>>>
>>>> -Jeff
>>> --
>>> David Gonzalez Gutierrez
>>> Computer Science and Information Systems
>>> Sanyo Electric Co. Ltd., Automotive Research
>>> d...@gmail.com
>>> Tel (Spain): (+34) 93 640 26 15
>>> Tel (Japan): (+81) 070 6640 4885 Start a New Thread

Thanks, Jeff and everyone.

I will try to sum up the basics of Flash organization of DM642EVM
according to what I have understood.

I guess this will be useful for other people someday:

The Flash Memory of the DM642EVM has 4 MB divided in 8 pages.
In one page we have 8 sectors, and each sector has 64KB (8 * 64KB = 512KB)
We have 8 pages, and each page has 512KB (8 * 512KB = 4MB)

We have 4 MB, so we need 22 bits for addressing: bits A21-A0, where
bits A21-A19 are provided from the FPGA (FPGA acts as a page
selector), and bits A18-A0 are provided from the DM642.

The first page (page 0) is mapped in EMIF CE1, only using DM642 bits.
The other pages are also mapped in EMIF CE1, using bits from DM642 and FPGA.

Is it OK ?

David. Start a New Thread

David-

> Thanks, Jeff and everyone.
>
> I will try to sum up the basics of Flash organization of DM642EVM
> according to what I have understood.
>
> I guess this will be useful for other people someday:
>
> The Flash Memory of the DM642EVM has 4 MB divided in 8 pages.
> In one page we have 8 sectors, and each sector has 64KB (8 * 64KB = 512KB)
> We have 8 pages, and each page has 512KB (8 * 512KB = 4MB)
>
> We have 4 MB, so we need 22 bits for addressing: bits A21-A0, where
> bits A21-A19 are provided from the FPGA (FPGA acts as a page
> selector), and bits A18-A0 are provided from the DM642.
>
> The first page (page 0) is mapped in EMIF CE1, only using DM642 bits.
> The other pages are also mapped in EMIF CE1, using bits from DM642 and FPGA.
>
> Is it OK ?

I'm not sure. Spectrum Digital should be able to help with this, as they "own" the
EVM DM642 board -- at least the docs and tech support for it. Using the FPGA to
provide a Flash "bank select" register makes sense. However, you mentioned earlier
that you think part of the Flash holds some data related to FPGA boot, but I've never
seen a design that didn't have a separate, vendor-specific Flash to handle FPGA boot.

To me it still sounds unclear, so my suggestion would be to pin down the SD guys for
answers. You can tell them for me they need to assign a person to monitor this group
and answer questions having to do with their boards. The end result would be a whole
lot better than their website FAQ.

-Jeff Start a New Thread

Jeff and David - FYI,

On 6/2/08, Jeff Brower wrote:
>
> David-
>
> > Thanks, Jeff and everyone.
> >
> > I will try to sum up the basics of Flash organization of DM642EVM
> > according to what I have understood.
> >
> > I guess this will be useful for other people someday:
> >
> > The Flash Memory of the DM642EVM has 4 MB divided in 8 pages.
> > In one page we have 8 sectors, and each sector has 64KB (8 * 64KB > 512KB)
> > We have 8 pages, and each page has 512KB (8 * 512KB = 4MB)
> >
> > We have 4 MB, so we need 22 bits for addressing: bits A21-A0, where
> > bits A21-A19 are provided from the FPGA (FPGA acts as a page
> > selector), and bits A18-A0 are provided from the DM642.
> >
> > The first page (page 0) is mapped in EMIF CE1, only using DM642 bits.
> > The other pages are also mapped in EMIF CE1, using bits from DM642 and
> FPGA.
> >
> > Is it OK ?
>
> I'm not sure. Spectrum Digital should be able to help with this, as they
> "own" the
> EVM DM642 board -- at least the docs and tech support for it. Using the
> FPGA to
> provide a Flash "bank select" register makes sense. However, you mentioned
> earlier
> that you think part of the Flash holds some data related to FPGA boot, but
> I've never
> seen a design that didn't have a separate, vendor-specific Flash to handle
> FPGA boot.
>


According to the DM642 EVM Tech reference...
"In standard configuration the FPGA contents are stored in the upper half of
Flash
page 0. The lower half of Flash Page 0 contains the code loaded by the
internal boot
loader. This code is loaded at reset and programs the on board FPGA. The
DM642
interface to the FPGA is shown below."

mikedunn
> To me it still sounds unclear, so my suggestion would be to pin down the
> SD guys for
> answers. You can tell them for me they need to assign a person to monitor
> this group
> and answer questions having to do with their boards. The end result would
> be a whole
> lot better than their website FAQ.
>
> -Jeff

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php Start a New Thread

Mike-
> Jeff and David - FYI,
> On 6/2/08, Jeff Brower wrote:
>
> David-
>
> > Thanks, Jeff and everyone.
> >
> > I will try to sum up the basics of Flash organization of DM642EVM
> > according to what I have understood.
> >
> > I guess this will be useful for other people someday:
> >
> > The Flash Memory of the DM642EVM has 4 MB divided in 8 pages.
> > In one page we have 8 sectors, and each sector has 64KB (8 * 64KB > 512KB)
> > We have 8 pages, and each page has 512KB (8 * 512KB = 4MB)
> >
> > We have 4 MB, so we need 22 bits for addressing: bits A21-A0, where
> > bits A21-A19 are provided from the FPGA (FPGA acts as a page
> > selector), and bits A18-A0 are provided from the DM642.
> >
> > The first page (page 0) is mapped in EMIF CE1, only using DM642 bits.
> > The other pages are also mapped in EMIF CE1, using bits from DM642 and
> FPGA.
> >
> > Is it OK ?
>
> I'm not sure. Spectrum Digital should be able to help with this, as they
> "own" the
> EVM DM642 board -- at least the docs and tech support for it. Using the
> FPGA to
> provide a Flash "bank select" register makes sense. However, you
> mentioned earlier
> that you think part of the Flash holds some data related to FPGA boot,
> but I've never
> seen a design that didn't have a separate, vendor-specific Flash to
> handle FPGA boot.
>
> According to the DM642 EVM Tech reference..."In standard configuration the
> FPGA contents are stored in the upper half of Flash
> page 0. The lower half of Flash Page 0 contains the code loaded by the internal
> boot
> loader. This code is loaded at reset and programs the on board FPGA. The DM642
> interface to the FPGA is shown below."

Ok, so let me understand what the SD doc seems to imply:

-power-on: FPGA does a byte-wide boot from
Flash, DSP held in Reset

-FPGA booted: FPGA logic init state machine
sets Flash address page register,
releases DSP from Reset, allows
DSP to boot from Flash (if
jumpered that way)

-DSP booted: DSP may access Flash as needed
during run-time operation (but
must be done carefully so as
not to overwrite FPGA boot
bitstream contents)

Well I guess it could work, but it's darn kludgy. The only reason I can think of
doing it this way is one less Xilinx device (platform Flash) on the board. I guess
that must be a "TI EVM design constraint" -- use as few non-TI devices as possible.

-Jeff
> To me it still sounds unclear, so my suggestion would be to pin down the
> SD guys for
> answers. You can tell them for me they need to assign a person to monitor
> this group
> and answer questions having to do with their boards. The end result would
> be a whole
> lot better than their website FAQ.
>
> -Jeff
> Start a New Thread