--- In c6x@y..., gary.halfyard@b... wrote: > Doing an L2 cache flush (manually using CCS) before examining the > buffer in CCS should then mean that the correct data can be seen (I > haven't tried this yet). I have found my bugs: - instead of CACHE_Flush(CACHE_L2) I should invoke CACHE_Clean(CACHE_L2) CSL function. CACHE_Flush() does not invalidate data in cache, therefore cache hit can occur at later accesses. This was my case: altough the buffer was flushed but I have accessed its data directly in cache. - CACHE_Flush() was invoked not only after buffer initialization but e.g. in Transmit Complete ISR. This is wrong: CACHE_Flush() can overwite the buffer by its previous cached content. Thanks & take care Gabor

I think I have the answer now, courtesy of TI Technical support and a little research of my own. The problem seems to be that the CPU, which controls the operation of the cache, does not know that the EDMA has altered the destination buffer and does not update its cache to reflect it. Examining the contents of the buffer using CCS then just reads the cache (which contains my original default values). Doing an L2 cache flush (manually using CCS) before examining the buffer in CCS should then mean that the correct data can be seen (I haven't tried this yet). Disabling the L2 cache (and even modifying its size) also resulted in correct operation. My solution is to move my destination buffer into internal memory (there are other reasons for me to do this as well). Good luck ! Gary --- In c6x@y..., Andrew Elder <andrew_elder@b...> wrote: > > Gabor, > > I assume you are taking care to do an L2 cache flush before > running the Tx side ? I got caught out with that one ! > > Andrew

Andrew, I have found, that if - both src/dst buffer is in internal RAM, rcv buffer is correct - both src/dst buffer is in external RAM but L2 cache is not used, rcv buffer is correct - both src/dst buffer is in external RAM but L2 cache is enabled, rcv buffer is empty > I assume you are taking care to do an L2 cache flush before > running the Tx side ? I got caught out with that one ! L2 cache is flushed out using CSL call after stopping DMA but before reading rcv buffer to check if it is empty or not. Gabor

--- In c6x@y..., gary.halfyard@b... wrote: > Can you try manually editing the reload parameters for your EDMA > channel to point to some other location in memory (whilst the DMA is > running). I did this (changed the destination pointer to 0x80300000) > and all data was transfered correctly. I did it too, but I have not recognised any change in my test: receiver buffer is empty after changing dst memory directly in the EDMA reload parameter structure during DMA. But if I change my L2 cache configuration in DSP/BIOS II, my tests show some differencies: - without L2 caching (Global Settings: L2 Mode = SRAM, L2 MAR0-15 = 0x0000) receive buffer in external memory has been filled in correctly - with L2 caching (Global Settings: L2 Mode = 2-way cache, L2 MAR0-15 = 0x0001) receive buffer in external memory is empty again. I tried L2 flush but without success. > I am very interested in the fact that it works OK if not using > DSP/BIOS. Can you force the destination address to be the same in > both cases and see whether that makes a difference ?? I did it; no difference in my cases. So, my feeling is that we have problems with L2 cache. Gabor

Gabor, I assume you are taking care to do an L2 cache flush before running the Tx side ? I got caught out with that one ! Andrew At 03:46 PM 1/26/01 +0000, wrote: >Sounds like you have the same problem as me !! I too have an EDMA >servicing McBSP and my destination buffer doesn't get written to >either. I'm also using DSP/BIOS II and a C6711 but the hardware is >custom. > >Can you try manually editing the reload parameters for your EDMA >channel to point to some other location in memory (whilst the DMA is >running). I did this (changed the destination pointer to 0x80300000) >and all data was transfered correctly. > >I also got to a point where there were two segments inside my >destination buffer that were getting updated and the rest of the >buffer wasn't. > >I am very interested in the fact that it works OK if not using >DSP/BIOS. Can you force the destination address to be the same in >both cases and see whether that makes a difference ?? > >I've tried TI technical support but (so far) they have been >useless !!! > >Anyone explain why the destination buffer is not being written to >correctly ?? > >Cheers, >... Gary > >--- In c6x@y..., gabor.kruchio@a... wrote: >> Compiling with DSP/BIOS II, EDMA receiver generates Transfer >Complete >> interrupt, but the receive buffer is empty (without DSP/BIOS II my >> test code works as I expect: transmit buffer is copied thru McBSP >into >> receive buffer). Both transmitter and receiver buffer is allocated >> in external memory. > > >_____________________________________ >Note: If you do a simple "reply" with your email client, only the author of >this message will receive your answer. You need to do a "reply all" if you >want your answer to be distributed to the entire group. > >_____________________________________ >About this discussion group: > >To Join: Send an email to > >To Post: Send an email to > >To Leave: Send an email to > >Archives: http://www.egroups.com/group/c6x > >Other Groups: http://www.dsprelated.com >

Sounds like you have the same problem as me !! I too have an EDMA servicing McBSP and my destination buffer doesn't get written to either. I'm also using DSP/BIOS II and a C6711 but the hardware is custom. Can you try manually editing the reload parameters for your EDMA channel to point to some other location in memory (whilst the DMA is running). I did this (changed the destination pointer to 0x80300000) and all data was transfered correctly. I also got to a point where there were two segments inside my destination buffer that were getting updated and the rest of the buffer wasn't. I am very interested in the fact that it works OK if not using DSP/BIOS. Can you force the destination address to be the same in both cases and see whether that makes a difference ?? I've tried TI technical support but (so far) they have been useless !!! Anyone explain why the destination buffer is not being written to correctly ?? Cheers, ... Gary --- In c6x@y..., gabor.kruchio@a... wrote: > Compiling with DSP/BIOS II, EDMA receiver generates Transfer Complete > interrupt, but the receive buffer is empty (without DSP/BIOS II my > test code works as I expect: transmit buffer is copied thru McBSP into > receive buffer). Both transmitter and receiver buffer is allocated > in external memory.

--- In c6x@y..., "Andrew Elder" <andrew_elder@b...> wrote: > > Compiling with DSP/BIOS II, EDMA receiver generates Transfer > Complete > > interrupt, but the receive buffer is empty (without DSP/BIOS II my > > test code works as I expect: transmit buffer is copied thru McBSP > into > > receive buffer). Both transmitter and receiver buffer is allocated > > in external memory. > > McBSP is configured in Digital Loopback Mode, with internal clock > > and FS, FSX on DXR-XSR copy. I do not use the clock divider > > (SRGR.CLKGDV=1). > > For such high data rates you should use internal SRAM for the src and > dst buffers. OK, I tried them out: - using internal SRAM, the test code works under DSP/BIOS II, too. But what I do not understand is why the same configuration still can *NOT* handle external SDRAM if DSP/BIOS II linked in and can handle fine the same external SDRAM if DSP/BIOS II is *NOT* linked in? What can be the significant difference? CCS does not show any difference in the EMIF configuration. What makes DSP/BIOS II ? - If clock divider is used to lower data rate (e.g. SRGR.CLKGDV=0xff) with the Loopback configuration (DLB, FSGM_DXR2XSR, playing with delay: X/RCR.RDATDLY=0/1/2) there is no any change: rcv buffer allocated in external memory remains empty if DSP/BIOS II is linked in. Gabor

--- In , gabor.kruchio@a... wrote: > --- In , "Andrew Elder" <andrew_elder@b...> wrote: > > What does "gets crazy" mean. > > What do you observe ? > Compiling with DSP/BIOS II, EDMA receiver generates Transfer Complete > interrupt, but the receive buffer is empty (without DSP/BIOS II my > test code works as I expect: transmit buffer is copied thru McBSP into > receive buffer). Both transmitter and receiver buffer is allocated > in external memory. For such high data rates you should use internal SRAM for the src and dst buffers. > > > > What data rates are you talking about. > McBSP is configured in Digital Loopback Mode, with internal clock > and FS, FSX on DXR-XSR copy. I do not use the clock divider > (SRGR.CLKGDV=1). > > We are using McBSP and EDMA under DSP/BIOS II. > > We set up the EDMA channel(s) first and then start the McBSP. > > Linked EDMA transfers are a good idea if you want continuous > > operation. > Could you send some details on your configuration sequence: > - what do you configure/enable in main()? > - where do you enable interrupt(s), EDMA events? see below > - do you have built-in delays between configuration steps? no, but there will be a few cycles between McBSP init and EDMA enable. > (Peripherals Reference Guide Ch.11.3.1 suggests some waits between > McBSP initialization steps) > - etc. (what you think makes sense) Here's what I do in main(). I'm using SSL calls/macros. setup EDMA setup McBSP then EDMA_EnableChannel(hEdmaChannel_Mcbsp0_Tx); // enable EDMA TCC code in channel interrupt enable register HEDMA_CIER |= 1<<ASI_EDMA_CIPR_MCBSP0_RX; IRQ_Enable(IRQ_EVT_EDMAINT); > > > > We are seeing some problems actually. > > Sometimes the EDMA channel "misses" a McBSP transfer request which > > results in missing samples. We are in the process of figuring it > > out. > I am very interested in the details. Well, for us it seems like a sample is missed from time to time. It is difficult to say more than that. The C6711 is not very deterministic, so one can't say the cache was doing (a) and the EMIF was donig (b). Makes debugging a bit tricky.... Good luck, Andrew > > Many thanks: > Gabor > > PS: I am using dsk6711 with CCS 1.20 > > ---------------- > Gabor Kruchio > Alcatel Austria - Voice Processing Center > A-1210 Wien tel: 431-27722-5003 > Scheydgasse 4 fax: 431-27722-75003 > Austria/Europe > mailto:gabor.kruchio@a...

--- In , "Andrew Elder" <andrew_elder@b...> wrote: > What does "gets crazy" mean. > What do you observe ? Compiling with DSP/BIOS II, EDMA receiver generates Transfer Complete interrupt, but the receive buffer is empty (without DSP/BIOS II my test code works as I expect: transmit buffer is copied thru McBSP into receive buffer). Both transmitter and receiver buffer is allocated in external memory. > What data rates are you talking about. McBSP is configured in Digital Loopback Mode, with internal clock and FS, FSX on DXR-XSR copy. I do not use the clock divider (SRGR.CLKGDV=1). > We are using McBSP and EDMA under DSP/BIOS II. > We set up the EDMA channel(s) first and then start the McBSP. > Linked EDMA transfers are a good idea if you want continuous > operation. Could you send some details on your configuration sequence: - what do you configure/enable in main()? - where do you enable interrupt(s), EDMA events? - do you have built-in delays between configuration steps? (Peripherals Reference Guide Ch.11.3.1 suggests some waits between McBSP initialization steps) - etc. (what you think makes sense) > We are seeing some problems actually. > Sometimes the EDMA channel "misses" a McBSP transfer request which > results in missing samples. We are in the process of figuring it > out. I am very interested in the details. Many thanks: Gabor PS: I am using dsk6711 with CCS 1.20 ---------------- Gabor Kruchio Alcatel Austria - Voice Processing Center A-1210 Wien tel: 431-27722-5003 Scheydgasse 4 fax: 431-27722-75003 Austria/Europe mailto: