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

I'm having problems w/ 6413 interface to ColdFire. HRDY always seems 
low.  During busy (120Khz dsp isr moving 20words each tick) dsp 
periods, the HPI reads (by CF) seem to give corrupt data.. on scope we 
see HPI data line timing vary widely.  If we pust DSP hard enough HRDY 
will go HIGH for 100's of ms??  From that point on HPI seems "dead" to

CF.

______________________________
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 )

E Hillen-

> I'm having problems w/ 6413 interface to ColdFire. HRDY always seems
> low.  During busy (120Khz dsp isr moving 20words each tick) dsp
> periods, the HPI reads (by CF) seem to give corrupt data.. on scope we
> see HPI data line timing vary widely.  If we pust DSP hard enough HRDY
> will go HIGH for 100's of ms??  From that point on HPI seems
"dead" to
> CF.

Without the ISR enabled, does HPI operate normally?  Can CF run a complete mem
diagnostic on C641x and verify both auto-increment and non-auto-increment
access?

-Jeff

______________________________
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 )

I can reproduce problem in DSPBios Task (w/ sleep delay).  Either way, most
of the time the CF can write and/or read ok; it is only when I push either the
frequency (if I use task or ISR) or the word count.  As I approach some
bandwidth the HPI data begins to go bad.  It seems like it starts w/ one or two
transfers and then all HPI data is wrong (on reads).  I have scope traces on
several HPI lines and can see that at times the HPI data lines (during CF reads)
are at a high (logic 1) state when they should be low?  This causes 0's to be
read as 1's.

  TI tech support is looking into it but so far they've only suggested I tried
disabling the DSP cache (I guess to avoid EDMA contention); this is not an
option for me. Besides, I tried marking SDRAM MAR as clear making SDRAM
non-cached.  This eliminates problem when I use cpu to move mem to/from DSP
SDRAM but I still have problems if I use QDMA (instead of CPU for loop).
   
  It seems to me that under high bw cases the edma causes problems w/ HPI.  I'd
expect the HPI to stall now and then but would also expect the HRDY line to
work.
  
Jeff Brower <j...@signalogic.com> wrote:
  E Hillen-

> I'm having problems w/ 6413 interface to ColdFire. HRDY always seems
> low. During busy (120Khz dsp isr moving 20words each tick) dsp
> periods, the HPI reads (by CF) seem to give corrupt data.. on scope we
> see HPI data line timing vary widely. If we pust DSP hard enough HRDY
> will go HIGH for 100's of ms?? From that point on HPI seems
"dead" to
> CF.

Without the ISR enabled, does HPI operate normally? Can CF run a complete mem
diagnostic on C641x and verify both auto-increment and non-auto-increment
access?

-Jeff
			
---------------------------------
Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.

______________________________
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 )

Ed-

My guess is you're still not using HRDY correctly.  When internal DMA bandwidth
is
low, then no problem -- you think the port is ready, and it is.  When internal
DMA is
busy, then you attempt HPI access when you should not, causing the internal HPI
state
machine to lock.  I say this because I've been in that situation before.

Are you asserting /HCS prior to checking HRDY?  This is a common error. 
Another
helpful thing to try is make sure your HPI accesses are only going to internal
memory; if you use external target addresses, then cache, snooping and other
circuitry gets in the picture and that's going to cloud the issue.

-Jeff
> I can reproduce problem in DSPBios Task (w/ sleep delay).  Either way, most
of the
> time the CF can write and/or read ok; it is only when I push either the
frequency
> (if I use task or ISR) or the word count.  As I approach some bandwidth the
HPI
> data begins to go bad.  It seems like it starts w/ one or two transfers and
then
> all HPI data is wrong (on reads).  I have scope traces on several HPI lines
and can
> see that at times the HPI data lines (during CF reads) are at a high (logic
1)
> state when they should be low?  This causes 0's to be read as 1's.TI tech
support
> is looking into it but so far they've only suggested I tried disabling the
DSP
> cache (I guess to avoid EDMA contention); this is not an option for me.
Besides, I
> tried marking SDRAM MAR as clear making SDRAM non-cached.  This eliminates
problem
> when I use cpu to move mem to/from DSP SDRAM but I still have problems if I
use
> QDMA (instead of CPU for loop). It seems to me that under high bw cases the
edma
> causes problems w/ HPI.  I'd expect the HPI to stall now and then but would
also
> expect the HRDY line to work.
> Jeff Brower <j...@signalogic.com> wrote:
>
>      E Hillen-
>
>      > I'm having problems w/ 6413 interface to ColdFire. HRDY always
seems
>      > low. During busy (120Khz dsp isr moving 20words each tick) dsp
>      > periods, the HPI reads (by CF) seem to give corrupt data.. on
scope we
>      > see HPI data line timing vary widely. If we pust DSP hard enough
HRDY
>      > will go HIGH for 100's of ms?? From that point on HPI seems
"dead" to
>      > CF.
>
>      Without the ISR enabled, does HPI operate normally? Can CF run a
complete
>      mem
>      diagnostic on C641x and verify both auto-increment and
non-auto-increment
>      access?
>
>      -Jeff
>
>
--------------------------------------------------------------------------------
----
> Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.

