AD535 | BIOS | Booting | Bootloader | C621 | C6211 | C6415 | C671 | C6711 | C6711DSK | C6713 | CCS | Chassaing | COFF | DAT | DM64 | DM642 | DMA | DSK671 | DSK6711 | EDM | EDMA | EMIF | Emulator | EVM | EVM620 | FFT | FIR | GPIO | Halting | HPI | HWI | IDK | JTAG | LDB | LDH | LDW | Linker | LMS | LOG_printf | Matlab | McBSP | MEM_alloc | MIPS | PCI | PCM3003 | Pipeline | Profiling | QDM | Reset | ROM | RTDX | Sampling | SDRAM | Stack | TEB | THS1206 | TMS320C621 | TMS320C6416 | TMS320C6711 | TMS320C6713 | UART | Vector Table | XBUS | XDS560

Hi,
   We are using a DM641 based custom board. We are using M29W160EB 
NOR Flash in the CE1 space of DM641 EMIF-A. We studied the Flash 
datasheet and developed a device driver to read and write from / to Flash 
device. The Flash chip has a Ready/Busy pin which can be connected to 
the ARDY pin of DM641 EMIF. When we program the Flash, the Flash 
chip pulls the DM641 EMIF ARDY pin low indicating that the Flash is busy 
and never recovers from this state. Could you please give some 
suggestions as to why this might happen? I went through all TI EMIF 
documents and the Flash datasheet but of no avail. The EMIF CE1 space 
register is configured for maximum read/write timings. We also tried 
introduing delays in between write commands to Flash but still the Flash 
device hangs. Please let me know your suggestions.

Thanks,
Kalaivani.S

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Hi Group,

Please let me know the resolution for QCCIF.

Thanks in advance,

Regards
Vijay

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Kalaivani,

On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S <k...@yahoo.co.in> wrote:
> Hi,
> We are using a DM641 based custom board. We are using M29W160EB
> NOR Flash in the CE1 space of DM641 EMIF-A. We studied the Flash
> datasheet and developed a device driver to read and write from / to Flash
> device. The Flash chip has a Ready/Busy pin which can be connected to
> the ARDY pin of DM641 EMIF. When we program the Flash, the Flash
> chip pulls the DM641 EMIF ARDY pin low indicating that the Flash is busy
> and never recovers from this state. Could you please give some
> suggestions as to why this might happen? I went through all TI EMIF
> documents and the Flash datasheet but of no avail. The EMIF CE1 space
> register is configured for maximum read/write timings. We also tried
> introduing delays in between write commands to Flash but still the Flash
> device hangs. Please let me know your suggestions.

<mld>
Did you check the flash data sheet carefully??
I have a feeling that you have created a deadlock situation.
Once you start programming the flash, I suspect that it will be busy
for more than 1 memory cycle [I have not checked the data sheet].
The DM641, however, will be 'hung' in a single memory cycle until it
completes. I have not seen this problem with flash because I never use
ARDY when connecting to flash. If you want to test it, I suggest using
it as a status bit. I have seen several 'ARDY hangs' over the years
caused by external devices that resulted in robustness problems - I
will only use ARDY when I understand the logic that it is connected to
and that logic is self clearing.

,mikedunn
>
> Thanks,
> Kalaivani.S

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

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Hi Mike,
     That was a very useful input. We tried removing the ARDY connection to
Flash chip and followed the command interface provided in the datasheet and it
worked really well. 

Thanks,
Kalaivani.S
--- On Fri, 1/9/09, Michael Dunn <m...@gmail.com> wrote:

