Hey Jeff,

On Fri, Apr 2, 2010 at 9:58 AM, Jeff Brower wrote:

> Mike-
>
> > See the corrections below.
> >
> > On Thu, Apr 1, 2010 at 4:37 PM, Jeff Brower
> wrote:
> >
> >>
> >>
> >> Sankar,
> >>
> >> > On Wed, Mar 31, 2010 at 11:13 AM, > >
> >> wrote:
> >> >
> >> >>
> >> >>
> >> >> Thanks a lot Jeff.
> >> >>
> >> >> I am not using RDY signal from Flash. I use 2/8/2 for reading and
> >> writing
> >> >> with 50MHz EMIF speed. I used to use the flash of slower speed. In
> that
> >> case
> >> >> current flash should be better of having higher speed grade.
> >> >>
> >> >> My concern is that I do not have any control on the boot read done by
> >> DSP.
> >> >> Do you know if i can control the default timing of the EMIF DSP uses
> to
> >> read
> >> >> the first 1KB of boot code.
> >> >>
> >> >
> >> > You cannot control the initial timing. It will default to "maximum
> slow".
> >> >
> >> > "Differences [like memory speed or manufacturer] should always be
> suspect
> >> > but never assumed to be the problem."
> >> >
> >> > FYI- I have seen cases almost exactly like yours with a small sample
> size
> >> > [2] where the real problem turned out to be caused by a combination of
> >> [a]
> >> > different power on states of RAM and [2] an uninitialized variable.
> There
> >> is
> >> > no substitute for troubleshooting the problem.
> >> >
> >> > Try the following:
> >> > 1. From CCS, perform a 'CPU Reset'. This should reset the DSP, load
> the
> >> > first 1k into internal memory, and halt the DSP at address 0. If you
> >> select
> >> > 'Run', the boot process should complete and the embedded code should
> run.
> >> > 2. From this point, you can apply your personal favorite
> troubleshooting
> >> > technique. The simplest would be to single step from address 0.
> >>
> >> Mike's advice as usual is very good and suggest you follow it.
> >>
> >> One additional thing you might try: find the bootloader source code for
> >> C6713. Then you can see exactly what EMIF
> >> async timing is used at boot-time. Even without the source you might try
> >> single-stepping the bootloader so you can
> >> see some of its initial setup (without source you would see asm
> >> instructions, so not easy to decipher).
> >>
> >> I haven't checked in some time, but typically bootloader source can be
> >> found somewhere on TI's site, and if not then
> >> you can ask for it on e2e.ti.com forum.
> >>
> >
> > Actually the c620x, c6701, c621x, c671x devices do NOT have an internal
> boot
> > loader like the c672x devices.
> > c621x and c671x devices boot using a state machine that DMAs 1k [64k for
> > 620x/6701] into internal memory via the EMIF based on the configuration
> > pins. The transfer takes place while reset is low. Since reset forces
> the
> > CE space timing to all ones [hence my description of 'maximum slow'], the
> > maximum number of CPU wait states will be generated. spru190 will point
> you
> > to the EMIF docs if you want to compute the exact EMIF timing.
> >
> > The first instruction that is executed during the boot process is the
> user
> > instruction that lands at address 0.
>
> Thanks for this correction. Back in the 2000-2003 time-frame some of the
> C54xx devices had an onchip bootloader so I
> assumed the C67xx product line had reached that point also. Bad
> assumption.
>
> One thing you mention I'm not sure of -- transfer taking place while Reset
> is low. SPRA978 mentions:
>
> "When the DSP is brought out of reset in [ROM boot] mode,
> the CPU core is internally held in reset while the
> DMA/EDMA peripheral transfers code from external non-
> volatile memory to address 0 of DSP memory."
>

I plead guilty of over simplification when answering the 'question not
asked' [how does it work?].
The description above is correct.
like the follow [ FYI-this description also applies to c6416 type devices]
... :-) >
The external reset performs any required board reset functions.
The rising edge of reset initiates the DMA xfer from the EMIF to internal
RAM beginning at address 0 while the DSP core remains in reset. When the DMA
xfer is complete, the core is released from reset. Since the PC was reset to
0, a fetch packet will be read from address 0 and execution will begin.