______________________________
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 )

We assert HCS before checking HRDY.  We basically NEVER see it high (not
ready).  We are using 32 bit HPI. I need to use HPI to SDRAM; I realize this
clouds the issues but are you saying that when using cached SDRAM HPI doesn't
work?  Anyhow, we see problems w/ L2RAM (HPI accesses) when using QDMA to move
L2RAM to L2RAM (I realized using QDMA to move internal RAM is dumb but I do it
to prove that it's not just SDRAM but L2RAM). 
   
  Even when the CF successfully reads and/or writes 6413 memory the HRDY NEVER
goes high (not ready)?  Have you heard of the HPI bus signals becomming damaged
(maybe due to a problem in pcboard design)?  I see alot of stuff in the various
newsgroups about "stuck" HRDY lines.

Jeff Brower <j...@signalogic.com> wrote:
  Ed-   My guess is you're still not using HRDY correctly.  When internal DMA
bandwidth is low, then no problem -- you think the port is ready, and it is. 
When internal DMA is busy, then you attempt HPI access when you should not,
causing the internal HPI state machine to lock.  I say this because I've been in
that situation before.   Are you asserting /HCS prior to checking HRDY?  This is
a common error.  Another helpful thing to try is make sure your HPI accesses are
only going to internal memory; if you use external target addresses, then cache,
snooping and other circuitry gets in the picture and that's going to cloud the
issue.   -Jeff 
    I can reproduce problem in DSPBios Task (w/ sleep delay).  Either way, most
of the time the CF can write and/or read ok; it is only when I push either the
frequency (if I use task or ISR) or the word count.  As I approach some
bandwidth the HPI data begins to go bad.  It seems like it starts w/ one or two
transfers and then all HPI data is wrong (on reads).  I have scope traces on
several HPI lines and can see that at times the HPI data lines (during CF reads)
are at a high (logic 1) state when they should be low?  This causes 0's to be
read as 1's.TI tech support is looking into it but so far they've only suggested
I tried disabling the DSP cache (I guess to avoid EDMA contention); this is not
an option for me. Besides, I tried marking SDRAM MAR as clear making SDRAM
non-cached.  This eliminates problem when I use cpu to move mem to/from DSP
SDRAM but I still have problems if I use QDMA (instead of CPU for loop). It
seems to me that under high bw cases the edma causes problems
 w/ HPI.  I'd expect the HPI to stall now and then but would also expect the
HRDY line to work.

Jeff Brower <j...@signalogic.com> wrote:   E Hillen-   > I'm having
problems w/ 6413 interface to ColdFire. HRDY always seems 
> low. During busy (120Khz dsp isr moving 20words each tick) dsp 
> periods, the HPI reads (by CF) seem to give corrupt data.. on scope we 
> see HPI data line timing vary widely. If we pust DSP hard enough HRDY 
> will go HIGH for 100's of ms?? From that point on HPI seems
"dead" to 
> CF.   Without the ISR enabled, does HPI operate normally? Can CF run a
complete mem 
diagnostic on C641x and verify both auto-increment and non-auto-increment
access?   -Jeff
    
---------------------------------
  Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.

---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.

______________________________
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 )

This is a tricky area. EDMA transfers can interact with HPI transfers.
I would look at spraaoo.pdf and spra996.pdf.

What does "approach some bandwidth" mean ?
Do you have some numbers here ?

