|
I need to configure the McBSP1 of a C6711 in (what appears to be) a "non-standard" mode. Can anyone help me over the last hurdle ?? Here's what I'm trying to do. I have McBSP1 receiving data from an external device - I am not using the Tx section of serial port and the DSP is the slave (the external device provides clock, data and frame sync). My Rx data is 16-bits but the FS pulses are 24-bits apart and I want to get 2 16-bit samples into the DRR before a new RXEVT is generated. This is so that the EDMA servicing the serial port has to perform half the number of transfers it currently has to. I have re-configured the serial port so that the Rx clock goes into the DSP on CLKS and I use the sample rate generator and clock stop mode to generate the CLKX that stops for the 8 unwanted bits. CLKX is connected to CLKR externally. This should give me what I want *BUT* when configured in CLKSTP mode, the serial port uses the internally generated clock to clock data in. This clock is *BEFORE* the buffer that is used to stop the CLKX (!@?*!*) so I still clock in the unwanted bits. Unfortunately, modifying the external device, or adding glue logic between the two is not an option (in the short term anyway). Anyone know whether what I'm trying to do is possible ?? Whilst I'm at it, another thing that has been bugging me is that using CCS (e.g. refreshing a watch window) causes EDMA stalls which result in me losing data. I have priority set to high in my DMA servicing the serial port but still lose data. Is there any way of guaranteeing that I won't lose data due to the EDMA. Thanks for any help, ... Gary |
|
|
McBSP Configuration Help
Started by ●February 21, 2001
Reply by ●February 21, 20012001-02-21
|
At 10:26 AM 2/21/01 +0000, wrote: >I need to configure the McBSP1 of a C6711 in (what appears to be) >a "non-standard" mode. Can anyone help me over the last hurdle ?? > >Here's what I'm trying to do. > >I have McBSP1 receiving data from an external device - I am not using >the Tx section of serial port and the DSP is the slave (the external >device provides clock, data and frame sync). > >My Rx data is 16-bits but the FS pulses are 24-bits apart and I want >to get 2 16-bit samples into the DRR before a new RXEVT is >generated. This is so that the EDMA servicing the serial port has to >perform half the number of transfers it currently has to. I don't think this is possible with this confguration. Can you generate 1 FS per 32 bit clocks and then pack the 2 16 bit samples back to back ? What sample rate are you using ? Maybe you shouldn't worry about the extra xfer ? Are you sending data to external or internal RAM ? Andrew > >I have re-configured the serial port so that the Rx clock goes into >the DSP on CLKS and I use the sample rate generator and clock stop >mode to generate the CLKX that stops for the 8 unwanted bits. CLKX >is connected to CLKR externally. This should give me what I want >*BUT* when configured in CLKSTP mode, the serial port uses the >internally generated clock to clock data in. This clock is *BEFORE* >the buffer that is used to stop the CLKX (!@?*!*) so I still clock in >the unwanted bits. > >Unfortunately, modifying the external device, or adding glue logic >between the two is not an option (in the short term anyway). Anyone >know whether what I'm trying to do is possible ?? > >Whilst I'm at it, another thing that has been bugging me is that >using CCS (e.g. refreshing a watch window) causes EDMA stalls which >result in me losing data. I have priority set to high in my DMA >servicing the serial port but still lose data. Is there any way of >guaranteeing that I won't lose data due to the EDMA. > >Thanks for any help, >... Gary > > >_____________________________________ >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 >">http://docs.yahoo.com/info/terms/ > |
|
|
Reply by ●March 6, 20012001-03-06
|
Hi and thanks for responding to my question(s). Unfortunately, I have no control over the way the serial interface produces data, I just have to receive it - and receive it reliably. I think I agree that it is not possible to do what I was trying to do. The main reason I am trying to pack two samples into a single word is because I'm experiencing data loss in my EDMA transfer. That is, the data arriving at the McBSP is real time and the data that I see in my buffer has the occasional missed sample. My investigation has shown that the data loss corresponds to activity on the JTAG emulator (I'm using an XDS510). If I use the watch window to modify a parameter, I get data loss (presume due to EDMA stall). I need to ensure the integrity of the data being received and have done everything I can think of to give the EDMA priority over everything else. If you have any ideas please let me know. Thanks again, ... Gary > I don't think this is possible with this confguration. > Can you generate 1 FS per 32 bit clocks and then pack the 2 16 bit samples > back to back ? > What sample rate are you using ? Maybe you shouldn't worry about the extra > xfer ? Are you sending data to external or internal RAM ? > > Andrew |
|
|
Reply by ●March 7, 20012001-03-07
|
Gary- >I need to ensure the integrity of the data being received and have >done everything I can think of to give the EDMA priority over >everything else. If you have any ideas please let me know. Don't use JTAG to debug. Use the HPI. Use JTAG to get going, then use HPI to see data during critical periods. You could also synchronize; i.e. after receiving a serial word (EDMA transfer has just occurred), set a bit in HPIC that the host sees and says "Ok to make some transfers". Jeff Brower Signalogic On Tue, 06 Mar 2001, wrote: >Hi and thanks for responding to my question(s). > >Unfortunately, I have no control over the way the serial interface >produces data, I just have to receive it - and receive it reliably. >I think I agree that it is not possible to do what I was trying to do. > >The main reason I am trying to pack two samples into a single word is >because I'm experiencing data loss in my EDMA transfer. That is, the >data arriving at the McBSP is real time and the data that I see in my >buffer has the occasional missed sample. > >My investigation has shown that the data loss corresponds to activity >on the JTAG emulator (I'm using an XDS510). If I use the watch >window to modify a parameter, I get data loss (presume due to EDMA >stall). > >I need to ensure the integrity of the data being received and have >done everything I can think of to give the EDMA priority over >everything else. If you have any ideas please let me know. > >Thanks again, >... Gary > >> I don't think this is possible with this confguration. >> Can you generate 1 FS per 32 bit clocks and then pack the 2 16 bit >samples >> back to back ? >> What sample rate are you using ? Maybe you shouldn't worry about >the extra >> xfer ? Are you sending data to external or internal RAM ? >> >> Andrew |
|
|
Reply by ●March 7, 20012001-03-07
|
Hi Jeff, My DSP is in an embedded system so the HPI is not available to me for debugging. Why do you say don't use JTAG for debugging - this is what is was intended for isn't it ? The suggestion about synchronising the HPI with an EDMA transfer doesn't sound like a good idea to me (maybe I'm wrong). To set the bit in the HPIC I would need to know that the EDMA transfer had occured - I guess the EDMA could generate an interrupt but I may as well have used the McBSP Rx interrupt to transfer the data from the serial port in the first place. This *does* guarantee the integrity of my data but also takes up all of my processing power in ISR overhead. If I've missed your point I apologise. Cheers, ... Gary --- In c6x@y..., Jeff Brower <jbrower@s...> wrote: > Gary- > > >I need to ensure the integrity of the data being received and have > >done everything I can think of to give the EDMA priority over > >everything else. If you have any ideas please let me know. > > Don't use JTAG to debug. Use the HPI. Use JTAG to get going, then use HPI to > see data during critical periods. You could also synchronize; i.e. after > receiving a serial word (EDMA transfer has just occurred), set a bit in HPIC > that the host sees and says "Ok to make some transfers". > > Jeff Brower > Signalogic > On Tue, 06 Mar 2001, gary.halfyard@b... wrote: > >Hi and thanks for responding to my question(s). > > > >Unfortunately, I have no control over the way the serial interface > >produces data, I just have to receive it - and receive it reliably. > >I think I agree that it is not possible to do what I was trying to do. > > > >The main reason I am trying to pack two samples into a single word is > >because I'm experiencing data loss in my EDMA transfer. That is, the > >data arriving at the McBSP is real time and the data that I see in my > >buffer has the occasional missed sample. > > > >My investigation has shown that the data loss corresponds to activity > >on the JTAG emulator (I'm using an XDS510). If I use the watch > >window to modify a parameter, I get data loss (presume due to EDMA > >stall). > >I need to ensure the integrity of the data being received and have > >done everything I can think of to give the EDMA priority over > >everything else. If you have any ideas please let me know. > > > >Thanks again, > >... Gary > > > >> I don't think this is possible with this confguration. > >> Can you generate 1 FS per 32 bit clocks and then pack the 2 16 bit > >samples > >> back to back ? > >> What sample rate are you using ? Maybe you shouldn't worry about > >the extra > >> xfer ? Are you sending data to external or internal RAM ? > >> > >> Andrew |
|
|
Reply by ●March 7, 20012001-03-07
|
Gary, You haven't mentioned what the data rate through the serial port is.... Andrew --- In c6x@y..., gary.halfyard@b... wrote: > Hi Jeff, > My DSP is in an embedded system so the HPI is not available to me for > debugging. Why do you say don't use JTAG for debugging - this is what > is was intended for isn't it ? > The suggestion about synchronising the HPI with an EDMA transfer > doesn't sound like a good idea to me (maybe I'm wrong). To set the > bit in the HPIC I would need to know that the EDMA transfer had > occured - I guess the EDMA could generate an interrupt but I may as > well have used the McBSP Rx interrupt to transfer the data from the > serial port in the first place. This *does* guarantee the integrity > of my data but also takes up all of my processing power in ISR > overhead. > If I've missed your point I apologise. > Cheers, > ... Gary > > --- In c6x@y..., Jeff Brower <jbrower@s...> wrote: > > Gary- > > > > >I need to ensure the integrity of the data being received and have > > >done everything I can think of to give the EDMA priority over > > >everything else. If you have any ideas please let me know. > > > > Don't use JTAG to debug. Use the HPI. Use JTAG to get going, then > use HPI to > > see data during critical periods. You could also synchronize; i.e. > after > > receiving a serial word (EDMA transfer has just occurred), set a > bit in HPIC > > that the host sees and says "Ok to make some transfers". > > > > Jeff Brower > > Signalogic > > > > > > On Tue, 06 Mar 2001, gary.halfyard@b... wrote: > > >Hi and thanks for responding to my question(s). > > > > > >Unfortunately, I have no control over the way the serial interface > > >produces data, I just have to receive it - and receive it > reliably. > > >I think I agree that it is not possible to do what I was trying to > do. > > > > > >The main reason I am trying to pack two samples into a single word > is > > >because I'm experiencing data loss in my EDMA transfer. That is, > the > > >data arriving at the McBSP is real time and the data that I see in > my > > >buffer has the occasional missed sample. > > > > > >My investigation has shown that the data loss corresponds to > activity > > >on the JTAG emulator (I'm using an XDS510). If I use the watch > > >window to modify a parameter, I get data loss (presume due to EDMA > > >stall). > > > >I need to ensure the integrity of the data being received and have > > >done everything I can think of to give the EDMA priority over > > >everything else. If you have any ideas please let me know. > > > > > >Thanks again, > > >... Gary > > > > > >> I don't think this is possible with this confguration. > > >> Can you generate 1 FS per 32 bit clocks and then pack the 2 16 > bit > > >samples > > >> back to back ? > > >> What sample rate are you using ? Maybe you shouldn't worry about > > >the extra > > >> xfer ? Are you sending data to external or internal RAM ? > > >> > > >> Andrew |
|
|
Reply by ●March 7, 20012001-03-07
|
Gary- >My DSP is in an embedded system so the HPI is not available to me for >debugging. Ok. > Why do you say don't use JTAG for debugging - this is what >is was intended for isn't it ? JTAG is one way. HPI is another. Texas Inst. implementation of JTAG is powerful, and their RTDX efforts are original and admirable. But even with RTDX you have to add non-production code in order to get fairly high transfer rates. What if you want to move large amounts of data while still allowing your DSP program to run in real-time? We need to do this all the time for bit-exact comparisons with MATLAB simulations for speech codecs, MP3, etc. It all comes down to what you are trying to debug. Our engineers use JTAG for low-level software problems and some hardware related problems. But once they have their system working, and the basic cycle of "modify C/asm code, build, load, re-run, check results, repeat" is in effect with no weirdnesses, they ditch JTAG in a hurry and start using HPI based tools. It saves hours and hours of work and time and gives us broad, data oriented results. For example, we can see huge buffers of data in MATLAB or Visual Studio waveform displays and our C54xx code hasn't missed a beat, and we are not modifying the production code with stuff that has to be taken out later. As a historical note, effective, fast, internal DMA-based host-port interfaces have been around on DSPs for a long, long time, going back to the Lucent DSP32x processors in 1990. Lucent, Mot, and some ADI DSPs all had them 1994 on; TI started adding HPIs on C54x devices starting about 1996/1997. We used to wonder if TI would ever add that feature, and they finally did it. >The suggestion about synchronising the HPI with an EDMA transfer >doesn't sound like a good idea to me (maybe I'm wrong). To set the >bit in the HPIC I would need to know that the EDMA transfer had >occured - I guess the EDMA could generate an interrupt but I may as >well have used the McBSP Rx interrupt to transfer the data from the >serial port in the first place. This *does* guarantee the integrity >of my data but also takes up all of my processing power in ISR >overhead. Well if EDMA is going all the time and there are no naturally occurring gaps, then synchronization might not work. But on the other hand, you might not need it either -- I was just trying to cover a case where EDMA could conflict with the HPI, which uses EDMA also. Jeff Brower DSP sw/hw engineer Signalogic >--- In c6x@y..., Jeff Brower <jbrower@s...> wrote: >> Gary- >> >> >I need to ensure the integrity of the data being received and have >> >done everything I can think of to give the EDMA priority over >> >everything else. If you have any ideas please let me know. >> >> Don't use JTAG to debug. Use the HPI. Use JTAG to get going, then >use HPI to >> see data during critical periods. You could also synchronize; i.e. >after >> receiving a serial word (EDMA transfer has just occurred), set a >bit in HPIC >> that the host sees and says "Ok to make some transfers". >> >> Jeff Brower >> Signalogic >> >> >> On Tue, 06 Mar 2001, gary.halfyard@b... wrote: >> >Hi and thanks for responding to my question(s). >> > >> >Unfortunately, I have no control over the way the serial interface >> >produces data, I just have to receive it - and receive it >reliably. >> >I think I agree that it is not possible to do what I was trying to >do. >> > >> >The main reason I am trying to pack two samples into a single word >is >> >because I'm experiencing data loss in my EDMA transfer. That is, >the >> >data arriving at the McBSP is real time and the data that I see in >my >> >buffer has the occasional missed sample. >> > >> >My investigation has shown that the data loss corresponds to >activity >> >on the JTAG emulator (I'm using an XDS510). If I use the watch >> >window to modify a parameter, I get data loss (presume due to EDMA >> >stall). > >> >I need to ensure the integrity of the data being received and have >> >done everything I can think of to give the EDMA priority over >> >everything else. If you have any ideas please let me know. >> > >> >Thanks again, >> >... Gary >> > >> >> I don't think this is possible with this confguration. >> >> Can you generate 1 FS per 32 bit clocks and then pack the 2 16 >bit >> >samples >> >> back to back ? >> >> What sample rate are you using ? Maybe you shouldn't worry about >> >the extra >> >> xfer ? Are you sending data to external or internal RAM ? >> >> >> >> Andrew |
Reply by ●March 8, 20012001-03-08
|
Gary- >OK, I guess I'm still at the low-level software problems stage. I could >live with the JTAG approach not being able to transfer large amounts of data >to visualise on a host. What is really stopping me getting on is not being >able to modify a single memory location without interrupting the EDMA >receiving data. I also thought that both the HPI and the JTAG interfaces >(once they are inside the DSP) both use the EDMA ? Surely the JTAG should >be able to perform transfers of small amounts of data (single words) in just >as efficient a manner as the HPI ?? Except that with JTAG the processor has to be stopped temporarily. Maybe that is what messes up EDMA? Maybe you miss a McBSP word or something because of the processor hiccup, and it's not actually an EDMA problem? Or maybe the processor loses a state or EDMA misses an edge or something because of the brief stop. >Sounds like you've been at it a lot longer than I have ;-> Yeah I know you're smirking. But you'll get there. Some day you'll mention "C6xx" and a young engineer working for you will say "yeah, I heard about that one; it ran DOS, right?". >OK and yep - I have to receive data continuously and at quite a high rate. > >When you say you use "HPI" based tools - do you use them on the actual >product (embedded) hardware or on development cards (such as the EVM). Both of course. Jeff Brower DSP sw/hw engineer Signalogic >BTW, this is so much better than TI Technical support !! I sent the same >question to them about 4 weeks before I sent it to this group and I STILL >haven't had anything more than their automated response. I think I'll be >looking seriously at ADI DSPs next time .... Well keep that up and you'll get some help from TI, for sure ;-) But seriously, I have found that peer sources nearly always get a better result, no matter the vendor. |
|
|
Reply by ●March 8, 20012001-03-08
|
Andrew, I'm receiving 16-bit words at around 500kHz. I'm using a C6711 at 150MHz. I'm transfering directly from McBSP1 to a buffer in internal RAM. Cheers, ... Gary > Gary, > > You haven't mentioned what the data rate through the serial port > is.... > > Andrew |
|
|
Reply by ●March 8, 20012001-03-08
|
Gary, We are transferring samples at around 350 kHz input and 350 kHz output and we are seeing samples get dropped as well. There seems to be either (a) a bug, or (b) a design flaw in the C6711. This problem only occurs when some of L2 is configured as cache. There is some sort of contention that allows the L2 cache controller to lock out EDMA transfers for long enough to miss a transfer request from the McBSP. TI are working on the problem, but have been unable to either determine the sequence of events that causes the problem or find a soln. Pity the C6711 doesn't allow one to assign McBSP EDMA transfers top priority. This is a major design oversight in my opinion. So far the only thing we know for sure is that configuring all L2 cache as SRAM causes the problem to go away. Is all of L2 configured as SRAM ? I'll keep you posted on our results. Andrew --- In c6x@y..., gary.halfyard@b... wrote: > Andrew, > > I'm receiving 16-bit words at around 500kHz. > I'm using a C6711 at 150MHz. > I'm transfering directly from McBSP1 to a buffer in internal RAM. > > Cheers, > ... Gary > > > Gary, > > > > You haven't mentioned what the data rate through the serial port > > is.... > > > > Andrew |
|
|
