Hello,
I want to store some data (not a bootable program) inside the flash
memory of the DM642EVM board, and read it later on.
I tried the following 3 ways:
1) Probe Points: I set up a probe point to write the contents of a
memory region to a .dat file. After that, I set up another probe point
to store the contents of the .dat file into Flash (address 0x 9000
0000, EMIFA CE1)
2) Storing manually 32 bits in this way:
#define MFLASH 0x90000000
*(int *) MFLASH = (*(int *) MFLASH) | 0x23232323;
3) Using FlashBurner and the .dat file.
But none of the 3 methods work: My video-loopback application ends up
showing nothing. Is this possible ? I mean, I can't understand why
writing to somewhere external like Flash can cause a program stored in
RAM to stop working...
Any help/ideas?
Thanks!
David
Flash memory and DM642EVM
Started by ●May 28, 2008
Reply by ●May 28, 20082008-05-28
Method 1, what is that?
Method 2, you need a flash driver to write to flash, that is easy to do for basic writing/erasing, for a full flash driver that handles toggle bit and error cases it is a bit more complicated, just check your flash provider and read data sheet.
Method 3, that should work, as flashburner includes a flash driver. did it give you an error? don't you see the data in flash by reading them?
Method 2, you need a flash driver to write to flash, that is easy to do for basic writing/erasing, for a full flash driver that handles toggle bit and error cases it is a bit more complicated, just check your flash provider and read data sheet.
Method 3, that should work, as flashburner includes a flash driver. did it give you an error? don't you see the data in flash by reading them?
Reply by ●May 28, 20082008-05-28
David-
> I want to store some data (not a bootable program) inside the flash
> memory of the DM642EVM board, and read it later on.
>
> I tried the following 3 ways:
>
> 1) Probe Points: I set up a probe point to write the contents of a
> memory region to a .dat file. After that, I set up another probe point
> to store the contents of the .dat file into Flash (address 0x 9000
> 0000, EMIFA CE1)
>
> 2) Storing manually 32 bits in this way:
>
> #define MFLASH 0x90000000
> *(int *) MFLASH = (*(int *) MFLASH) | 0x23232323;
Christophe already commented, but on your method 2), I would emphasize that you
*cannot* write Flash using a simple one-line access, as is possible with other types
of memory. Flash devices have special sequences of patterns and addresses used for
write operations, in order to protect against inadvertent writes (for example, if
your code crashes or the CPU does something crazy).
As Christophe mentioned, you should download the data sheet for your specific Flash
device, then you can know the special write sequences.
-Jeff
> 3) Using FlashBurner and the .dat file.
>
> But none of the 3 methods work: My video-loopback application ends up
> showing nothing. Is this possible ? I mean, I can't understand why
> writing to somewhere external like Flash can cause a program stored in
> RAM to stop working...
>
> Any help/ideas?
>
> Thanks!
> David
> I want to store some data (not a bootable program) inside the flash
> memory of the DM642EVM board, and read it later on.
>
> I tried the following 3 ways:
>
> 1) Probe Points: I set up a probe point to write the contents of a
> memory region to a .dat file. After that, I set up another probe point
> to store the contents of the .dat file into Flash (address 0x 9000
> 0000, EMIFA CE1)
>
> 2) Storing manually 32 bits in this way:
>
> #define MFLASH 0x90000000
> *(int *) MFLASH = (*(int *) MFLASH) | 0x23232323;
Christophe already commented, but on your method 2), I would emphasize that you
*cannot* write Flash using a simple one-line access, as is possible with other types
of memory. Flash devices have special sequences of patterns and addresses used for
write operations, in order to protect against inadvertent writes (for example, if
your code crashes or the CPU does something crazy).
As Christophe mentioned, you should download the data sheet for your specific Flash
device, then you can know the special write sequences.
-Jeff
> 3) Using FlashBurner and the .dat file.
>
> But none of the 3 methods work: My video-loopback application ends up
> showing nothing. Is this possible ? I mean, I can't understand why
> writing to somewhere external like Flash can cause a program stored in
> RAM to stop working...
>
> Any help/ideas?
>
> Thanks!
> David
Reply by ●May 28, 20082008-05-28
Jeff and Cristophe:
I will try to explain the problem in detail:
OK, in order to program Flash some sequences of bytes have to been
written to the flash memory (according to the data sheet). That is
what FlashBurn does, using a target side program loaded with CCS. I
used FlashBurn and could write into Flash Memory the desired data. I
checked the written data with both CCS and FB and everything was OK.
** BUT after that, I loaded my video loopback program in RAM and
attempted to run it. Instead of the video loopback, only a plain color
was being displayed ! This program loaded in RAM does not use the
flash memory at all. It basically has 3 tasks, and both of them seem
to be executed without any noticeable error:
1) Input : gets a frame by using: FVID_exchange(capChan, &capFrameBuf);
2) Process: does sth with the frame.
3) Output: displays the frame by using FVID_exchange(disChan, &disFrameBuf);
and the memory configuration is :
1) ISRAM : start at 0000 0400, len 0003 FFFF
2) SDRAM : start at 0800 0000, len 0820 0000
So, the question is: Why writing to Flash makes a program stored in
RAM to stop working ?
Thanks in advance.
David
On Wed, May 28, 2008 at 11:40 PM, Jeff Brower wrote:
> David-
>
>> I want to store some data (not a bootable program) inside the flash
>> memory of the DM642EVM board, and read it later on.
>>
>> I tried the following 3 ways:
>>
>> 1) Probe Points: I set up a probe point to write the contents of a
>> memory region to a .dat file. After that, I set up another probe point
>> to store the contents of the .dat file into Flash (address 0x 9000
>> 0000, EMIFA CE1)
>>
>> 2) Storing manually 32 bits in this way:
>>
>> #define MFLASH 0x90000000
>> *(int *) MFLASH = (*(int *) MFLASH) | 0x23232323;
>
> Christophe already commented, but on your method 2), I would emphasize that you
> *cannot* write Flash using a simple one-line access, as is possible with other types
> of memory. Flash devices have special sequences of patterns and addresses used for
> write operations, in order to protect against inadvertent writes (for example, if
> your code crashes or the CPU does something crazy).
>
> As Christophe mentioned, you should download the data sheet for your specific Flash
> device, then you can know the special write sequences.
>
> -Jeff
>
>> 3) Using FlashBurner and the .dat file.
>>
>> But none of the 3 methods work: My video-loopback application ends up
>> showing nothing. Is this possible ? I mean, I can't understand why
>> writing to somewhere external like Flash can cause a program stored in
>> RAM to stop working...
>>
>> Any help/ideas?
>>
>> Thanks!
>> David
>
--
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
I will try to explain the problem in detail:
OK, in order to program Flash some sequences of bytes have to been
written to the flash memory (according to the data sheet). That is
what FlashBurn does, using a target side program loaded with CCS. I
used FlashBurn and could write into Flash Memory the desired data. I
checked the written data with both CCS and FB and everything was OK.
** BUT after that, I loaded my video loopback program in RAM and
attempted to run it. Instead of the video loopback, only a plain color
was being displayed ! This program loaded in RAM does not use the
flash memory at all. It basically has 3 tasks, and both of them seem
to be executed without any noticeable error:
1) Input : gets a frame by using: FVID_exchange(capChan, &capFrameBuf);
2) Process: does sth with the frame.
3) Output: displays the frame by using FVID_exchange(disChan, &disFrameBuf);
and the memory configuration is :
1) ISRAM : start at 0000 0400, len 0003 FFFF
2) SDRAM : start at 0800 0000, len 0820 0000
So, the question is: Why writing to Flash makes a program stored in
RAM to stop working ?
Thanks in advance.
David
On Wed, May 28, 2008 at 11:40 PM, Jeff Brower wrote:
> David-
>
>> I want to store some data (not a bootable program) inside the flash
>> memory of the DM642EVM board, and read it later on.
>>
>> I tried the following 3 ways:
>>
>> 1) Probe Points: I set up a probe point to write the contents of a
>> memory region to a .dat file. After that, I set up another probe point
>> to store the contents of the .dat file into Flash (address 0x 9000
>> 0000, EMIFA CE1)
>>
>> 2) Storing manually 32 bits in this way:
>>
>> #define MFLASH 0x90000000
>> *(int *) MFLASH = (*(int *) MFLASH) | 0x23232323;
>
> Christophe already commented, but on your method 2), I would emphasize that you
> *cannot* write Flash using a simple one-line access, as is possible with other types
> of memory. Flash devices have special sequences of patterns and addresses used for
> write operations, in order to protect against inadvertent writes (for example, if
> your code crashes or the CPU does something crazy).
>
> As Christophe mentioned, you should download the data sheet for your specific Flash
> device, then you can know the special write sequences.
>
> -Jeff
>
>> 3) Using FlashBurner and the .dat file.
>>
>> But none of the 3 methods work: My video-loopback application ends up
>> showing nothing. Is this possible ? I mean, I can't understand why
>> writing to somewhere external like Flash can cause a program stored in
>> RAM to stop working...
>>
>> Any help/ideas?
>>
>> Thanks!
>> David
>
--
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
Reply by ●May 29, 20082008-05-29
David-
> I will try to explain the problem in detail:
>
> OK, in order to program Flash some sequences of bytes have to been
> written to the flash memory (according to the data sheet). That is
> what FlashBurn does, using a target side program loaded with CCS. I
> used FlashBurn and could write into Flash Memory the desired data. I
> checked the written data with both CCS and FB and everything was OK.
>
> ** BUT after that, I loaded my video loopback program in RAM and
> attempted to run it. Instead of the video loopback, only a plain color
> was being displayed ! This program loaded in RAM does not use the
> flash memory at all. It basically has 3 tasks, and both of them seem
> to be executed without any noticeable error:
> 1) Input : gets a frame by using: FVID_exchange(capChan, &capFrameBuf);
> 2) Process: does sth with the frame.
> 3) Output: displays the frame by using FVID_exchange(disChan, &disFrameBuf);
> and the memory configuration is :
> 1) ISRAM : start at 0000 0400, len 0003 FFFF
> 2) SDRAM : start at 0800 0000, len 0820 0000
>
> So, the question is: Why writing to Flash makes a program stored in
> RAM to stop working ?
And if you erase Flash memory, then your program works again? If so then your
program probably reads some variable or array from Flash memory space, and normally
the value is 0xffffffff (or whatever Flash mem contents are when erased), but you
haven't found it yet. You should check the .map file section that lists memory usage
by address and see if there's anything at all in the 0x90000000 range (CE1 space,
connected to Flash on the DM642 EVM).
Another possibility is that when you write to Flash, somehow you mess up the FPGA
settings (also connected to CE1 space), which in turn causes some issue with video
I/O. Did you try powering off/on the board before re-running your program? That
should re-init the FPGA to default values.
-Jeff
> On Wed, May 28, 2008 at 11:40 PM, Jeff Brower wrote:
> > David-
> >
> >> I want to store some data (not a bootable program) inside the flash
> >> memory of the DM642EVM board, and read it later on.
> >>
> >> I tried the following 3 ways:
> >>
> >> 1) Probe Points: I set up a probe point to write the contents of a
> >> memory region to a .dat file. After that, I set up another probe point
> >> to store the contents of the .dat file into Flash (address 0x 9000
> >> 0000, EMIFA CE1)
> >>
> >> 2) Storing manually 32 bits in this way:
> >>
> >> #define MFLASH 0x90000000
> >> *(int *) MFLASH = (*(int *) MFLASH) | 0x23232323;
> >
> > Christophe already commented, but on your method 2), I would emphasize that you
> > *cannot* write Flash using a simple one-line access, as is possible with other types
> > of memory. Flash devices have special sequences of patterns and addresses used for
> > write operations, in order to protect against inadvertent writes (for example, if
> > your code crashes or the CPU does something crazy).
> >
> > As Christophe mentioned, you should download the data sheet for your specific Flash
> > device, then you can know the special write sequences.
> >
> > -Jeff
> >
> >> 3) Using FlashBurner and the .dat file.
> >>
> >> But none of the 3 methods work: My video-loopback application ends up
> >> showing nothing. Is this possible ? I mean, I can't understand why
> >> writing to somewhere external like Flash can cause a program stored in
> >> RAM to stop working...
> >>
> >> Any help/ideas?
> >>
> >> Thanks!
> >> David
> > --
> 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
> I will try to explain the problem in detail:
>
> OK, in order to program Flash some sequences of bytes have to been
> written to the flash memory (according to the data sheet). That is
> what FlashBurn does, using a target side program loaded with CCS. I
> used FlashBurn and could write into Flash Memory the desired data. I
> checked the written data with both CCS and FB and everything was OK.
>
> ** BUT after that, I loaded my video loopback program in RAM and
> attempted to run it. Instead of the video loopback, only a plain color
> was being displayed ! This program loaded in RAM does not use the
> flash memory at all. It basically has 3 tasks, and both of them seem
> to be executed without any noticeable error:
> 1) Input : gets a frame by using: FVID_exchange(capChan, &capFrameBuf);
> 2) Process: does sth with the frame.
> 3) Output: displays the frame by using FVID_exchange(disChan, &disFrameBuf);
> and the memory configuration is :
> 1) ISRAM : start at 0000 0400, len 0003 FFFF
> 2) SDRAM : start at 0800 0000, len 0820 0000
>
> So, the question is: Why writing to Flash makes a program stored in
> RAM to stop working ?
And if you erase Flash memory, then your program works again? If so then your
program probably reads some variable or array from Flash memory space, and normally
the value is 0xffffffff (or whatever Flash mem contents are when erased), but you
haven't found it yet. You should check the .map file section that lists memory usage
by address and see if there's anything at all in the 0x90000000 range (CE1 space,
connected to Flash on the DM642 EVM).
Another possibility is that when you write to Flash, somehow you mess up the FPGA
settings (also connected to CE1 space), which in turn causes some issue with video
I/O. Did you try powering off/on the board before re-running your program? That
should re-init the FPGA to default values.
-Jeff
> On Wed, May 28, 2008 at 11:40 PM, Jeff Brower wrote:
> > David-
> >
> >> I want to store some data (not a bootable program) inside the flash
> >> memory of the DM642EVM board, and read it later on.
> >>
> >> I tried the following 3 ways:
> >>
> >> 1) Probe Points: I set up a probe point to write the contents of a
> >> memory region to a .dat file. After that, I set up another probe point
> >> to store the contents of the .dat file into Flash (address 0x 9000
> >> 0000, EMIFA CE1)
> >>
> >> 2) Storing manually 32 bits in this way:
> >>
> >> #define MFLASH 0x90000000
> >> *(int *) MFLASH = (*(int *) MFLASH) | 0x23232323;
> >
> > Christophe already commented, but on your method 2), I would emphasize that you
> > *cannot* write Flash using a simple one-line access, as is possible with other types
> > of memory. Flash devices have special sequences of patterns and addresses used for
> > write operations, in order to protect against inadvertent writes (for example, if
> > your code crashes or the CPU does something crazy).
> >
> > As Christophe mentioned, you should download the data sheet for your specific Flash
> > device, then you can know the special write sequences.
> >
> > -Jeff
> >
> >> 3) Using FlashBurner and the .dat file.
> >>
> >> But none of the 3 methods work: My video-loopback application ends up
> >> showing nothing. Is this possible ? I mean, I can't understand why
> >> writing to somewhere external like Flash can cause a program stored in
> >> RAM to stop working...
> >>
> >> Any help/ideas?
> >>
> >> Thanks!
> >> David
> > --
> 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
Reply by ●May 29, 20082008-05-29
Jeff,
Thanks for your mail,
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...
David.
Thanks for your mail,
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...
David.
Reply by ●May 29, 20082008-05-29
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
> 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
Reply by ●May 29, 20082008-05-29
Jeff-
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...
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
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...
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
Reply by ●May 29, 20082008-05-29
David,
Are you using the BSL_init function provided with the EVM board? If you are
then erasing the flash will cause that function to not program the FPGA
correctly and you will probably see strange problems (like you are).
I forget the address but I belive the upper 256KB of the flash is supposed
to contain the FPGA image that BSL_init will program. The FPGA is also what
controls the upper 3 address pins on the flash to allow access to a flash
memory bigger than 1MB.
How much data are you trying to store in the flash memory? You might need to
work with the BSL library provided and only use the upper parts of flash
memory after the FPGA has control and can change the upper address pins for
you.
Greg Lee
On Wed, May 28, 2008 at 11:58 PM, David Gonzalez <
d...@gmail.com> wrote:
> Jeff-
>
> 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...
> 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
>
>
>
>
>
>
>
Are you using the BSL_init function provided with the EVM board? If you are
then erasing the flash will cause that function to not program the FPGA
correctly and you will probably see strange problems (like you are).
I forget the address but I belive the upper 256KB of the flash is supposed
to contain the FPGA image that BSL_init will program. The FPGA is also what
controls the upper 3 address pins on the flash to allow access to a flash
memory bigger than 1MB.
How much data are you trying to store in the flash memory? You might need to
work with the BSL library provided and only use the upper parts of flash
memory after the FPGA has control and can change the upper address pins for
you.
Greg Lee
On Wed, May 28, 2008 at 11:58 PM, David Gonzalez <
d...@gmail.com> wrote:
> Jeff-
>
> 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...
> 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
>
>
>
>
>
>
>
Reply by ●May 29, 20082008-05-29
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
>
> 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
>
