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
Regd. programming Flash using DM641
Started by ●January 8, 2009
Reply by ●January 8, 20092009-01-08
Reply by ●January 8, 20092009-01-08
Kalaivani,
On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S 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.
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
On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S 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.
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
Reply by ●January 13, 20092009-01-13
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 wrote:
> From: Michael Dunn
> Subject: Re: [c6x] Regd. programming Flash using DM641
> To: "Kalaivani.S"
> Cc: c...
> Date: Friday, January 9, 2009, 12:49 AM
> Kalaivani,
>
> On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
> 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.
>
>
> 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
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 wrote:
> From: Michael Dunn
> Subject: Re: [c6x] Regd. programming Flash using DM641
> To: "Kalaivani.S"
> Cc: c...
> Date: Friday, January 9, 2009, 12:49 AM
> Kalaivani,
>
> On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
> 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.
>
>
> 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
Reply by ●January 13, 20092009-01-13
Kalaivani,
On Mon, Jan 12, 2009 at 9:24 PM, kalai vani 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.
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 wrote:
>
>> From: Michael Dunn
>> Subject: Re: [c6x] Regd. programming Flash using DM641
>> To: "Kalaivani.S"
>> Cc: c...
>> Date: Friday, January 9, 2009, 12:49 AM
>> Kalaivani,
>>
>> On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
>> 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.
>>
>>
>> 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
On Mon, Jan 12, 2009 at 9:24 PM, kalai vani 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.
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 wrote:
>
>> From: Michael Dunn
>> Subject: Re: [c6x] Regd. programming Flash using DM641
>> To: "Kalaivani.S"
>> Cc: c...
>> Date: Friday, January 9, 2009, 12:49 AM
>> Kalaivani,
>>
>> On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
>> 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.
>>
>>
>> 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
Reply by ●January 13, 20092009-01-13
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 wrote:
>
> > From: Michael Dunn
> > Subject: Re: [c6x] Regd. programming Flash using DM641
> > To: "Kalaivani.S"
> > Cc: c...
> > Date: Friday, January 9, 2009, 12:49 AM
> > Kalaivani,
> >
> > On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
> > 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.
> >
> >
> > 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
>
>
>
>
> 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 wrote:
>
> > From: Michael Dunn
> > Subject: Re: [c6x] Regd. programming Flash using DM641
> > To: "Kalaivani.S"
> > Cc: c...
> > Date: Friday, January 9, 2009, 12:49 AM
> > Kalaivani,
> >
> > On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
> > 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.
> >
> >
> > 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
>
>
>
>
Reply by ●January 19, 20092009-01-19
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 wrote:
>
> From: Jeff Brower
> Subject: Re: [c6x] Regd. programming Flash using DM641
> To: "Kalaivani S"
> Cc: c...
> 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 wrote:
>>
>> > From: Michael Dunn
>> > Subject: Re: [c6x] Regd. programming Flash using DM641
>> > To: "Kalaivani.S"
>> > Cc: c...
>> > Date: Friday, January 9, 2009, 12:49 AM
>> > Kalaivani,
>> >
>> > On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
>> > 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.
>> >
>> >
>> > 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
>>
>>
>>
>> _____________________________________
>>
>
_____________________________________
> 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 wrote:
>
> From: Jeff Brower
> Subject: Re: [c6x] Regd. programming Flash using DM641
> To: "Kalaivani S"
> Cc: c...
> 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 wrote:
>>
>> > From: Michael Dunn
>> > Subject: Re: [c6x] Regd. programming Flash using DM641
>> > To: "Kalaivani.S"
>> > Cc: c...
>> > Date: Friday, January 9, 2009, 12:49 AM
>> > Kalaivani,
>> >
>> > On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
>> > 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.
>> >
>> >
>> > 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
>>
>>
>>
>> _____________________________________
>>
>
_____________________________________
Reply by ●January 19, 20092009-01-19
Kalaivani,
On Mon, Jan 19, 2009 at 9:51 AM, Jeff Brower 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.
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 wrote:
>>
>> From: Jeff Brower > Subject: Re: [c6x] Regd. programming Flash using DM641
>> To: "Kalaivani S"
>> Cc: c...
>> 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 wrote:
>>>
>>> > From: Michael Dunn
>>> > Subject: Re: [c6x] Regd. programming Flash using DM641
>>> > To: "Kalaivani.S"
>>> > Cc: c...
>>> > Date: Friday, January 9, 2009, 12:49 AM
>>> > Kalaivani,
>>> >
>>> > On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
>>> > 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.
>>> >
>>> >
>>> > 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
_____________________________________
On Mon, Jan 19, 2009 at 9:51 AM, Jeff Brower 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.
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 wrote:
>>
>> From: Jeff Brower > Subject: Re: [c6x] Regd. programming Flash using DM641
>> To: "Kalaivani S"
>> Cc: c...
>> 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 wrote:
>>>
>>> > From: Michael Dunn
>>> > Subject: Re: [c6x] Regd. programming Flash using DM641
>>> > To: "Kalaivani.S"
>>> > Cc: c...
>>> > Date: Friday, January 9, 2009, 12:49 AM
>>> > Kalaivani,
>>> >
>>> > On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
>>> > 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.
>>> >
>>> >
>>> > 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
_____________________________________
Reply by ●January 19, 20092009-01-19
Jeff,
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? 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 wrote:
From: Jeff Brower
Subject: Re: [c6x] Regd. programming Flash using DM641
To: "Kalaivani S"
Cc: c...
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 wrote:
>
> > From: Michael Dunn
> > Subject: Re: [c6x] Regd. programming Flash using DM641
> > To: "Kalaivani.S"
> > Cc: c...
> > Date: Friday, January 9, 2009, 12:49 AM
> > Kalaivani,
> >
> > On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
> > 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.
> >
> >
> > 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
>
_____________________________________
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? 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 wrote:
From: Jeff Brower
Subject: Re: [c6x] Regd. programming Flash using DM641
To: "Kalaivani S"
Cc: c...
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 wrote:
>
> > From: Michael Dunn
> > Subject: Re: [c6x] Regd. programming Flash using DM641
> > To: "Kalaivani.S"
> > Cc: c...
> > Date: Friday, January 9, 2009, 12:49 AM
> > Kalaivani,
> >
> > On Wed, Jan 7, 2009 at 11:20 PM, Kalaivani.S
> > 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.
> >
> >
> > 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
>
_____________________________________
