Hi, I'm working with a LPC1758 processor and an AT45 dataflash. The dataflash communicate with the processor by SSP1 and dma.
In my first attempt: I want to read the status register from the dataflash. The specific command is a single byte 0xD7 - no addr bytes or dummy bytes have to be transmitted to the dataflash.
I setup the corresponding tx dma channel
#define tx_datasize 1 /* at45-command-size */ pHw->DMACCControl = (tx_datasize & 0x0FFF)|(0x00 << 12) |(0x00 << 15)|(0x00 << 18)|(0x00 << 21)|(1 << 26)|0x80000000;
and start the transfer.
Unfortunately the dma interrupt handler isn't called. The error seems to be due to the "tx_datasize". If I set the "tx_datasize" to 2 the dma interrupt handler is called.
I couldn't find any information in the user manual that told me that I've to increase the tx_datasize....
best regards Lars
Well, SPI is always full duplex.
Whenever the master sends a byte, it is also receiving a byte.
But lots of SPI protocols are semi-duplex. I.e. the master sends a command while the slave sends "null" bytes. Then the master sends "null" bytes while letting the slave send the actual response.
0xFF received is the default when the MISO signal is in idle state - which it is when no slave is selected or when the slave is busy receiving a command so it will know what it is expected to respond with.
So a normal SPI transfer where a 3 byte command is sent to a device and a 5 byte response is expected normally happens like:
Master sends
m1 m2 m3 ff ff ff ff ff
Master receives
ff ff ff s1 s2 s3 s4 s5
So the master must make a transfer that is long enough to cover both the transmit of the command and the reception of the following answer. It can normally throw away as many bytes as the command was long - first then will it start to receive valid response data.
And as I noted earlier: 0xff is normally the expected "filler" data on SPI - not 0x00 - unless the datasheet happens to specify something else.
Per, thanks for your explanations!
One more thing about this subject. My DMA has a four-word-FIFO and the SSP interface has a 8 frame-FIFO for Tx and Rx.
//P2M transfer settings LPC_GPDMACH1->DMACCControl = (rx_size & 0x0FFF)|(0x01 << 12)|(0x01 << 15)|(0x00 << 18)|(0x02 << 21)|(1 << 27)|0x80000000;
The burst size for tx and rx is 8 bytes and I set the destination transfer width to word-width (32-bit). The source transfer width is byte-width (8-bit).
If I send a read command + dummy bytes which has a multiple to 4 -> everything is working as expected; which means I receive 4x 0xFF and 4x data bytes from the dataflash (in the correct order).
If the read command + dummy bytes has not a multiple to 4, the dma-rx-channel doesn't work as expected, because the dma doesn't use a single-byte-transfer if needed; the dma always transfers 4x bytes (according to the destination transfer width setting). If I set the destination transfer width to byte width, any transfer independent of how many bytes are received is working as expected.
In the datasheet of the processor I read that the SSP interface is able to transfer DMA single requests as well as DMA burst requests. I might be wrong, but I thought that DMA will transfer each request with the "destination transfer width settings" only if there are lesser bytes than the destination transfer width.