> From: Michael Dunn <m...@gmail.com>
> Subject: Re: [c6x] Regd. programming Flash using DM641
> To: "Kalaivani.S" <k...@yahoo.co.in>
> Cc: c...@yahoogroups.com
> Date: Friday, January 9, 2009, 12:49 AM
> Kalaivani,
> 
> On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
> <k...@yahoo.co.in> wrote:
> > Hi,
> > We are using a DM641 based custom board. We are using
> M29W160EB
> > NOR Flash in the CE1 space of DM641 EMIF-A. We studied
> the Flash
> > datasheet and developed a device driver to read and
> write from / to Flash
> > device. The Flash chip has a Ready/Busy pin which can
> be connected to
> > the ARDY pin of DM641 EMIF. When we program the Flash,
> the Flash
> > chip pulls the DM641 EMIF ARDY pin low indicating that
> the Flash is busy
> > and never recovers from this state. Could you please
> give some
> > suggestions as to why this might happen? I went
> through all TI EMIF
> > documents and the Flash datasheet but of no avail. The
> EMIF CE1 space
> > register is configured for maximum read/write timings.
> We also tried
> > introduing delays in between write commands to Flash
> but still the Flash
> > device hangs. Please let me know your suggestions.
> 
> <mld>
> Did you check the flash data sheet carefully??
> I have a feeling that you have created a deadlock
> situation.
> Once you start programming the flash, I suspect that it
> will be busy
> for more than 1 memory cycle [I have not checked the data
> sheet].
> The DM641, however, will be 'hung' in a single
> memory cycle until it
> completes. I have not seen this problem with flash because
> I never use
> ARDY when connecting to flash. If you want to test it, I
> suggest using
> it as a status bit. I have seen several 'ARDY
> hangs' over the years
> caused by external devices that resulted in robustness
> problems - I
> will only use ARDY when I understand the logic that it is
> connected to
> and that logic is self clearing.
> 
> ,mikedunn
> >
> > Thanks,
> > Kalaivani.S
> >
> > -- 
> www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Kalaivani,

On Mon, Jan 12, 2009 at 9:24 PM, kalai vani <k...@yahoo.co.in> wrote:
> Hi Mike,
>     That was a very useful input. We tried removing the ARDY connection to
Flash chip and followed the command interface provided in the datasheet and it
worked really well.

<mld>
Thanx for providing the feedback - it can possibly help others [as
well as myself].

mikedunn
>
> Thanks,
> Kalaivani.S
> --- On Fri, 1/9/09, Michael Dunn <m...@gmail.com> wrote:
>
>> From: Michael Dunn <m...@gmail.com>
>> Subject: Re: [c6x] Regd. programming Flash using DM641
>> To: "Kalaivani.S" <k...@yahoo.co.in>
>> Cc: c...@yahoogroups.com
>> Date: Friday, January 9, 2009, 12:49 AM
>> Kalaivani,
>>
>> On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
>> <k...@yahoo.co.in> wrote:
>> > Hi,
>> > We are using a DM641 based custom board. We are using
>> M29W160EB
>> > NOR Flash in the CE1 space of DM641 EMIF-A. We studied
>> the Flash
>> > datasheet and developed a device driver to read and
>> write from / to Flash
>> > device. The Flash chip has a Ready/Busy pin which can
>> be connected to
>> > the ARDY pin of DM641 EMIF. When we program the Flash,
>> the Flash
>> > chip pulls the DM641 EMIF ARDY pin low indicating that
>> the Flash is busy
>> > and never recovers from this state. Could you please
>> give some
>> > suggestions as to why this might happen? I went
>> through all TI EMIF
>> > documents and the Flash datasheet but of no avail. The
>> EMIF CE1 space
>> > register is configured for maximum read/write timings.
>> We also tried
>> > introduing delays in between write commands to Flash
>> but still the Flash
>> > device hangs. Please let me know your suggestions.
>>
>> <mld>
>> Did you check the flash data sheet carefully??
>> I have a feeling that you have created a deadlock
>> situation.
>> Once you start programming the flash, I suspect that it
>> will be busy
>> for more than 1 memory cycle [I have not checked the data
>> sheet].
>> The DM641, however, will be 'hung' in a single
>> memory cycle until it
>> completes. I have not seen this problem with flash because
>> I never use
>> ARDY when connecting to flash. If you want to test it, I
>> suggest using
>> it as a status bit. I have seen several 'ARDY
>> hangs' over the years
>> caused by external devices that resulted in robustness
>> problems - I
>> will only use ARDY when I understand the logic that it is
>> connected to
>> and that logic is self clearing.
>>
>> ,mikedunn
>> >
>> > Thanks,
>> > Kalaivani.S
>> >
>> > 
>>
>> --
>> www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Kalai vani-

>      That was a very useful input. We tried removing the ARDY connection
> to Flash chip and followed the command interface provided in the datasheet
> and it worked really well.

Mike must be on the money (he always is), certainly your device is working now. 
I
would add a comment:  if you did encounter a multicycle hang problem with the
M29W160EB Flash, then other Flash devices may not have the issue, or it could be
the
nature of your software or test procedure.  We've done C64x and C55x designs
where we
connected ARDY to the RY/BY pin on Flash devices and it worked Ok.  Normally the
TI
data sheet says something like "...the processor extends the memory access
by one
cycle and checks ARDY again...".  The general idea is that you make sure
that if you
do a long operation (e.g. erase sector) that your DSP software is in a state
where it
can tolerate waiting (like several msec) and no interrupts or other
time-critical
things are going to occur.  Maybe if you were using JTAG and single-stepping
then you
would violate that.

For other designs, when we were not in that situation, then we connected RY/BY
to a
GPIO pin.

In any case, you should not ignore the ready/busy pin -- for long Flash
operations
you have to check it.

-Jeff

> --- On Fri, 1/9/09, Michael Dunn <m...@gmail.com> wrote:
> 
> > From: Michael Dunn <m...@gmail.com>
> > Subject: Re: [c6x] Regd. programming Flash using DM641
> > To: "Kalaivani.S" <k...@yahoo.co.in>
> > Cc: c...@yahoogroups.com
> > Date: Friday, January 9, 2009, 12:49 AM
> > Kalaivani,
> >
> > On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
> > <k...@yahoo.co.in> wrote:
> > > Hi,
> > > We are using a DM641 based custom board. We are using
> > M29W160EB
> > > NOR Flash in the CE1 space of DM641 EMIF-A. We studied
> > the Flash
> > > datasheet and developed a device driver to read and
> > write from / to Flash
> > > device. The Flash chip has a Ready/Busy pin which can
> > be connected to
> > > the ARDY pin of DM641 EMIF. When we program the Flash,
> > the Flash
> > > chip pulls the DM641 EMIF ARDY pin low indicating that
> > the Flash is busy
> > > and never recovers from this state. Could you please
> > give some
> > > suggestions as to why this might happen? I went
> > through all TI EMIF
> > > documents and the Flash datasheet but of no avail. The
> > EMIF CE1 space
> > > register is configured for maximum read/write timings.
> > We also tried
> > > introduing delays in between write commands to Flash
> > but still the Flash
> > > device hangs. Please let me know your suggestions.
> >
> > <mld>
> > Did you check the flash data sheet carefully??
> > I have a feeling that you have created a deadlock
> > situation.
> > Once you start programming the flash, I suspect that it
> > will be busy
> > for more than 1 memory cycle [I have not checked the data
> > sheet].
> > The DM641, however, will be 'hung' in a single
> > memory cycle until it
> > completes. I have not seen this problem with flash because
> > I never use
> > ARDY when connecting to flash. If you want to test it, I
> > suggest using
> > it as a status bit. I have seen several 'ARDY
> > hangs' over the years
> > caused by external devices that resulted in robustness
> > problems - I
> > will only use ARDY when I understand the logic that it is
> > connected to
> > and that logic is self clearing.
> >
> > ,mikedunn
> > >
> > > Thanks,
> > > Kalaivani.S
> > >
> > >
> >
> >
> >
> > --
> > www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
> 
>
> 
>

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Kalaivani-

>    Could you please clarify your suggestions? If JTAG was not being used
> during Flash sector erase or programming, the
> ARDY connection to Ready/Busy pin would work fine, is it?

I'm not sure.  But I suspect that any external I/O requiring the DSP to "do
something" while it's in the process of
extending an EMIF memory cycle for 100s of usec or even msec could run into
trouble.  Unless you are in "Run Free"
mode, CCS maintains a constant JTAG connection with the DSP.  Even scrolling
your source code view can cause JTAG
commands.  Conflict between JTAG and external peripheral access has been around
for a while.  For example, some
peripherals (like serial ports) have "Free" or similar register bits
that allow them to continue to function when JTAG
is active.  Some, like HPI, tend to get stuck if used when JTAG is active.

> Will ignoring
> the Ready/Busy pin connection affect Flash
> device or DSP in the long run? Instead of using the Ready/Busy pin, the
> Flash device has a Status register which we
> poll periodically to determine if the erase/program operation is
> complete. Will that suffice?

The status register method should work, as long as the Flash device data sheet
clearly indicates the status register
can *always* be read, regardless of what the device is doing.

-Jeff

> --- On Tue, 1/13/09, Jeff Brower <j...@signalogic.com> wrote:
>
> From: Jeff Brower <j...@signalogic.com>
> Subject: Re: [c6x] Regd. programming Flash using DM641
> To: "Kalaivani S" <k...@yahoo.co.in>
> Cc: c...@yahoogroups.com
> Date: Tuesday, January 13, 2009, 12:15 PM
>
> Kalai vani-
>
>>      That was a very useful input. We tried removing the ARDY
connection
>> to Flash chip and followed the command interface provided in the
datasheet
>> and it worked really well.
>
> Mike must be on the money (he always is), certainly your device is working
now.
>  I
> would add a comment:  if you did encounter a multicycle hang problem with
the
> M29W160EB Flash, then other Flash devices may not have the issue, or it
could
> be the
> nature of your software or test procedure.  We've done C64x and C55x
> designs where we
> connected ARDY to the RY/BY pin on Flash devices and it worked Ok. 
Normally
> the TI
> data sheet says something like "...the processor extends the memory
access
> by one
> cycle and checks ARDY again...".  The general idea is that you make
sure
> that if you
> do a long operation (e.g. erase sector) that your DSP software is in a
state
> where it
> can tolerate waiting (like several msec) and no interrupts or other
> time-critical
> things are going to occur.  Maybe if you were using JTAG and
single-stepping
> then you
> would violate that.
>
> For other designs, when we were not in that situation, then we connected
RY/BY
> to a
> GPIO pin.
>
> In any case, you should not ignore the ready/busy pin -- for long Flash
> operations
> you have to check it.
>
> -Jeff
>
>> --- On Fri, 1/9/09, Michael Dunn <m...@gmail.com> wrote:
>>
>> > From: Michael Dunn <m...@gmail.com>
>> > Subject: Re: [c6x] Regd. programming Flash using DM641
>> > To: "Kalaivani.S" <k...@yahoo.co.in>
>> > Cc: c...@yahoogroups.com
>> > Date: Friday, January 9, 2009, 12:49 AM
>> > Kalaivani,
>> >
>> > On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
>> > <k...@yahoo.co.in> wrote:
>> > > Hi,
>> > > We are using a DM641 based custom board. We are using
>> > M29W160EB
>> > > NOR Flash in the CE1 space of DM641 EMIF-A. We studied
>> > the Flash
>> > > datasheet and developed a device driver to read and
>> > write from / to Flash
>> > > device. The Flash chip has a Ready/Busy pin which can
>> > be connected to
>> > > the ARDY pin of DM641 EMIF. When we program the Flash,
>> > the Flash
>> > > chip pulls the DM641 EMIF ARDY pin low indicating that
>> > the Flash is busy
>> > > and never recovers from this state. Could you please
>> > give some
>> > > suggestions as to why this might happen? I went
>> > through all TI EMIF
>> > > documents and the Flash datasheet but of no avail. The
>> > EMIF CE1 space
>> > > register is configured for maximum read/write timings.
>> > We also tried
>> > > introduing delays in between write commands to Flash
>> > but still the Flash
>> > > device hangs. Please let me know your suggestions.
>> >
>> > <mld>
>> > Did you check the flash data sheet carefully??
>> > I have a feeling that you have created a deadlock
>> > situation.
>> > Once you start programming the flash, I suspect that it
>> > will be busy
>> > for more than 1 memory cycle [I have not checked the data
>> > sheet].
>> > The DM641, however, will be 'hung' in a single
>> > memory cycle until it
>> > completes. I have not seen this problem with flash because
>> > I never use
>> > ARDY when connecting to flash. If you want to test it, I
>> > suggest using
>> > it as a status bit. I have seen several 'ARDY
>> > hangs' over the years
>> > caused by external devices that resulted in robustness
>> > problems - I
>> > will only use ARDY when I understand the logic that it is
>> > connected to
>> > and that logic is self clearing.
>> >
>> > ,mikedunn
>> > >
>> > > Thanks,
>> > > Kalaivani.S
>> > >
>> > >
>> >
>> >
>> >
>> > --
>> > www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
>>
>>
>>
>> _____________________________________
>>
>

