|
Andrew, Good to know its not me and I'm not the only one with this problem. What really makes me *mad* is that TI technical support have not responded to my support request about this issue for nearly five weeks now. If they know about the problem why the heck didn't they let me know. Sounds very much like TI don't like admiting any flaws in their stuff !! I have SO many examples of time I've wasted due to a lack of support from TI. Its not as if I want something for nothing either - I would be prepared to pay for 12-months worth of technical support (if it was any good that is). I had no idea a new version of the Peripherals Reference was out so had no idea there were any such bits as FREE and SOFT in the SPCR register. I'll give them a go and see. FYI, I am currently using 2-way L2 cache and have placed my most processing intensive code and data buffers into internal ram (using #pragma directives). I don't think I'd be able to fit all of my code into internal and I have lots of functions/data that are used infrequently but still require the speed of the internal RAM so need some L2 cache. Thanks for your (very useful) input, ... Gary BTW - if you here anything back from TI on the EDMA missing samples from the McBSP *please* pass it on to me. --- In c6x@y..., andrew_elder@b... wrote: > > 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 > |
|
|
Online · Live + on demand
February 9-11, 2027
Price goes up Nov 1: register now to lock in today's rate
Register Now →
McBSP Configuration Help
Started by ●February 21, 2001
Reply by ●March 9, 20012001-03-09
Reply by ●March 9, 20012001-03-09
|
I have found that I usually can fix my stuff before the TI help desk
sends me something that's helpful. The Field Applications Engineers are typically much better at answering so you may want to try your local person Jeff White -----Original Message----- From: [mailto:] Sent: Friday, March 09, 2001 8:52 AM To: Subject: [c6x] Re: McBSP Configuration Help Andrew, Good to know its not me and I'm not the only one with this problem. What really makes me *mad* is that TI technical support have not responded to my support request about this issue for nearly five weeks now. If they know about the problem why the heck didn't they let me know. Sounds very much like TI don't like admiting any flaws in their stuff !! I have SO many examples of time I've wasted due to a lack of support from TI. Its not as if I want something for nothing either - I would be prepared to pay for 12-months worth of technical support (if it was any good that is). I had no idea a new version of the Peripherals Reference was out so had no idea there were any such bits as FREE and SOFT in the SPCR register. I'll give them a go and see. FYI, I am currently using 2-way L2 cache and have placed my most processing intensive code and data buffers into internal ram (using #pragma directives). I don't think I'd be able to fit all of my code into internal and I have lots of functions/data that are used infrequently but still require the speed of the internal RAM so need some L2 cache. Thanks for your (very useful) input, ... Gary BTW - if you here anything back from TI on the EDMA missing samples from the McBSP *please* pass it on to me. --- In c6x@y..., andrew_elder@b... wrote: > > 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 > _____________________________________ 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 20, 20012001-03-20
|
CCS stopping the processor should not affect the EDMA. It should continue
to run. When you stop the processor, though, you're probably stopping the serial port. This can cause you to miss data that the EDMA could otherwise move to internal memory for you. If you look at page 12-8 in the new peripherals guide (spru190d.pdf) now on the TI website, you'll see the 'C6x11 devices now have a FREE bit documented to address this problem. >From: >To: >Subject: [c6x] McBSP Configuration Help >Date: Wed, 21 Feb 2001 10:26:37 -0000 >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. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com |