mikedunn

>
> -Jeff
>
> >> >> >I am working on a custom board having TMS320C6713BPYP interfaced
> with
> >> ST
> >> >> M29W400DT, a 55ns part. Most of the power ups, boot fails. When it
> >> succeeds
> >> >> to boot it work fine. I checked the chip select line of the flash
> after
> >> >> reset. It seems DSP reads 1K boot code. But after that DSP does not
> read
> >> in
> >> >> the rest of the program. It seems to me that boot code get corrupted
> >> during
> >> >> the boot up. Can any one suggests any debugging clue so that i can
> >> >> investigate it further. I can not suspect my boot code because system
> >> work
> >> >> fine when boot code reads rest of the programm more over I have
> another
> >> >> board with slower flash which is s29AL00470T, spansion 70ns part,
> >> working
> >> >> fine with the same boot code.
> >> >> >
> >> >> >Any help is appreciated.
> >> >> >
> >> >> >Sankar
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

Mike-

> See the corrections below.
>
> On Thu, Apr 1, 2010 at 4:37 PM, Jeff Brower wrote:
>
>> Sankar,
>>
>> > On Wed, Mar 31, 2010 at 11:13 AM, >
>> wrote:
>> >
>> >>
>> >>
>> >> Thanks a lot Jeff.
>> >>
>> >> I am not using RDY signal from Flash. I use 2/8/2 for reading and
>> writing
>> >> with 50MHz EMIF speed. I used to use the flash of slower speed. In that
>> case
>> >> current flash should be better of having higher speed grade.
>> >>
>> >> My concern is that I do not have any control on the boot read done by
>> DSP.
>> >> Do you know if i can control the default timing of the EMIF DSP uses to
>> read
>> >> the first 1KB of boot code.
>> >>
>> >
>> > You cannot control the initial timing. It will default to "maximum slow".
>> >
>> > "Differences [like memory speed or manufacturer] should always be suspect
>> > but never assumed to be the problem."
>> >
>> > FYI- I have seen cases almost exactly like yours with a small sample size
>> > [2] where the real problem turned out to be caused by a combination of
>> [a]
>> > different power on states of RAM and [2] an uninitialized variable. There
>> is
>> > no substitute for troubleshooting the problem.
>> >
>> > Try the following:
>> > 1. From CCS, perform a 'CPU Reset'. This should reset the DSP, load the
>> > first 1k into internal memory, and halt the DSP at address 0. If you
>> select
>> > 'Run', the boot process should complete and the embedded code should run.
>> > 2. From this point, you can apply your personal favorite troubleshooting
>> > technique. The simplest would be to single step from address 0.
>>
>> Mike's advice as usual is very good and suggest you follow it.
>>
>> One additional thing you might try: find the bootloader source code for
>> C6713. Then you can see exactly what EMIF
>> async timing is used at boot-time. Even without the source you might try
>> single-stepping the bootloader so you can
>> see some of its initial setup (without source you would see asm
>> instructions, so not easy to decipher).
>>
>> I haven't checked in some time, but typically bootloader source can be
>> found somewhere on TI's site, and if not then
>> you can ask for it on e2e.ti.com forum.
>>
>
> Actually the c620x, c6701, c621x, c671x devices do NOT have an internal boot
> loader like the c672x devices.
> c621x and c671x devices boot using a state machine that DMAs 1k [64k for
> 620x/6701] into internal memory via the EMIF based on the configuration
> pins. The transfer takes place while reset is low. Since reset forces the
> CE space timing to all ones [hence my description of 'maximum slow'], the
> maximum number of CPU wait states will be generated. spru190 will point you
> to the EMIF docs if you want to compute the exact EMIF timing.
>
> The first instruction that is executed during the boot process is the user
> instruction that lands at address 0.

Thanks for this correction. Back in the 2000-2003 time-frame some of the C54xx devices had an onchip bootloader so I
assumed the C67xx product line had reached that point also. Bad assumption.

One thing you mention I'm not sure of -- transfer taking place while Reset is low. SPRA978 mentions:

"When the DSP is brought out of reset in [ROM boot] mode,
the CPU core is internally held in reset while the
DMA/EDMA peripheral transfers code from external non-
volatile memory to address 0 of DSP memory."

-Jeff

>> >> >I am working on a custom board having TMS320C6713BPYP interfaced with
>> ST
>> >> M29W400DT, a 55ns part. Most of the power ups, boot fails. When it
>> succeeds
>> >> to boot it work fine. I checked the chip select line of the flash after
>> >> reset. It seems DSP reads 1K boot code. But after that DSP does not read
>> in
>> >> the rest of the program. It seems to me that boot code get corrupted
>> during
>> >> the boot up. Can any one suggests any debugging clue so that i can
>> >> investigate it further. I can not suspect my boot code because system
>> work
>> >> fine when boot code reads rest of the programm more over I have another
>> >> board with slower flash which is s29AL00470T, spansion 70ns part,
>> working
>> >> fine with the same boot code.
>> >> >
>> >> >Any help is appreciated.
>> >> >
>> >> >Sankar

_____________________________________

Sankar and Jeff,

See the corrections below.

On Thu, Apr 1, 2010 at 4:37 PM, Jeff Brower wrote:

> Sankar,
>
> > On Wed, Mar 31, 2010 at 11:13 AM, >
> wrote:
> >
> >>
> >>
> >> Thanks a lot Jeff.
> >>
> >> I am not using RDY signal from Flash. I use 2/8/2 for reading and
> writing
> >> with 50MHz EMIF speed. I used to use the flash of slower speed. In that
> case
> >> current flash should be better of having higher speed grade.
> >>
> >> My concern is that I do not have any control on the boot read done by
> DSP.
> >> Do you know if i can control the default timing of the EMIF DSP uses to
> read
> >> the first 1KB of boot code.
> >>
> >
> > You cannot control the initial timing. It will default to "maximum slow".
> >
> > "Differences [like memory speed or manufacturer] should always be suspect
> > but never assumed to be the problem."
> >
> > FYI- I have seen cases almost exactly like yours with a small sample size
> > [2] where the real problem turned out to be caused by a combination of
> [a]
> > different power on states of RAM and [2] an uninitialized variable. There
> is
> > no substitute for troubleshooting the problem.
> >
> > Try the following:
> > 1. From CCS, perform a 'CPU Reset'. This should reset the DSP, load the
> > first 1k into internal memory, and halt the DSP at address 0. If you
> select
> > 'Run', the boot process should complete and the embedded code should run.
> > 2. From this point, you can apply your personal favorite troubleshooting
> > technique. The simplest would be to single step from address 0.
>
> Mike's advice as usual is very good and suggest you follow it.
>
> One additional thing you might try: find the bootloader source code for
> C6713. Then you can see exactly what EMIF
> async timing is used at boot-time. Even without the source you might try
> single-stepping the bootloader so you can
> see some of its initial setup (without source you would see asm
> instructions, so not easy to decipher).
>
> I haven't checked in some time, but typically bootloader source can be
> found somewhere on TI's site, and if not then
> you can ask for it on e2e.ti.com forum.
>

Actually the c620x, c6701, c621x, c671x devices do NOT have an internal boot
loader like the c672x devices.
c621x and c671x devices boot using a state machine that DMAs 1k [64k for
620x/6701] into internal memory via the EMIF based on the configuration
pins. The transfer takes place while reset is low. Since reset forces the
CE space timing to all ones [hence my description of 'maximum slow'], the
maximum number of CPU wait states will be generated. spru190 will point you
to the EMIF docs if you want to compute the exact EMIF timing.

The first instruction that is executed during the boot process is the user
instruction that lands at address 0.

mikedunn

>
> -Jeff
> >> >I am working on a custom board having TMS320C6713BPYP interfaced with
> ST
> >> M29W400DT, a 55ns part. Most of the power ups, boot fails. When it
> succeeds
> >> to boot it work fine. I checked the chip select line of the flash after
> >> reset. It seems DSP reads 1K boot code. But after that DSP does not read
> in
> >> the rest of the program. It seems to me that boot code get corrupted
> during
> >> the boot up. Can any one suggests any debugging clue so that i can
> >> investigate it further. I can not suspect my boot code because system
> work
> >> fine when boot code reads rest of the programm more over I have another
> >> board with slower flash which is s29AL00470T, spansion 70ns part,
> working
> >> fine with the same boot code.
> >> >
> >> >Any help is appreciated.
> >> >
> >> >Sankar
>
>
>

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

Sankar,

> On Wed, Mar 31, 2010 at 11:13 AM, wrote:
>
>> Thanks a lot Jeff.
>>
>> I am not using RDY signal from Flash. I use 2/8/2 for reading and writing
>> with 50MHz EMIF speed. I used to use the flash of slower speed. In that case
>> current flash should be better of having higher speed grade.
>>
>> My concern is that I do not have any control on the boot read done by DSP.
>> Do you know if i can control the default timing of the EMIF DSP uses to read
>> the first 1KB of boot code.
>>
>
> You cannot control the initial timing. It will default to "maximum slow".
>
> "Differences [like memory speed or manufacturer] should always be suspect
> but never assumed to be the problem."
>
> FYI- I have seen cases almost exactly like yours with a small sample size
> [2] where the real problem turned out to be caused by a combination of [a]
> different power on states of RAM and [2] an uninitialized variable. There is
> no substitute for troubleshooting the problem.
>
> Try the following:
> 1. From CCS, perform a 'CPU Reset'. This should reset the DSP, load the
> first 1k into internal memory, and halt the DSP at address 0. If you select
> 'Run', the boot process should complete and the embedded code should run.
> 2. From this point, you can apply your personal favorite troubleshooting
> technique. The simplest would be to single step from address 0.

Mike's advice as usual is very good and suggest you follow it.

One additional thing you might try: find the bootloader source code for C6713. Then you can see exactly what EMIF
async timing is used at boot-time. Even without the source you might try single-stepping the bootloader so you can
see some of its initial setup (without source you would see asm instructions, so not easy to decipher).

I haven't checked in some time, but typically bootloader source can be found somewhere on TI's site, and if not then
you can ask for it on e2e.ti.com forum.

-Jeff

>> >I am working on a custom board having TMS320C6713BPYP interfaced with ST
>> M29W400DT, a 55ns part. Most of the power ups, boot fails. When it succeeds
>> to boot it work fine. I checked the chip select line of the flash after
>> reset. It seems DSP reads 1K boot code. But after that DSP does not read in
>> the rest of the program. It seems to me that boot code get corrupted during
>> the boot up. Can any one suggests any debugging clue so that i can
>> investigate it further. I can not suspect my boot code because system work
>> fine when boot code reads rest of the programm more over I have another
>> board with slower flash which is s29AL00470T, spansion 70ns part, working
>> fine with the same boot code.
>> >
>> >Any help is appreciated.
>> >
>> >Sankar

_____________________________________

Sankar,

On Wed, Mar 31, 2010 at 11:13 AM, wrote:

> Thanks a lot Jeff.
>
> I am not using RDY signal from Flash. I use 2/8/2 for reading and writing
> with 50MHz EMIF speed. I used to use the flash of slower speed. In that case
> current flash should be better of having higher speed grade.
>
> My concern is that I do not have any control on the boot read done by DSP.
> Do you know if i can control the default timing of the EMIF DSP uses to read
> the first 1KB of boot code.
>

You cannot control the initial timing. It will default to "maximum slow".

"Differences [like memory speed or manufacturer] should always be suspect
but never assumed to be the problem."

FYI- I have seen cases almost exactly like yours with a small sample size
[2] where the real problem turned out to be caused by a combination of [a]
different power on states of RAM and [2] an uninitialized variable. There is
no substitute for troubleshooting the problem.

Try the following:
1. From CCS, perform a 'CPU Reset'. This should reset the DSP, load the
first 1k into internal memory, and halt the DSP at address 0. If you select
'Run', the boot process should complete and the embedded code should run.
2. From this point, you can apply your personal favorite troubleshooting
technique. The simplest would be to single step from address 0.

mikedunn

>
> Thanks
>
> Sankar
>
> Hi,
>
> >
> >I am working on a custom board having TMS320C6713BPYP interfaced with ST
> M29W400DT, a 55ns part. Most of the power ups, boot fails. When it succeeds
> to boot it work fine. I checked the chip select line of the flash after
> reset. It seems DSP reads 1K boot code. But after that DSP does not read in
> the rest of the program. It seems to me that boot code get corrupted during
> the boot up. Can any one suggests any debugging clue so that i can
> investigate it further. I can not suspect my boot code because system work
> fine when boot code reads rest of the programm more over I have another
> board with slower flash which is s29AL00470T, spansion 70ns part, working
> fine with the same boot code.
> >
> >Any help is appreciated.
> >
> >Sankar
> >
> >_____________________________________
> >
> >
>
>

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

Hi,
>
>I am working on a custom board having TMS320C6713BPYP interfaced with ST M29W400DT, a 55ns part. Most of the power ups, boot fails. When it succeeds to boot it work fine. I checked the chip select line of the flash after reset. It seems DSP reads 1K boot code. But after that DSP does not read in the rest of the program. It seems to me that boot code get corrupted during the boot up. Can any one suggests any debugging clue so that i can investigate it further. I can not suspect my boot code because system work fine when boot code reads rest of the programm more over I have another board with slower flash which is s29AL00470T, spansion 70ns part, working fine with the same boot code.
>
>Any help is appreciated.
>
>Sankar
>
>_____________________________________

_____________________________________

Thanks a lot Jeff.

I am not using RDY signal from Flash. I use 2/8/2 for reading and writing with 50MHz EMIF speed. I used to use the flash of slower speed. In that case current flash should be better of having higher speed grade.

My concern is that I do not have any control on the boot read done by DSP. Do you know if i can control the default timing of the EMIF DSP uses to read the first 1KB of boot code.

Thanks

Sankar

Hi,
>
>I am working on a custom board having TMS320C6713BPYP interfaced with ST M29W400DT, a 55ns part. Most of the power ups, boot fails. When it succeeds to boot it work fine. I checked the chip select line of the flash after reset. It seems DSP reads 1K boot code. But after that DSP does not read in the rest of the program. It seems to me that boot code get corrupted during the boot up. Can any one suggests any debugging clue so that i can investigate it further. I can not suspect my boot code because system work fine when boot code reads rest of the programm more over I have another board with slower flash which is s29AL00470T, spansion 70ns part, working fine with the same boot code.
>
>Any help is appreciated.
>
>Sankar
>
>_____________________________________

_____________________________________

Sankar-

> I am working on a custom board having TMS320C6713BPYP
> interfaced with ST M29W400DT, a 55ns part. Most of the
> power ups, boot fails. When it succeeds to boot it
> work fine. I checked the chip select line of the flash
> after reset. It seems DSP reads 1K boot code. But
> after that DSP does not read in the rest of the
> program. It seems to me that boot code get corrupted
> during the boot up. Can any one suggests any debugging
> clue so that i can investigate it further. I
> can not suspect my boot code because system work fine
> when boot code reads rest of the programm more over I
> have another board with slower flash which is
> s29AL00470T, spansion 70ns part, working fine with the
> same boot code.

Since you have another working system with identical code and circuitry, we can guess the issue may be related to
Flash access timing -- some reads returning incorrect values. How did you initialize async EMIF registers for the
Flash CEn space? How do you control Flash access timing? Are you using the RDY signal from the Flash? Are you using
a fixed number of wait-states?

-Jeff

_____________________________________