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

Has anyone an example code using C6711's McBSP with EDMA under DSP/BIOS II? Specially I am interested in the initialization sequence. I have written a test program which initializes McBSP in Digital Loopback mode and EDMA to feet the transmiter and read the receiver. It works fine without DSP/BIOS but EDMA gets crazy if I embed more or less the same code in a DSP/BIOS II frame. Gabor

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

What does "gets crazy" mean. What do you observe ? What data rates are you talking about. 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. 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. Good luck. Andrew --- In , gabor.kruchio@a... wrote: > Has anyone an example code using C6711's McBSP with EDMA under > DSP/BIOS II? > Specially I am interested in the initialization sequence. > I have written a test program which initializes McBSP in Digital > Loopback mode and EDMA to feet the transmiter and read the receiver. > It works fine without DSP/BIOS but EDMA gets crazy if I embed more or > less the same code in a DSP/BIOS II frame. > Gabor

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

Andrew Elder wrote: > What does "gets crazy" mean. > What do you observe ? > What data rates are you talking about. > > 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. > > 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. Which transfer rate are you using at the McBSP? We have seen similar problems: Some samples were missed if the EDMA worked from the serial port receive register into the external SDRAM. Due to cache misses/victims with higher priority than "normal" EDMA transfers the EDMA was stalled too long which caused a missing sample. If the EDMA works into L2 memory everything is fine (ping-pong transfer: serial port --> L2 --> SDRAM). Cheers Thomas -- //\\\\ | ~ ~ | ( O O ) ___________________________________oOOo______( )_____oOOo_______ Thomas Schwere Phone: +41 1 445 16 61 Supercomputing Systems AG Fax: +41 1 445 16 10 Technoparkstrasse 1 Url: www.scs.ch CH-8005 Zurich Email: Switzerland Oooo _________________________________________oooO______( )_________ ( ) ) / \ ( (_/ \_)

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

--- 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:

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

--- 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...

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

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

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.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.

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

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. > > >_____________________________________

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

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

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

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

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

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

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

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

Last, but not least: I have found, that TI has a new version of its Application Report "TMS320C6000 McBSP as a TDM Highway" (SPRA491A - Updated: 09/11/2000) (http://www.ti.com/sc/docs/psheets/abstract/apps/spra491a.htm) The update enhances the original example code with - DSP/BIOS - using McBSP with EDMA - CSL - where to use CASH_flush(), CASH_clean() Gabor

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