_____________________________________

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Kalaivani,

On Mon, Jan 19, 2009 at 9:51 AM, Jeff Brower <j...@signalogic.com> wrote:
> Kalaivani-
>
>>    Could you please clarify your suggestions? If JTAG was not being
used
>> during Flash sector erase or programming, the
>> ARDY connection to Ready/Busy pin would work fine, is it?
>
> I'm not sure. But I suspect that any external I/O requiring the DSP to
"do
> something" while it's in the process of
> extending an EMIF memory cycle for 100s of usec or even msec could run
into
> trouble. Unless you are in "Run Free"
> mode, CCS maintains a constant JTAG connection with the DSP. Even
scrolling
> your source code view can cause JTAG
> commands. Conflict between JTAG and external peripheral access has been
> around for a while. For example, some
> peripherals (like serial ports) have "Free" or similar register
bits that
> allow them to continue to function when JTAG
> is active. Some, like HPI, tend to get stuck if used when JTAG is active.

<mld>
Jeff is correct. JTAG commands can only occur between instructions.
When ARDY is used, the particular instruction is 'in progress' and is
not complete until the end of the memory cycle - therefore, no JTAG
access. Like Jeff said, the info that is displayed by CCS is obtained
using JTAG target accesses - any CCS change causing a screen update
will result in JTAG accesses.  Normally, you should not mix long ARDY
cycles with JTAG debugging.

mikedunn
>
>> Will ignoring
>> the Ready/Busy pin connection affect Flash
>> device or DSP in the long run? Instead of using the Ready/Busy pin,
the
>> Flash device has a Status register which we
>> poll periodically to determine if the erase/program operation is
>> complete. Will that suffice?
>
> The status register method should work, as long as the Flash device data
> sheet clearly indicates the status register
> can *always* be read, regardless of what the device is doing.
>
> -Jeff
>
>> --- On Tue, 1/13/09, Jeff Brower <j...@signalogic.com> wrote:
>>
>> From: Jeff Brower <j...@signalogic.com>> Subject: Re: [c6x]
Regd. programming Flash using DM641
>> To: "Kalaivani S" <k...@yahoo.co.in>
>> Cc: c...@yahoogroups.com
>> Date: Tuesday, January 13, 2009, 12:15 PM
>>
>> Kalai vani-
>>
>>> That was a very useful input. We tried removing the ARDY
connection
>>> to Flash chip and followed the command interface provided in the
>>> datasheet
>>> and it worked really well.
>>
>> Mike must be on the money (he always is), certainly your device is
working
>> now.
>> I
>> would add a comment: if you did encounter a multicycle hang problem
with
>> the
>> M29W160EB Flash, then other Flash devices may not have the issue, or
it
>> could
>> be the
>> nature of your software or test procedure. We've done C64x and C55x
>> designs where we
>> connected ARDY to the RY/BY pin on Flash devices and it worked Ok.
>> Normally
>> the TI
>> data sheet says something like "...the processor extends the
memory access
>> by one
>> cycle and checks ARDY again...". The general idea is that you make
sure
>> that if you
>> do a long operation (e.g. erase sector) that your DSP software is in a
>> state
>> where it
>> can tolerate waiting (like several msec) and no interrupts or other
>> time-critical
>> things are going to occur. Maybe if you were using JTAG and
>> single-stepping
>> then you
>> would violate that.
>>
>> For other designs, when we were not in that situation, then we
connected
>> RY/BY
>> to a
>> GPIO pin.
>>
>> In any case, you should not ignore the ready/busy pin -- for long
Flash
>> operations
>> you have to check it.
>>
>> -Jeff
>>
>>> --- On Fri, 1/9/09, Michael Dunn <m...@gmail.com> wrote:
>>>
>>> > From: Michael Dunn <m...@gmail.com>
>>> > Subject: Re: [c6x] Regd. programming Flash using DM641
>>> > To: "Kalaivani.S" <k...@yahoo.co.in>
>>> > Cc: c...@yahoogroups.com
>>> > Date: Friday, January 9, 2009, 12:49 AM
>>> > Kalaivani,
>>> >
>>> > On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
>>> > <k...@yahoo.co.in> wrote:
>>> > > Hi,
>>> > > We are using a DM641 based custom board. We are using
>>> > M29W160EB
>>> > > NOR Flash in the CE1 space of DM641 EMIF-A. We studied
>>> > the Flash
>>> > > datasheet and developed a device driver to read and
>>> > write from / to Flash
>>> > > device. The Flash chip has a Ready/Busy pin which can
>>> > be connected to
>>> > > the ARDY pin of DM641 EMIF. When we program the Flash,
>>> > the Flash
>>> > > chip pulls the DM641 EMIF ARDY pin low indicating that
>>> > the Flash is busy
>>> > > and never recovers from this state. Could you please
>>> > give some
>>> > > suggestions as to why this might happen? I went
>>> > through all TI EMIF
>>> > > documents and the Flash datasheet but of no avail. The
>>> > EMIF CE1 space
>>> > > register is configured for maximum read/write timings.
>>> > We also tried
>>> > > introduing delays in between write commands to Flash
>>> > but still the Flash
>>> > > device hangs. Please let me know your suggestions.
>>> >
>>> > <mld>
>>> > Did you check the flash data sheet carefully??
>>> > I have a feeling that you have created a deadlock
>>> > situation.
>>> > Once you start programming the flash, I suspect that it
>>> > will be busy
>>> > for more than 1 memory cycle [I have not checked the data
>>> > sheet].
>>> > The DM641, however, will be 'hung' in a single
>>> > memory cycle until it
>>> > completes. I have not seen this problem with flash because
>>> > I never use
>>> > ARDY when connecting to flash. If you want to test it, I
>>> > suggest using
>>> > it as a status bit. I have seen several 'ARDY
>>> > hangs' over the years
>>> > caused by external devices that resulted in robustness
>>> > problems - I
>>> > will only use ARDY when I understand the logic that it is
>>> > connected to
>>> > and that logic is self clearing.
>>> >
>>> > ,mikedunn
>>> > >
>>> > > Thanks,
>>> > > Kalaivani.S
>>> > >
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>> _____________________________________
>>> 
>>>
>>>
>
-- 
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

_____________________________________

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Jeff,
=A0=A0 Could you please clarify your suggestions? If JTAG was not being use=
d during Flash sector erase or programming, the ARDY connection to Ready/Bu=
sy pin would work fine, is it? Will ignoring the Ready/Busy pin connection =
affect Flash device or DSP in the long run? Instead of using the Ready/Busy=
 pin, the Flash device has a Status register which we poll periodically to =
determine if the erase/program operation is complete. Will that suffice?

Thanks,
Kalaivani.S

--- On Tue, 1/13/09, Jeff Brower <j...@signalogic.com> wrote:

From: Jeff Brower <j...@signalogic.com>
Subject: Re: [c6x] Regd. programming Flash using DM641
To: "Kalaivani S" <k...@yahoo.co.in>
Cc: c...@yahoogroups.com
Date: Tuesday, January 13, 2009, 12:15 PM

Kalai vani-

>      That was a very useful input. We tried removing the ARDY connection
> to Flash chip and followed the command interface provided in the datashee=
t
> and it worked really well.

Mike must be on the money (he always is), certainly your device is working =
now.
 I
would add a comment:  if you did encounter a multicycle hang problem with t=
he
M29W160EB Flash, then other Flash devices may not have the issue, or it cou=
ld
be the
nature of your software or test procedure.  We've done C64x and C55x
designs where we
connected ARDY to the RY/BY pin on Flash devices and it worked Ok.  Normall=
y
the TI
data sheet says something like "...the processor extends the memory access
by one
cycle and checks ARDY again...".  The general idea is that you make sure
that if you
do a long operation (e.g. erase sector) that your DSP software is in a stat=
e
where it
can tolerate waiting (like several msec) and no interrupts or other
time-critical
things are going to occur.  Maybe if you were using JTAG and single-steppin=
g
then you
would violate that.

For other designs, when we were not in that situation, then we connected RY=
/BY
to a
GPIO pin.

In any case, you should not ignore the ready/busy pin -- for long Flash
operations
you have to check it.

-Jeff

> --- On Fri, 1/9/09, Michael Dunn <m...@gmail.com> wrote:
>=20
> > From: Michael Dunn <m...@gmail.com>
> > Subject: Re: [c6x] Regd. programming Flash using DM641
> > To: "Kalaivani.S" <k...@yahoo.co.in>
> > Cc: c...@yahoogroups.com
> > Date: Friday, January 9, 2009, 12:49 AM
> > Kalaivani,
> >
> > On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
> > <k...@yahoo.co.in> wrote:
> > > Hi,
> > > We are using a DM641 based custom board. We are using
> > M29W160EB
> > > NOR Flash in the CE1 space of DM641 EMIF-A. We studied
> > the Flash
> > > datasheet and developed a device driver to read and
> > write from / to Flash
> > > device. The Flash chip has a Ready/Busy pin which can
> > be connected to
> > > the ARDY pin of DM641 EMIF. When we program the Flash,
> > the Flash
> > > chip pulls the DM641 EMIF ARDY pin low indicating that
> > the Flash is busy
> > > and never recovers from this state. Could you please
> > give some
> > > suggestions as to why this might happen? I went
> > through all TI EMIF
> > > documents and the Flash datasheet but of no avail. The
> > EMIF CE1 space
> > > register is configured for maximum read/write timings.
> > We also tried
> > > introduing delays in between write commands to Flash
> > but still the Flash
> > > device hangs. Please let me know your suggestions.
> >
> > <mld>
> > Did you check the flash data sheet carefully??
> > I have a feeling that you have created a deadlock
> > situation.
> > Once you start programming the flash, I suspect that it
> > will be busy
> > for more than 1 memory cycle [I have not checked the data
> > sheet].
> > The DM641, however, will be 'hung' in a single
> > memory cycle until it
> > completes. I have not seen this problem with flash because
> > I never use
> > ARDY when connecting to flash. If you want to test it, I
> > suggest using
> > it as a status bit. I have seen several 'ARDY
> > hangs' over the years
> > caused by external devices that resulted in robustness
> > problems - I
> > will only use ARDY when I understand the logic that it is
> > connected to
> > and that logic is self clearing.
> >
> > ,mikedunn
> > >
> > > Thanks,
> > > Kalaivani.S
> > >
> > >
> >
> >
> >
> > --
> > www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
>=20

_____________________________________

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )