Sign in
Search lpc2000
Subscribe to lpc2000
lpc2000 by Keywords
2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler
Ads
Discussion Groups
See Also
Discussion Groups | LPC2000 | questions re ssp0 rx and dma
Discussion group dedicated to the Philips LPC2000 family of ARM MCUs
questions re ssp0 rx and dma - John S - Oct 7 15:01:39 2009
On a LCP2378.
I am using PWM to toggle control lines of a a/d and start a ssp (master) transfer at a 5us interval.
I've setup the DMA to move the (16bit) data to usbram.
DMACCONFIGURATION.E=1;
DMACC0CONTROL.TransferSize = 0x100;
.SBSize = 1;
.DBSize = 1;
.SWidth = 1;
.DWidth = 2;
.SI = 0;
.DI = 1;
DMACC0SRCADDR = 0xe0068008;
DMACC0DESTADDR = 0x7fd00000;
DMACC0CONFIGURATION.SRC = 1;
.DEST = 0;
.FLOWCNTRL = 2;
.E = 1;
This fills 0x200 bytes in usbram. Twice what I expect.
Next I set .FLOWCNTRL = 6 instead of 2
then I seem to get 0x4000 bytes in usbram filled.
When .DMACC0DESTADDR gets to 0x7fd04000 it seems to set the error status bit and turns off the DMACC0CONIGURATION.E
This actually seems to do exactly what I want, which is to fill the entire memory with data, then stop when filled, but there are some things I don't understand.
1. doco indicates usbram ends at 0x7fd01fff. 1/2 of what I see.
2. I don't quite understand what .SWidth and .DWidth do.
3. There is a note about 1kb address generation burst boundary limit. Is this relevant?
4. Is there anything wrong with using the dma in this way?
5. By the next time I enable the dma to transfer the ssp data to usbram the ssp fifo will have overflowed. What now is the data in that fifo? is it most recent data? or did accumulation stop once ssp was full?
------------------------------------
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
I am using PWM to toggle control lines of a a/d and start a ssp (master) transfer at a 5us interval.
I've setup the DMA to move the (16bit) data to usbram.
DMACCONFIGURATION.E=1;
DMACC0CONTROL.TransferSize = 0x100;
.SBSize = 1;
.DBSize = 1;
.SWidth = 1;
.DWidth = 2;
.SI = 0;
.DI = 1;
DMACC0SRCADDR = 0xe0068008;
DMACC0DESTADDR = 0x7fd00000;
DMACC0CONFIGURATION.SRC = 1;
.DEST = 0;
.FLOWCNTRL = 2;
.E = 1;
This fills 0x200 bytes in usbram. Twice what I expect.
Next I set .FLOWCNTRL = 6 instead of 2
then I seem to get 0x4000 bytes in usbram filled.
When .DMACC0DESTADDR gets to 0x7fd04000 it seems to set the error status bit and turns off the DMACC0CONIGURATION.E
This actually seems to do exactly what I want, which is to fill the entire memory with data, then stop when filled, but there are some things I don't understand.
1. doco indicates usbram ends at 0x7fd01fff. 1/2 of what I see.
2. I don't quite understand what .SWidth and .DWidth do.
3. There is a note about 1kb address generation burst boundary limit. Is this relevant?
4. Is there anything wrong with using the dma in this way?
5. By the next time I enable the dma to transfer the ssp data to usbram the ssp fifo will have overflowed. What now is the data in that fifo? is it most recent data? or did accumulation stop once ssp was full?
------------------------------------
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
Re: questions re ssp0 rx and dma - rolf_meeser - Oct 7 16:27:18 2009
Hi John,
--- In l...@yahoogroups.com, "John S" wrote:
>
> On a LCP2378.
> I am using PWM to toggle control lines of a a/d and start a ssp (master) transfer at a 5us interval.
> I've setup the DMA to move the (16bit) data to usbram.
>
> DMACCONFIGURATION.E=1;
>
> DMACC0CONTROL.TransferSize = 0x100;
> .SBSize = 1;
> .DBSize = 1;
> .SWidth = 1;
> .DWidth = 2;
> .SI = 0;
> .DI = 1;
>
> DMACC0SRCADDR = 0xe0068008;
> DMACC0DESTADDR = 0x7fd00000;
>
> DMACC0CONFIGURATION.SRC = 1;
> .DEST = 0;
> .FLOWCNTRL = 2;
> .E = 1;
>
> This fills 0x200 bytes in usbram. Twice what I expect.
>
The TransferSize field of the control register holds the number of source transfers to be done, not the number of bytes. As you have configured a source width of 16 bits, the total number of bytes is 2*0x100. What you configure is what you get :-)
> Next I set .FLOWCNTRL = 6 instead of 2
> then I seem to get 0x4000 bytes in usbram filled.
>
You cannot use the SSP as the flow controller for a DMA transfer. The flow controller is the guy who knows when the whole DMA block is through. The SSP has no such concept, and cannot end a DMA block. As a consequence, the DMA only stops when it gets an abort beyond the SRAM bounds. (Note that the TransferSize field is ignored when the DMA is not the flow controller).
.FLOWCNTRL=2 is your only option.
> 2. I don't quite understand what .SWidth and .DWidth do.
In your application, .SWidth must be set to the frame size of the SSP. You work width 16-bit frames, so your setting is fine.
.DWidth (here) controls the access to the memory. 32-bit access is most efficient for this device. If you chose .DWidth=1, the DMA would waste bus bandwidth by doing twice the number of write cycles.
However, the transferred data must be a multiple of 32 bits, if you choose .DWidth=2! The destination address has to be aligned to 32 bits as well.
> 3. There is a note about 1kb address generation burst boundary limit. Is this relevant?
You have correctly configured a burst size of four (half of the eight frames the SSP FIFO can hold). A burst therefore consists of 8 bytes (16-bit frame!). As long as your destination buffer is aligned to an 8-byte grid, a burst will never cross a 1-KB boundary. So there is no problem.
> 4. Is there anything wrong with using the dma in this way?
I'm wondering why your DMA transfer works at all :-)
You say that you are using the SSP in master mode, but then you need to feed the SSP TX channel in order to get RX DMA requests. In master RX mode, you need to setup both channels, one of them sending dummy TX frames.
For SSP slave mode, your setup is ok.
> 5. By the next time I enable the dma to transfer the ssp data to usbram the ssp fifo will have overflowed. What now is the data in that fifo? is it most recent data? or did accumulation stop once ssp was full?
>
Hmmm, I don't know... It might better to drain the SSP RX FIFO anyway as part of the DMA transfer setup.
Regards,
Rolf
------------------------------------
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
--- In l...@yahoogroups.com, "John S"
>
> On a LCP2378.
> I am using PWM to toggle control lines of a a/d and start a ssp (master) transfer at a 5us interval.
> I've setup the DMA to move the (16bit) data to usbram.
>
> DMACCONFIGURATION.E=1;
>
> DMACC0CONTROL.TransferSize = 0x100;
> .SBSize = 1;
> .DBSize = 1;
> .SWidth = 1;
> .DWidth = 2;
> .SI = 0;
> .DI = 1;
>
> DMACC0SRCADDR = 0xe0068008;
> DMACC0DESTADDR = 0x7fd00000;
>
> DMACC0CONFIGURATION.SRC = 1;
> .DEST = 0;
> .FLOWCNTRL = 2;
> .E = 1;
>
> This fills 0x200 bytes in usbram. Twice what I expect.
>
The TransferSize field of the control register holds the number of source transfers to be done, not the number of bytes. As you have configured a source width of 16 bits, the total number of bytes is 2*0x100. What you configure is what you get :-)
> Next I set .FLOWCNTRL = 6 instead of 2
> then I seem to get 0x4000 bytes in usbram filled.
>
You cannot use the SSP as the flow controller for a DMA transfer. The flow controller is the guy who knows when the whole DMA block is through. The SSP has no such concept, and cannot end a DMA block. As a consequence, the DMA only stops when it gets an abort beyond the SRAM bounds. (Note that the TransferSize field is ignored when the DMA is not the flow controller).
.FLOWCNTRL=2 is your only option.
> 2. I don't quite understand what .SWidth and .DWidth do.
In your application, .SWidth must be set to the frame size of the SSP. You work width 16-bit frames, so your setting is fine.
.DWidth (here) controls the access to the memory. 32-bit access is most efficient for this device. If you chose .DWidth=1, the DMA would waste bus bandwidth by doing twice the number of write cycles.
However, the transferred data must be a multiple of 32 bits, if you choose .DWidth=2! The destination address has to be aligned to 32 bits as well.
> 3. There is a note about 1kb address generation burst boundary limit. Is this relevant?
You have correctly configured a burst size of four (half of the eight frames the SSP FIFO can hold). A burst therefore consists of 8 bytes (16-bit frame!). As long as your destination buffer is aligned to an 8-byte grid, a burst will never cross a 1-KB boundary. So there is no problem.
> 4. Is there anything wrong with using the dma in this way?
I'm wondering why your DMA transfer works at all :-)
You say that you are using the SSP in master mode, but then you need to feed the SSP TX channel in order to get RX DMA requests. In master RX mode, you need to setup both channels, one of them sending dummy TX frames.
For SSP slave mode, your setup is ok.
> 5. By the next time I enable the dma to transfer the ssp data to usbram the ssp fifo will have overflowed. What now is the data in that fifo? is it most recent data? or did accumulation stop once ssp was full?
>
Hmmm, I don't know... It might better to drain the SSP RX FIFO anyway as part of the DMA transfer setup.
Regards,
Rolf
------------------------------------
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
Re: questions re ssp0 rx and dma - John S - Oct 7 16:46:33 2009
Thx Rolf,
--- In l...@yahoogroups.com, "rolf_meeser" wrote:
>
> > 4. Is there anything wrong with using the dma in this way?
>
> I'm wondering why your DMA transfer works at all :-)
> You say that you are using the SSP in master mode, but then you need to feed the SSP TX channel in order to get RX DMA requests. In master RX mode, you need to setup both channels, one of them sending dummy TX frames.
I use one of the PWM channels to generate an interrupt (fiq) a bit after the control lines are finished with the sole purpose to write to SSP0DR.
I originally had the ssp setup as a slave, but the slave is limited (6mhz) and the timing didn't quite work.
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )
--- In l...@yahoogroups.com, "rolf_meeser"
>
> > 4. Is there anything wrong with using the dma in this way?
>
> I'm wondering why your DMA transfer works at all :-)
> You say that you are using the SSP in master mode, but then you need to feed the SSP TX channel in order to get RX DMA requests. In master RX mode, you need to setup both channels, one of them sending dummy TX frames.
I use one of the PWM channels to generate an interrupt (fiq) a bit after the control lines are finished with the sole purpose to write to SSP0DR.
I originally had the ssp setup as a slave, but the slave is limited (6mhz) and the timing didn't quite work.
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )