|
Hi all, I am using EDMA to service McBSP1 in UART mode. I am using the code that is available on TI's website(spra633b).I have modified it to send 256 bits as opposed to 32 characters proposed in the application report. When I send the data onto McBSP port, I see that it transmits the data properly but DX of McBSP1 remains low for apprx 260msec, whereas the time taken to transmit 256 integers using UART config takes around 16ms (including data framers). After debuging the code, I think this was due to the fact that EDMA was still transferring data stored in the memory location following the actual data words. Element count was set to exact count of 352 elements in order to take care of extra framing bits necessary for transmission of the 256 elements, however the problem persisted. My problem is that I want to implement linking feature of EDMA to continously transmit the data for x number of times. Even when I set it to transfer for just one time, with linking, it so happens that during that mysterious 260msec period McBSP transmits the same data around 8 times. Also it interrupts the CPU only after that 280msec period, so CPU also cannot control (stop) that retransmission of data. Just want to know whether any of you have come across any such problem while dealing with EDMA or is there something that I am missing out on. Please reply with your comments/suggestions on this. Thanks a lot -Tarang |
|
|
Issues with EDMA-McBSP transfer in UART config
Started by ●July 19, 2004
Reply by ●July 19, 20042004-07-19
|
On Sun, 2004-07-18 at 22:38, Tarang Dadia wrote: > Hi all, > > I am using EDMA to service McBSP1 in UART mode. I am using the code > that is available on TI's website(spra633b).I have modified it to send > 256 bits as opposed to 32 characters proposed in the application > report. > > When I send the data onto McBSP port, I see that it transmits the data > properly but DX of McBSP1 remains low for apprx 260msec, whereas the > time taken to transmit 256 integers using UART config takes around > 16ms (including data framers). After debuging the code, I think this > was due to the fact that EDMA was still transferring data stored in > the memory location following the actual data words. Element count was > set to exact count of 352 elements in order to take care of extra > framing bits necessary for transmission of the 256 elements, however > the problem persisted. > > My problem is that I want to implement linking feature of EDMA to > continously transmit the data for x number of times. Even when I set > it to transfer for just one time, with linking, it so happens that > during that mysterious 260msec period McBSP transmits the same data > around 8 times. Also it interrupts the CPU only after that 280msec > period, so CPU also cannot control (stop) that retransmission of data. > > Just want to know whether any of you have come across any such problem > while dealing with EDMA or is there something that I am missing out > on. Please reply with your comments/suggestions on this. I was just working with this, I did not see the problem that you mentioned. I spent most of my time working on the receive part of the UART. The configuration part was a little confusing to me. I figured most of it out through trial an error. I set a breakpoint in the ISR and then tried the various options. The nice thing is that you can break in the debugger and look at the PRAM for the EDMA. At this point my code uses linked PRAMS for receive and a single PRAM for transmit. The only problem I am having is when the data I want to transmit it bigger than my edma buffer. It seems that sometimes I end up clobbering the EDMA with a new buffer before the old one is finished. How are you setting up the EDMA? |
|
|
Reply by ●July 20, 20042004-07-20
|
On Mon, 19 Jul 2004 10:35:25 -0700, lwj <> wrote: > > > On Sun, 2004-07-18 at 22:38, Tarang Dadia wrote: > > Hi all, > > > > I am using EDMA to service McBSP1 in UART mode. I am using the code > > that is available on TI's website(spra633b).I have modified it to send > > 256 bits as opposed to 32 characters proposed in the application > > report. > > > > When I send the data onto McBSP port, I see that it transmits the data > > properly but DX of McBSP1 remains low for apprx 260msec, whereas the > > time taken to transmit 256 integers using UART config takes around > > 16ms (including data framers). After debuging the code, I think this > > was due to the fact that EDMA was still transferring data stored in > > the memory location following the actual data words. Element count was > > set to exact count of 352 elements in order to take care of extra > > framing bits necessary for transmission of the 256 elements, however > > the problem persisted. > > > > My problem is that I want to implement linking feature of EDMA to > > continously transmit the data for x number of times. Even when I set > > it to transfer for just one time, with linking, it so happens that > > during that mysterious 260msec period McBSP transmits the same data > > around 8 times. Also it interrupts the CPU only after that 280msec > > period, so CPU also cannot control (stop) that retransmission of data. > > > > Just want to know whether any of you have come across any such problem > > while dealing with EDMA or is there something that I am missing out > > on. Please reply with your comments/suggestions on this. > > I was just working with this, I did not see the problem that you > mentioned. I spent most of my time working on the receive part of the > UART. The configuration part was a little confusing to me. I figured > most of it out through trial an error. I set a breakpoint in the ISR and > then tried the various options. The nice thing is that you can break in > the debugger and look at the PRAM for the EDMA. > > At this point my code uses linked PRAMS for receive and a single PRAM > for transmit. The only problem I am having is when the data I want to > transmit it bigger than my edma buffer. It seems that sometimes I end up > clobbering the EDMA with a new buffer before the old one is finished. > > How are you setting up the EDMA? I am setting up EDMA using following parameters EDMA_configArgs(hEdma14, /* OPT Setup */ EDMA_OPT_RMK( EDMA_OPT_PRI_HIGH, /* 1 */ EDMA_OPT_ESIZE_16BIT, /* 01 */ EDMA_OPT_2DS_NO, /* 0 */ EDMA_OPT_SUM_INC, /* 01 */ EDMA_OPT_2DD_NO, /* 0 */ EDMA_OPT_DUM_NONE, /* 00 */ EDMA_OPT_TCINT_YES, /* 1 */ EDMA_OPT_TCC_OF(14), /* 14 */ EDMA_OPT_LINK_YES, /* 0 */ EDMA_OPT_FS_NO /* 0 */ ), /* SRC Setup */ EDMA_SRC_RMK((Uint32) xmitbuf), /*xmitbuf address*/ /* CNT Setup */ EDMA_CNT_RMK( 0, EDMA_CNT_ELECNT_OF(352) ), /* DST Setup */ EDMA_DST_RMK(MCBSP_getXmtAddr(hMcbsp1)), /* IDX Setup */ EDMA_IDX_RMK(0,0), /* RLD Setup */ EDMA_RLD_RMK(0,EDMA_RLD_OF(EDMA_getTableAddress(hEdmaDelay))) ); and to restate the problem that I am facing : whenever I enable linking in EDMA and execute the code, McBSP transmit line DX1 goes high, transmits data and remains low for 260msec then goes high again. I do not want the DX line to remain low for 260msec (since I cannot resend data for 260msec) and I do not understand why this happens so cannot control that. If you have access to the code that you were working on, can you please check what kind of output you get before linking and after enabling linking and specifying self link address. I will really appreciate that. Thanks for your comments -Tarang > > _____________________________________ > 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 |
|
|
Reply by ●July 22, 20042004-07-22
|
lwj - I did figure out from where the mysterious 260msec crept into my code. It was basically after each EDMA transfer, in the ISR, the code was printing out some diagnostic message on host screen and as we all know printf statements takes apprx 4000 cycles to execute i.e. 4000*6.6667nsec (clock for c6711 dsp) = 266msec. Simple isnt it...just took lil longer to debug tho :-). Just thought would put it online for everyone so can be of use to someone who mite bump into similar problem. Thanks a lot for ur comments -Tarang On Tue, 20 Jul 2004 01:23:37 -0600, Tarang Dadia <> wrote: > On Mon, 19 Jul 2004 10:35:25 -0700, lwj <> wrote: > > > > > > On Sun, 2004-07-18 at 22:38, Tarang Dadia wrote: > > > Hi all, > > > > > > I am using EDMA to service McBSP1 in UART mode. I am using the code > > > that is available on TI's website(spra633b).I have modified it to send > > > 256 bits as opposed to 32 characters proposed in the application > > > report. > > > > > > When I send the data onto McBSP port, I see that it transmits the data > > > properly but DX of McBSP1 remains low for apprx 260msec, whereas the > > > time taken to transmit 256 integers using UART config takes around > > > 16ms (including data framers). After debuging the code, I think this > > > was due to the fact that EDMA was still transferring data stored in > > > the memory location following the actual data words. Element count was > > > set to exact count of 352 elements in order to take care of extra > > > framing bits necessary for transmission of the 256 elements, however > > > the problem persisted. > > > > > > My problem is that I want to implement linking feature of EDMA to > > > continously transmit the data for x number of times. Even when I set > > > it to transfer for just one time, with linking, it so happens that > > > during that mysterious 260msec period McBSP transmits the same data > > > around 8 times. Also it interrupts the CPU only after that 280msec > > > period, so CPU also cannot control (stop) that retransmission of data. > > > > > > Just want to know whether any of you have come across any such problem > > > while dealing with EDMA or is there something that I am missing out > > > on. Please reply with your comments/suggestions on this. > > > > I was just working with this, I did not see the problem that you > > mentioned. I spent most of my time working on the receive part of the > > UART. The configuration part was a little confusing to me. I figured > > most of it out through trial an error. I set a breakpoint in the ISR and > > then tried the various options. The nice thing is that you can break in > > the debugger and look at the PRAM for the EDMA. > > > > At this point my code uses linked PRAMS for receive and a single PRAM > > for transmit. The only problem I am having is when the data I want to > > transmit it bigger than my edma buffer. It seems that sometimes I end up > > clobbering the EDMA with a new buffer before the old one is finished. > > > > How are you setting up the EDMA? > > I am setting up EDMA using following parameters > > EDMA_configArgs(hEdma14, > /* OPT Setup */ > EDMA_OPT_RMK( > EDMA_OPT_PRI_HIGH, /* 1 */ > EDMA_OPT_ESIZE_16BIT, /* 01 */ > EDMA_OPT_2DS_NO, /* 0 */ > EDMA_OPT_SUM_INC, /* 01 */ > EDMA_OPT_2DD_NO, /* 0 */ > EDMA_OPT_DUM_NONE, /* 00 */ > EDMA_OPT_TCINT_YES, /* 1 */ > EDMA_OPT_TCC_OF(14), /* 14 */ > EDMA_OPT_LINK_YES, /* 0 */ > EDMA_OPT_FS_NO /* 0 */ > ), > > /* SRC Setup */ > EDMA_SRC_RMK((Uint32) xmitbuf), /*xmitbuf address*/ > > /* CNT Setup */ > EDMA_CNT_RMK( > 0, > EDMA_CNT_ELECNT_OF(352) > ), > > /* DST Setup */ > EDMA_DST_RMK(MCBSP_getXmtAddr(hMcbsp1)), > > /* IDX Setup */ > EDMA_IDX_RMK(0,0), > > /* RLD Setup */ > EDMA_RLD_RMK(0,EDMA_RLD_OF(EDMA_getTableAddress(hEdmaDelay))) > ); > > and to restate the problem that I am facing : > > whenever I enable linking in EDMA and execute the code, McBSP transmit > line DX1 goes high, transmits data and remains low for 260msec then > goes high again. I do not want the DX line to remain low for 260msec > (since I cannot resend data for 260msec) and I do not understand why > this happens so cannot control that. > > If you have access to the code that you were working on, can you > please check what kind of output you get before linking and after > enabling linking and specifying self link address. I will really > appreciate that. > > Thanks for your comments > -Tarang > > > > _____________________________________ > > 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 > > > > > > > > > > > |
