|
Milan, Glad you are making progress. I haven't been looking for info. on this subject recently, but I did notice that SPRZ191G (C6713 Silicon Errata) has a description of the effect of processor L2 cache operations blocking EDMA transfers. I do seem to recall that once a low-priority transfer has started, it can't be "interrupted" by another high priority operation. Maybe someone else can fill in here ? - Andrew At 04:35 PM 7/26/2004 +0200, Milan Bajza wrote: >Andrew, > >thanks for your response. > >I have changed the destination memory from external SDRAM to internal for >the DPRAM-Receive (primary transfer from EMIF-B to EMIF-A). With this setup >the reported transfer error don't occur anymore. > >Transfers such DPRAM-Transmit (transfer from EMIF-A to EMIF-B), McBSP Tx and >Rx works with internal and external memory (SDRAM at EMIF-A) without >problems. > >Anyway I have to use external memory cause of large data transfers. I will >change the EDMA transfers in 2 phases next time. First from external in >internal memory and then from internal to external memory. I hope this >works. > >But I still want know: >Why can the low-priority EDMA-transfer (blockmove, EMIF-B to EMIF-A) stall a >higher priority EDMA-transfer (McBSP). The options "EDMAWEIGHT" and "EDMA >Priority Que Length" I have already considered. >I can't find the reason in the TI application notes. > >Has anyone an idea? > >Thanks, >Milan > > >Milan, > >I ran into something similar on the C6711 a few years ago. > >Change the McBSP destination to be internal memory (if it isn't already). >That way it can proceed at the same time as the external bus accesses. > >If that doesn't fix it, I would try splitting the DPRAM EDMA operation into >several smaller linked EDMA chunks. > >I assume you have read all the EDMA documentation you can get your hands on >? When I ran into my problems most of EDMA blocking issues weren't >documented, but TI has since made a major effort to try document how things >work. > >- Andrew E. > >At 02:32 PM 7/16/2004 +0200, Milan Bajza wrote: >>Hello, >> >>I am writing a communication device driver for a multi-dsp-system over >McBSP >>and Dual Ported RAM (DPRAM) on the C6414 with 400MHz. I am using the DEV >>driver model with SIOs under DSP/BIOS. >>The transfer is realized in two priorities and is packet based with the >size >>of max. 792 bytes and max. 4096 bytes. >> >>***SITUATION*** >>The McBSP-Driver (25MHz McBSP-Clock) receives 4096 Bytes with EDMA >>(Urgent-Priority). In the middle of this transfer the DPRAM-Driver begins >to >>receive 4096 byte from EMIF-B with EDMA (LOW-Priority) to SDRAM at EMIF-A, >>too. >>In this case the EDMA of the McBSP-Transfer stopped with element counter >>between 1 to 6 and blocked the hole transfer. It seems that the block move >>(16bit) of the 4096 bytes of the DPRAM-Driver blocked the EDMA to receive >>McBSP words (32bit). >>In the received buffer I can find missed words according to the value of >the >>element counter (e.g. ...100, 101, 102, 104, 105...) >>==> The EDMA leave out McBSP-Events in high transfer situations. >> >> >>***FACTS AND DEBUGGING*** >>I don't use the L2-Cache, but the hole application, outer the transfer >>buffers (SDRAM), are in the internal RAM. >> >>I am using C6414 Revisions 1.02 and 1.1. >>With revision 1.1 I tried to set EDMAWEIGHT to 3 (50% L1D access and 50% >>EDMA access), see SPRU234 3-13. This change has no effect also if I set the >>value to 0. >> >>Furthermore I increase the EDMA Priority Que Length with >>"EDMA_setPriQLength(EDMA_Q0, 10);" from 2 to 10. >>This has also no positive effect. >> >>A debugging session with the Logic Analyzer shows, that this parallel EDMA >>transfer occurs without error often. But sometimes the same scenario ends >>with a transfer stop, cause uncompleted EDMA job. >>That proves, that my software and the statemashine is OK. >> >> >>***QUESTIONS*** >>The McBSP words comes with a rate of 1.28us (512 CPU-clocks). Is this time >>to short for the EDMA? >> >>Is it possible that the EMIF-B (DPRAM) stall the McBSP-EDMA or the hole >DSP? >> >> >>This EDMA problem don't occur, if I decrease the McBSP-Clock from 25MHz to >>6.25MHz, but then the transfer rate is to low. I want reaches 50MHz. >> >> >>Has anyone an idea to solve this problem? >> >> >>Thanks, >>Milan >> >> >>Ingenieurbo Bajza >>Softwareentwicklung f DSPs und Mikrocontroller >> >>Dipl.Ing.(FH) Milan Bajza >> >> >> >> >> >>_____________________________________ >>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.yahoogroups.com/group/c6x >> >>Other Groups: http://www.dsprelated.com >> >>Yahoo! Groups Links >> >> >> > > >_____________________________________ >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.yahoogroups.com/group/c6x > >Other Groups: http://www.dsprelated.com > >Yahoo! Groups Links > > |
|
|
Re: AW: C6414 EDMA stall, missing McBSP words
Started by ●July 26, 2004
Reply by ●July 26, 20042004-07-26
|
Milan Bajza wrote: > > Andrew, > > thanks for your response. > > I have changed the destination memory from external SDRAM to internal for > the DPRAM-Receive (primary transfer from EMIF-B to EMIF-A). With this setup > the reported transfer error don't occur anymore. > > Transfers such DPRAM-Transmit (transfer from EMIF-A to EMIF-B), McBSP Tx and > Rx works with internal and external memory (SDRAM at EMIF-A) without > problems. > > Anyway I have to use external memory cause of large data transfers. I will > change the EDMA transfers in 2 phases next time. First from external in > internal memory and then from internal to external memory. I hope this > works. > > But I still want know: > Why can the low-priority EDMA-transfer (blockmove, EMIF-B to EMIF-A) stall a > higher priority EDMA-transfer (McBSP). The options "EDMAWEIGHT" and "EDMA > Priority Que Length" I have already considered. > I can't find the reason in the TI application notes. > > Has anyone an idea? > > Thanks, > Milan > > Milan, > You may want to break up the 4096 transfer into 8 512 byte transfers. The issue, I think is that if the low priority transfer of 4096 bytes sneeks in, then it is only after the completion of this transfer taht a higher priority transfer can proceed. By breaking up0 the 4096 byte transfer into 8 chunks of 512 bytes, as a chained EDMA, a higher priority transfer (if available) is checked once after every 512 bytes. You do not have to break it into two transfers, rather break it into smaller chunks. EMIFB is a 16-bit and hence increases the transfer time on the bus while EMIFA is a 64 bit bus. This mainly has to do with the McBSP requiring a tight servicing deadline, and the EDMA not able to do so when you issue a large transfer on a low priority. There is not much else that can be done, other than making sure that lower prioritiy transfers do not issue a large transfer in one go, locking out the bandwidth and responsiveness for higher priority transfers. that need fast servicing. Regds Jagadeesh Sankaran PS: These are strictly my own opinions and are not endorsed by Texas Instruments in ant form of consent. I am a software guy!. |
|
|
Reply by ●July 27, 20042004-07-27
|
Milan, I think Jagadeesh gave a very good explanation below. - Andrew At 01:34 PM 7/26/2004 -0500, Jagadeesh Sankaran wrote: >Milan Bajza wrote: >> >> Andrew, >> >> thanks for your response. >> >> I have changed the destination memory from external SDRAM to internal for >> the DPRAM-Receive (primary transfer from EMIF-B to EMIF-A). With this setup >> the reported transfer error don't occur anymore. >> >> Transfers such DPRAM-Transmit (transfer from EMIF-A to EMIF-B), McBSP Tx and >> Rx works with internal and external memory (SDRAM at EMIF-A) without >> problems. >> >> Anyway I have to use external memory cause of large data transfers. I will >> change the EDMA transfers in 2 phases next time. First from external in >> internal memory and then from internal to external memory. I hope this >> works. >> >> But I still want know: >> Why can the low-priority EDMA-transfer (blockmove, EMIF-B to EMIF-A) stall a >> higher priority EDMA-transfer (McBSP). The options "EDMAWEIGHT" and "EDMA >> Priority Que Length" I have already considered. >> I can't find the reason in the TI application notes. >> >> Has anyone an idea? >> >> Thanks, >> Milan >> >> Milan, >> > >You may want to break up the 4096 transfer into 8 512 byte transfers. >The issue, >I think is that if the low priority transfer of 4096 bytes sneeks in, >then it is >only after the completion of this transfer taht a higher priority >transfer can >proceed. By breaking up0 the 4096 byte transfer into 8 chunks of 512 >bytes, as >a chained EDMA, a higher priority transfer (if available) is checked >once after >every 512 bytes. You do not have to break it into two transfers, rather >break >it into smaller chunks. EMIFB is a 16-bit and hence increases the >transfer time >on the bus while EMIFA is a 64 bit bus. > >This mainly has to do with the McBSP requiring a tight servicing >deadline, >and the EDMA not able to do so when you issue a large transfer on a low >priority. There is not much else that can be done, other than making >sure >that lower prioritiy transfers do not issue a large transfer in one go, >locking out the bandwidth and responsiveness for higher priority >transfers. >that need fast servicing. > >Regds >Jagadeesh Sankaran > >PS: > These are strictly my own opinions and are not endorsed by Texas >Instruments > in ant form of consent. > > I am a software guy!. > |
|
|
Reply by ●July 27, 20042004-07-27