- Andrew E.

Ed Hillen wrote:

> We assert HCS before checking HRDY.  We basically NEVER see it high 
> (not ready).  We are using 32 bit HPI. I need to use HPI to SDRAM; I 
> realize this clouds the issues but are you saying that when using 
> cached SDRAM HPI doesn't work?  Anyhow, we see problems w/ L2RAM (HPI 
> accesses) when using QDMA to move L2RAM to L2RAM (I realized using 
> QDMA to move internal RAM is dumb but I do it to prove that it's not 
> just SDRAM but L2RAM). 
>  
> Even when the CF successfully reads and/or writes 6413 memory the HRDY 
> NEVER goes high (not ready)?  Have you heard of the HPI bus signals 
> becomming damaged (maybe due to a problem in pcboard design)?  I see 
> alot of stuff in the various newsgroups about "stuck" HRDY
lines.
>
> */Jeff Brower <j...@signalogic.com>/* wrote:
>
>     Ed-
>     My guess is you're still not using HRDY correctly.  When internal
>     DMA bandwidth is low, then no problem -- you think the port is
>     ready, and it is.  When internal DMA is busy, then you attempt HPI
>     access when you should not, causing the internal HPI state machine
>     to lock.  I say this because I've been in that situation before.
>     Are you asserting /HCS prior to checking HRDY?  This is a common
>     error.  Another helpful thing to try is make sure your HPI
>     accesses are only going to internal memory; if you use external
>     target addresses, then cache, snooping and other circuitry gets in
>     the picture and that's going to cloud the issue.
>     -Jeff
>      
>
>>     I can reproduce problem in DSPBios Task (w/ sleep delay).  Either
>>     way, most of the time the CF can write and/or read ok; it is only
>>     when I push either the frequency (if I use task or ISR) or the
>>     word count.  As I approach some bandwidth the HPI data begins to
>>     go bad.  It seems like it starts w/ one or two transfers and then
>>     all HPI data is wrong (on reads).  I have scope traces on several
>>     HPI lines and can see that at times the HPI data lines (during CF
>>     reads) are at a high (logic 1) state when they should be low? 
>>     This causes 0's to be read as 1's.TI tech support is looking into
>>     it but so far they've only suggested I tried disabling the DSP
>>     cache (I guess to avoid EDMA contention); this is not an option
>>     for me. Besides, I tried marking SDRAM MAR as clear making SDRAM
>>     non-cached.  This eliminates problem when I use cpu to move mem
>>     to/from DSP SDRAM but I still have problems if I use QDMA
>>     (instead of CPU for loop). It seems to me that under high bw
>>     cases the edma causes problems w/ HPI.  I'd expect the HPI to
>>     stall now and then but would also expect the HRDY line to work.
>>      
>>       
>>     */Jeff Brower <j...@signalogic.com>/* wrote:
>>
>>         E Hillen-
>>         > I'm having problems w/ 6413 interface to ColdFire. HRDY
>>         always seems
>>         > low. During busy (120Khz dsp isr moving 20words each tick)
dsp
>>         > periods, the HPI reads (by CF) seem to give corrupt
data..
>>         on scope we
>>         > see HPI data line timing vary widely. If we pust DSP hard
>>         enough HRDY
>>         > will go HIGH for 100's of ms?? From that point on HPI
seems
>>         "dead" to
>>         > CF.
>>         Without the ISR enabled, does HPI operate normally? Can CF
>>         run a complete mem
>>         diagnostic on C641x and verify both auto-increment and
>>         non-auto-increment access?
>>         -Jeff
>>
>>    
------------------------------------------------------------------------
>>     Yahoo! Messenger with Voice.
>>    
<http://us.rd.yahoo.com/mail_us/taglines/postman3/*http://us.rd.yahoo.com/evt
=39666/*http://beta.messenger.yahoo.com>
>>     PC-to-Phone calls for ridiculously low rates.
> ------------------------------------------------------------------------
> New Yahoo! Messenger with Voice. Call regular phones from your PC 
>
<http://us.rd.yahoo.com/mail_us/taglines/postman5/*http://us.rd.yahoo.com/evt
=39666/*http://beta.messenger.yahoo.com%20> 
> and save big.
>
>     
> ------------------------------------------------------------------------
>

______________________________
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 )

Ed-

> We assert HCS before checking HRDY.  We basically NEVER see it
> high (not ready).  We are using 32 bit HPI. I need to use HPI
> to SDRAM; I realize this clouds the issues but are you saying
> that when using cached SDRAM HPI doesn't work?  Anyhow, we see
> problems w/ L2RAM (HPI accesses) when using QDMA to move L2RAM
> to L2RAM (I realized using QDMA to move internal RAM is dumb
> but I do it to prove that it's not just SDRAM but L2RAM).

It's just not possible to never see HRDY high -- that would not match any of
the
C6xxx devices we've worked with (C6x01, C6203, C6x11, C6x13, C641x).  Even for
simple
read accesses to internal mem, the first time some random location is read,
there has
to be a short wait period as that data can't possibly already be in the HPI
FIFO,
right?

I don't see anything in the C6413 errata.  I would focus on the hardware.  Is
this an
in-house board design?  Just one C6413 or multiple?  Is HRDY connected to an
FPGA?
Did you put a pull-up/pull-down R on HRDY?  If so what value?

Also, what is your definition of "successfully reads C6413 memory"? 
Did you try a
simple test like using CCS to change a location, then read it using HPI?

-Jeff
>
>   Even when the CF successfully reads and/or writes 6413 memory the HRDY
NEVER goes
> high (not ready)?  Have you heard of the HPI bus signals becomming damaged
(maybe
> due to a problem in pcboard design)?  I see alot of stuff in the various
newsgroups
> about "stuck" HRDY lines.
>
> Jeff Brower <j...@signalogic.com> wrote:
>
>      Ed-My guess is you'r e still not using HRDY correctly.  When internal
DMA
>      bandwidth is low, then no problem -- you think the port is ready, and
it
>      is.  When internal DMA is busy, then you attempt HPI access when you
>      should not, causing the internal HPI state machine to lock.  I say
this
>      because I've been in that situation before.Are you asserting /HCS
prior
>      to checking HRDY?  This is a common error.  Another helpful thing to
try
>      is make sure your HPI accesses are only going to internal memory; if
you
>      use external target addresses, then cache, snooping and other
circuitry
>      gets in the picture and that's going to cloud the issue.-Jeff
>     > I can reproduce problem in DSPBios Task (w/ sleep delay).  Either
way,
>     > most of the time the CF can write and/or read ok; it is only when
I
>     > push either the frequency (if I use task or ISR) or the word
count.  As
>     > I approach some bandwidth the HPI data begins to go bad.  It seems
like
>     > it starts w/ one or two transfers and then all HPI data is wrong
(on
>     > reads).  I have scope traces on several HPI lines and can see that
at
>     > times the HPI data lines (during CF reads) are at a high (logic
1)
>     > state when they should be low?  This causes 0's to be read as
1's.TI
>     > tech support is looking into it but so far they've only suggested
I
>     > tried disabling the DSP cache (I guess to avoid EDMA contention);
this
>     > is not an option for me. Besides, I tried marking SDRAM MAR as
clear
>     > making SDRAM non-cached.  This eliminates problem when I use cpu
to
>     > move mem to/from DSP SDRAM but I still have problems if I use
QDMA
>     > (instead of CPU for loop). It seems to me that under high bw cases
the
>     > edma causes problems w/ HPI.  I'd expect the HPI to stall now and
then
>     > but would also expect the HRDY line to work.
>     >
>     >
>     > Jeff Brower <j...@signalogic.com> wrote:
>     >
>     >      E Hillen-> I'm having problems w/ 6413 interface to
ColdFire.
>     >      HRDY always seems
>     >      > low. During busy (120Khz dsp isr moving 20words each
tick)
>     >      dsp
>     >      > periods, the HPI reads (by CF) seem to give corrupt
data..
>     >      on scope we
>     >      > see HPI data line timing vary widely. If we pust DSP
hard
>     >      enough HRDY
>     >      > will go HIGH for 100's of ms?? From that point on HPI
seems
>     >      "dead" to
>     >      > CF.Without the ISR enabled, does HPI operate normally?
Can
>     >      CF run a complete mem
>     >      diagnostic on C641x and verify both auto-increment and
>     >      non-auto-increment access?-Jeff
>     >

______________________________
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 )