microSD card in SPI mode timing - c

I'm writing and reading values on a SD card in SPI mode. The frequency for writing and reading blocks of 512 bytes is set to 10Mhz. For writing a block it takes about 5ms and timing between blocks is about 10 ms.
Is any way to improve the speed of writing?
void sd_card_write_block(uint16 blockNumber, uint8* buffer)
{
uint16 blockLow = 0;
uint16 blockHigh = 0;
uint8 dummy = 0;
uint8 result = 0;
uint8 data_block_start_byte = 0;
uint8 write_command[SD_CMD_SIZE] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
uint8 dummy_buffer[DUMMY_BUFFER_LENGTH] = {0xFF, 0xFF, 0xFF, 0xFF,0xFF, 0xFF, 0xFF, 0xFF};
uint8 i = 0;
uint8 check_response[CHECK_RESPONSE_SIZE] = {0x00, 0x00, 0x00};
uint8 check_response1[CHECK_RESPONSE_SIZE] = {0x00, 0x00, 0x00};
uint8 r1 = 0;
uint16 retry = 0;
uint8 response1 = 0;
dummy = 0xFF;
//initialize the dummy buffer to keep MOSI pin High
for(i = 0; i < DUMMY_BUFFER_LENGTH; i++)
{
dummy_buffer[i] = 0xFF;
}
//set CS pin low
spi_select_slave( &spi_master_instance, &slave, true);
//send three clock cycles with MOSI HIGH (Ncs)
spi_write_buffer_wait( &spi_master_instance, dummy_buffer, NCS_LENGTH);
//block size was set in sd_init
blockLow = ((blockNumber & 0x003F) << 9);
blockHigh = ((blockNumber & 0xFFC0) >> 7);
//send SD CMD24(WRITE_SINGLE_BLOCK) to write the data to SD card
write_command[0] = 0x58;
//high block address bits, blockHigh HIGH and LOW
write_command[1] = (blockHigh >> 0x08);
write_command[2] = (blockHigh & 0xFF);
//low block address bits, blockLow HIGH and LOW
write_command[3] = (blockLow >> 0x08);
write_command[4] = (blockLow & 0xFF);
//checksum is no longer required but send 0xFF
write_command[5] = 0xFF;
spi_write_buffer_wait( &spi_master_instance, write_command, SD_CMD_SIZE);
spi_transceive_buffer_wait( &spi_master_instance, dummy_buffer, check_response, CHECK_RESPONSE_SIZE);
//send three clock cycles with MOSI High
spi_write_buffer_wait( &spi_master_instance, dummy_buffer, DUMMY_BUFFER_LENGTH);
//set bit 0 to 0 which indicates the beginning of the data block
data_block_start_byte = DATA_BLOCK_START_TOKEN;
spi_transceive_buffer_wait( &spi_master_instance, &data_block_start_byte, &result, SD_RESPONSE_SIZE);
/*takes so long because its similar to transreceivea and it discards the rx*/
spi_write_buffer_wait( &spi_master_instance, buffer, SD_BLOCK_LENGTH);
//read the microSD card response
spi_transceive_buffer_wait( &spi_master_instance, dummy_buffer, check_response1, CHECK_RESPONSE_SIZE);
do
{
// write dummy byte
spi_transceive_buffer_wait( &spi_master_instance, &dummy, &response1, SD_RESPONSE_SIZE);
r1 = response1;
// do retry counter
retry++;
if(retry > MAX_TIMEOUT)
{
spi_select_slave( &spi_master_instance, &slave, false);
break;
}
}
while(r1 == END_OF_BLOCK_RESPONSE);
//set the CS High
spi_select_slave( &spi_master_instance, &slave, false);
}

You can't, atleast not by much. The reason being that the SPI mode itself is the bottleneck. So, you can use a few tricks here and there to get that speed up, but you really won't be benifitting much from it. I'd advise you to use SDIO if you really need that much speed (It's not as complicated as you might think). If you're using an AVR, try the xmega lineup (Don't quote me on that, I'm not quite informed in the AVR, since I use ARMs), or switch to another lineup completely.

In order to get high write speeds, you need to:
- use a faster clock
- use a wider bus
- Write larger blocks (2k or 4k) at a time
In other words, you pretty much need to use the SDIO spec.
There's also ways to begin a large sequential transaction and not end it until all the data has been received (but maybe that's in the SDIO spec and not the SPI command interface). These sort of hints tells the controller that it can prepare a large section of the flash and not commit the write buffer until it's full.
And even then, you can end up with "very long" write cycles occasionally, so you cannot rely upon an SD card to stream high speed data off in real time without buffers on your side to handle the latency blips.

You should have posted your spi_write_buffer_wait code but consider something like this:
Rearange the stuff in your actual write function where you send the data. Think about it. You have to wait until the SD Card indicates you, that the byte was written successfully. Use this "useless" wait time to prepare the next data.
/* write a single block */
for ( i = MMC_BLOCKLEN; i > 0; i-- ) {
uint8_t data = *buffer;
buffer++;
wait_till_send_done();
xmit_byte ( data );
}
wait_till_send_done();
There you prepare the byte to send and also move the pointer one byte forward before you start waiting for the SD Card to indicate its successfull writing of the previous byte.
It is also a good idea to check the generated ASM code...
If you are about to write more than 512bytes of data, consider using multiblock writes (4k blocks for example at once).
Usually SD cards have internal block sizes of more than 512bytes. So to write 512 bytes, they have to internally read for example 4k, exchange your 512bytes and write everything back... so to write more data at once is always a good idea...

Related

Transmitting over UART on STM32

Hello i am using an STM32 as the host mcu for a SI4362 radio. the radio uses SPI communication to initialize. although i am stepping through meaning i believe to be receiving correct CTS from the radio it is not working. i would like to transmit everything i send and receive from the SPI out to a UART terminal for debug.
Here is a sample of what i am sending:
uint8_t RF_POWER_UP[7] = { 0x02, 0x01, 0x01, 0x01, 0xC9, 0xC3, 0x80};
I would like to send the bytes over SPI as designated in the datasheet, and then promptly send the output over UART for debugging more easily something like this:
uart_buf_len = sprintf(uart_buf, "\r\nSPI Test\r\n");
HAL_UART_Transmit(&huart1, (uint8_t*) uart_buf, uart_buf_len, 100)
HAL_GPIO_WritePin(SDN_GPIO_Port, SDN_Pin, GPIO_PIN_RESET);
HAL_GPIO_WritePin(SS_GPIO_Port, SS_Pin, GPIO_PIN_RESET);
HAL_SPI_Transmit(&hspi1, RF_POWER_UP, 7, 50);
//convert RF_POWER_UP to something the UART can transmit in plain text
HAL_UART_Transmit(&huart1, RF_POWER_UP, 7, 50);
do {
HAL_SPI_Receive(&hspi1, (uint8_t*) spi_buf, 1, 100);
//convert spi buf to something the UART can transmit in plain text
HAL_UART_Transmit(&huart1, (uint8_t*) spi_buf, 1, 100);
} while (*spi_buf != 0xFF);
HAL_GPIO_WritePin(SS_GPIO_Port, SS_Pin, GPIO_PIN_SET);
so i feel that writing a function might make the most sense. i found a helpful post using memcopy, but it converted the bytes into the equivalent ascii value basically returning the equal result. i am now actively searching the correct and appropriate return value for the needed function as well as propper code inside. i just wanted to make the edits to the post in the meantime as requested.
thank you
I found some helpful tools on this stack overflow that gave me what i needed. i dont quite understand whats going on with the shifting. if someone would like to bring clarity i would appreciate that.
void btox(char *xp, const char *bb, int n) {
const char xx[] = "0123456789ABCDEF";
while (--n >= 0)
xp[n] = xx[(bb[n >> 1] >> ((1 - (n & 1)) << 2)) & 0xF];
}
from what i gather i am calling the program with a pointer to the first address of an empty string identified in main using xp and likewise the byte aray using bb. also passing the size of the array of bytes as sizeof would only pass the size of the address.
xx[] is the array containing defining characters to be used for the byte to string conversion.
so running through a while loop until n-1 >= to zero
and i start to get very lost very fast.
it is working but i don't fully understand the code.

SPI slave read data into buffer on stm32?

I'm trying to set communication between esp32 (master) and stm32 (slave) over SPI. esp32 is running under micropython and sends four bytes, for example
spi.write_readinto(b'\x31\x32\x33\x34', buf)
stm32' code is here (instead of this i use SPI_InitDef.SPI_NSS = SPI_NSS_Soft;)
void SPI_Init(void) {
...
// initialize SPI slave
// for slave, no need to define SPI_BaudRatePrescaler
SPI_InitDef.SPI_Direction = SPI_Direction_2Lines_FullDuplex;
SPI_InitDef.SPI_Mode = SPI_Mode_Slave;
SPI_InitDef.SPI_DataSize = SPI_DataSize_8b; // 8-bit transactions
SPI_InitDef.SPI_FirstBit = SPI_FirstBit_MSB; // MSB first
SPI_InitDef.SPI_CPOL = SPI_CPOL_Low; // CPOL = 0, clock idle low
SPI_InitDef.SPI_CPHA = SPI_CPHA_2Edge; // CPHA = 1
SPI_InitDef.SPI_NSS = SPI_NSS_Hard; // use hardware SS
SPI_InitDef.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_64; // APB2 72/64 = 1.125 MHz
SPI_InitDef.SPI_CRCPolynomial = 7;
SPI_Init(SPI1, &SPI_InitDef);
SPI_Cmd(SPI1, ENABLE);
NVIC_EnableIRQ(SPI1_IRQn);
//Тут мы разрешаем прерывание по приему
SPI_I2S_ITConfig(SPI1, SPI_I2S_IT_RXNE, ENABLE);
}
void main() {
/* Setup SysTick Timer for 10ms interrupts */
if (SysTick_Config(SystemCoreClock / 100))
{
/* Capture error */
while (1);
}
/* Configure the SysTick handler priority */
NVIC_SetPriority(SysTick_IRQn, 0x0);
SPI_Init();
while(1) {
while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE));
for (u8 i=0; i<4; i++) {
printf("0x%02x ", SPI_I2S_ReceiveData(SPI1));
}
printf("\r\n");
}
}
But when I send four bytes 0x31 0x32 0x33 0x34 (analyzer confirms bytes were sent) and my stm gets only 0x31 0x32 0x31 0x32
UPD
I use std periph library and SPI_I2S_ReceiveData is a native method to read byte from SPI.
uint16_t SPI_I2S_ReceiveData ( SPI_TypeDef * SPIx )
Returns the most recent received data by the SPIx/I2Sx peripheral.
Parameters:
SPIx,: To select the SPIx/I2Sx peripheral, where x can be: 1, 2 or 3 in SPI mode or 2 or 3 in I2S mode or I2Sxext for I2S full duplex mode.
Return values:
The value of the received data.
uint16_t SPI_I2S_ReceiveData ( SPI_TypeDef * SPIx )
Returns the most recent received data by the SPIx/I2Sx peripheral.
Parameters:
SPIx,: To select the SPIx/I2Sx peripheral, where x can be: 1, 2 or 3 in SPI mode or 2 or 3 in I2S mode or I2Sxext for I2S full duplex mode.
Return values:
The value of the received data.
But maybe I exit out from IRQ before all data are read. I found to run the while loop until the transmission of the last byte is complete
I think the following code is not correct (but I don't know what the function SPI_I2S_ReceiveData is doing):
while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE));
for (u8 i=0; i<4; i++) {
printf("0x%02x ", SPI_I2S_ReceiveData(SPI1));
}
You exit from the while as soon as one byte is ready to be read. I assume SPI_I2S_ReceiveData is only reading the SPI FIFO. in that case you try to read 4 bytes when possibly only one or two has been received.
You didn't precise the kind of STM32 you're using so I am describing the SPI of STM32H7 (as far as I know it should be pretty similar in other STM32).
To setup a reception in slave mode you should define in particular these 3 parameters:
the length of the socalled "frame" (number of bytes to be read/written at once). This is the field SPI_DataSize` in the HAL data structure, here 8 bits.
the number of transfer (TSIZE) which specifies when the End Of Transmission event is generated. It is expressed in number of "frames". This parameter must be set through register SPI.CR2 before each reception (provided you know the number of bytes to be received of course).
the "FIFO threshold". It specifies at which frequency an event RXP or TXP is generated. You can change this parameter to decrease the workload on the software but to receive only 4 bytes it has no impact.
In your case I think you should setup a transfer size of 4 (4 bytes) and wait for EOT flag to be set. When it is set you only have to read 4 bytes from SPI Receive Register (you can read all 4 bytes at once by the way).
I suggest you do not use the HAL but write your own SPI reception / transmission routines by reading / writing registers. It is not a very complex peripheral (so it will not cost you a lot of time) and you will understand precisely how it works (instead of digging into the HAL).

M95128-W EEPROM. First byte of each page not writing or reading correctly

I am working on a library for controlling the M95128-W EEPROM from an STM32 device. I have the library writing and reading back data however the first byte of each page it not as expected and seems to be fixed at 0x04.
For example I write 128 bytes across two pages starting at 0x00 address with value 0x80. When read back I get:
byte[0] = 0x04;
byte[1] = 0x80;
byte[2] = 0x80;
byte[3] = 0x80;
.......
byte[64] = 0x04;
byte[65] = 0x80;
byte[66] = 0x80;
byte[67] = 0x80;
I have debugged the SPI with a logic analyzer and confirmed the correct bytes are being sent. When using the logic analyzer on the read command the mysterios 0x04 is transmitted from the EEPROM.
Here is my code:
void FLA::write(const void* data, unsigned int dataLength, uint16_t address)
{
int pagePos = 0;
int pageCount = (dataLength + 64 - 1) / 64;
int bytePos = 0;
int startAddress = address;
while (pagePos < pageCount)
{
HAL_GPIO_WritePin(GPIOB,GPIO_PIN_2, GPIO_PIN_SET); // WP High
chipSelect();
_spi->transfer(INSTRUCTION_WREN);
chipUnselect();
uint8_t status = readRegister(INSTRUCTION_RDSR);
chipSelect();
_spi->transfer(INSTRUCTION_WRITE);
uint8_t xlow = address & 0xff;
uint8_t xhigh = (address >> 8);
_spi->transfer(xhigh); // part 1 address MSB
_spi->transfer(xlow); // part 2 address LSB
for (unsigned int i = 0; i < 64 && bytePos < dataLength; i++ )
{
uint8_t byte = ((uint8_t*)data)[bytePos];
_spi->transfer(byte);
printConsole("Wrote byte to ");
printConsoleInt(startAddress + bytePos);
printConsole("with value ");
printConsoleInt(byte);
printConsole("\n");
bytePos ++;
}
_spi->transfer(INSTRUCTION_WRDI);
chipUnselect();
HAL_GPIO_WritePin(GPIOB,GPIO_PIN_2, GPIO_PIN_RESET); //WP LOW
bool writeComplete = false;
while (writeComplete == false)
{
uint8_t status = readRegister(INSTRUCTION_RDSR);
if(status&1<<0)
{
printConsole("Waiting for write to complete....\n");
}
else
{
writeComplete = true;
printConsole("Write complete to page ");
printConsoleInt(pagePos);
printConsole("# address ");
printConsoleInt(bytePos);
printConsole("\n");
}
}
pagePos++;
address = address + 64;
}
printConsole("Finished writing all pages total bytes ");
printConsoleInt(bytePos);
printConsole("\n");
}
void FLA::read(char* returndata, unsigned int dataLength, uint16_t address)
{
chipSelect();
_spi->transfer(INSTRUCTION_READ);
uint8_t xlow = address & 0xff;
uint8_t xhigh = (address >> 8);
_spi->transfer(xhigh); // part 1 address
_spi->transfer(xlow); // part 2 address
for (unsigned int i = 0; i < dataLength; i++)
returndata[i] = _spi->transfer(0x00);
chipUnselect();
}
Any suggestion or help appreciated.
UPDATES:
I have tried writing sequentially 255 bytes increasing data to check for rollover. The results are as follows:
byte[0] = 4; // Incorrect Mystery Byte
byte[1] = 1;
byte[2] = 2;
byte[3] = 3;
.......
byte[63] = 63;
byte[64] = 4; // Incorrect Mystery Byte
byte[65] = 65;
byte[66] = 66;
.......
byte[127] = 127;
byte[128] = 4; // Incorrect Mystery Byte
byte[129} = 129;
Pattern continues. I have also tried writing just 8 bytes from address 0x00 and the same problem persists so I think we can rule out rollover.
I have tried removing the debug printConsole and it has had no effect.
Here is a SPI logic trace of the write command:
And a close up of the first byte that is not working correctly:
Code can be viewed on gitlab here:
https://gitlab.com/DanielBeyzade/stm32f107vc-home-control-master/blob/master/Src/flash.cpp
Init code of SPI can be seen here in MX_SPI_Init()
https://gitlab.com/DanielBeyzade/stm32f107vc-home-control-master/blob/master/Src/main.cpp
I have another device on the SPI bus (RFM69HW RF Module) which works as expected sending and receiving data.
The explanation was actually already given by Craig Estey in his answer. You do have a rollover. You write full page and then - without cycling the CS pin - you send INSTRUCTION_WRDI command. Guess what's the binary code of this command? If you guessed that it's 4, then you're absolutely right.
Check your code here:
chipSelect();
_spi->transfer(INSTRUCTION_WRITE);
uint8_t xlow = address & 0xff;
uint8_t xhigh = (address >> 8);
_spi->transfer(xhigh); // part 1 address MSB
_spi->transfer(xlow); // part 2 address LSB
for (unsigned int i = 0; i < 64 && bytePos < dataLength; i++ )
{
uint8_t byte = ((uint8_t*)data)[bytePos];
_spi->transfer(byte);
// ...
bytePos ++;
}
_spi->transfer(INSTRUCTION_WRDI); // <-------------- ROLLOEVER!
chipUnselect();
With these devices, each command MUST start with cycling CS. After CS goes low, the first byte is interpreted as command. All remaining bytes - until CS is cycled again - are interpreted as data. So you cannot send multiple commands in a single "block" with CS being constantly pulled low.
Another thing is that you don't need WRDI command at all - after the write instruction is terminated (by CS going high), the WEL bit is automatically reset. See page 18 of the datasheet:
The Write Enable Latch (WEL) bit, in fact, becomes reset by any of the
following events:
• Power-up
• WRDI instruction execution
• WRSR instruction completion
• WRITE instruction completion.
Caveat: I don't have a definitive solution, just some observations and suggestions [that would be too large for a comment].
From 6.6: Each time a new data byte is shifted in, the least significant bits of the internal address counter are incremented. If more bytes are sent than will fit up to the end of the page, a condition known as “roll-over” occurs. In case of roll-over, the bytes exceeding the page size are overwritten from location 0 of the same page.
So, in your write loop code, you do: for (i = 0; i < 64; i++). This is incorrect in the general case if the LSB of address (xlow) is non-zero. You'd need to do something like: for (i = xlow % 64; i < 64; i++)
In other words, you might be getting the page boundary rollover. But, you mentioned that you're using address 0x0000, so it should work, even with the code as it exists.
I might remove the print statements from the loop as they could have an effect on the serialization timing.
I might try this with an incrementing data pattern: (e.g.) 0x01,0x02,0x03,... That way, you could see which byte is rolling over [if any].
Also, try writing a single page from address zero, and write less than the full page size (i.e. less that 64 bytes) to guarantee that you're not getting rollover.
Also, from figure 13 [the timing diagram for WRITE], it looks like once you assert chip select, the ROM wants a continuous bit stream clocked precisely, so you may have a race condition where you're not providing the data at precisely the clock edge(s) needed. You may want to use the logic analyzer to verify that the data appears exactly in sync with clock edge as required (i.e. at clock rising edge)
As you've probably already noticed, offset 0 and offset 64 are getting the 0x04. So, this adds to the notion of rollover.
Or, it could be that the first data byte of each page is being written "late" and the 0x04 is a result of that.
I don't know if your output port has a SILO so you can send data as in a traditional serial I/O port or do you have to maintain precise bit-for-bit timing (which I presume the _spi->transfer would do)
Another thing to try is to write a shorter pattern (e.g. 10 bytes) starting at a non-zero address (e.g. xhigh = 0; xlow = 4) and the incrementing pattern and see how things change.
UPDATE:
From your update, it appears to be the first byte of each page [obviously].
From the exploded view of the timing, I notice SCLK is not strictly uniform. The pulse width is slightly erratic. Since the write data is sampled on the clock rising edge, this shouldn't matter. But, I wonder where this comes from. That is, is SCLK asserted/deasserted by the software (i.e. transfer) and SCLK is connected to another GPIO pin? I'd be interested in seeing the source for the transfer function [or a disassembly].
I've just looked up SPI here: https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus and it answers my own question.
From that, here is a sample transfer function:
/*
* Simultaneously transmit and receive a byte on the SPI.
*
* Polarity and phase are assumed to be both 0, i.e.:
* - input data is captured on rising edge of SCLK.
* - output data is propagated on falling edge of SCLK.
*
* Returns the received byte.
*/
uint8_t SPI_transfer_byte(uint8_t byte_out)
{
uint8_t byte_in = 0;
uint8_t bit;
for (bit = 0x80; bit; bit >>= 1) {
/* Shift-out a bit to the MOSI line */
write_MOSI((byte_out & bit) ? HIGH : LOW);
/* Delay for at least the peer's setup time */
delay(SPI_SCLK_LOW_TIME);
/* Pull the clock line high */
write_SCLK(HIGH);
/* Shift-in a bit from the MISO line */
if (read_MISO() == HIGH)
byte_in |= bit;
/* Delay for at least the peer's hold time */
delay(SPI_SCLK_HIGH_TIME);
/* Pull the clock line low */
write_SCLK(LOW);
}
return byte_in;
}
So, the delay times need be at least the ones the ROM needs. Hopefully, you can verify that is the case.
But, I also notice that on the problem byte, the first bit of the data appears to lag its rising clock edge. That is, I would want the data line to be stabilized before clock rising edge.
But, that assumes CPOL=0,CPHA=1. Your ROM can be programmed for that mode or CPOL=0,CPHA=0, which is the mode used by the sample code above.
This is what I see from the timing diagram. It implies that the transfer function does CPOL=0,CPHA=0:
SCLK
__
| |
___| |___
DATA
___
/ \
/ \
This is what I originally expected (CPOL=0,CPHA=1) based on something earlier in the ROM document:
SCLK
__
| |
___| |___
DATA
___
/ \
/ \
The ROM can be configured to use either CPOL=0,CPHA=0 or CPOL=1,CPHA=1. So, you may need to configure these values to match the transfer function (or vice-versa) And, verify that the transfer function's delay times are adequate for your ROM. The SDK may do all this for you, but, since you're having trouble, double checking this may be worthwhile (e.g. See Table 18 et. al. in the ROM document).
However, since the ROM seems to respond well for most byte locations, the timing may already be adequate.
One thing you might also try. Since it's the first byte that is the problem, and here I mean first byte after the LSB address byte, the memory might need some additional [and undocumented] setup time.
So, after the transfer(xlow), add a small spin loop after that before entering the data transfer loop, to give the ROM time to set up for the write burst [or read burst].
This could be confirmed by starting xlow at a non-zero value (e.g. 3) and shortening the transfer. If the problem byte tracks xlow, that's one way to verify that the setup time may be required. You'd need to use a different data value for each test to be sure you're not just reading back a stale value from a prior test.

Using DMA to read EEPROM on SPI (SSP) Bus

I'm using an NXP LH79525, ARM7TDMI based processor. There is an EEPROM connected via SPI bus to the SSP port.
The objective is to read the EEPROM into SRAM for faster accessing.
The present working code sends a read command to the EEPROM, the reads the data byte per byte, which takes a long time.
I want to use the DMA to read EEPROM on the SPI bus directly, without intervention from the CPU.
Here is my code snippet:
// Initialize the DMA for use with SPI bus.
// Source is the EEPROM on the SPI bus.
// Destination is "buffer".
p_dma_stream_2->source_low = 0U;
p_dma_stream_2->source_high = 0U;
const uint32_t dest_addr = (uint32_t) buffer;
p_dma_stream_2->dest_low = (dest_addr & 0xFFFFU);
p_dma_stream_2->dest_high = (dest_addr >> 16U);
p_dma_stream_2->max_count = bytesToRead;
*p_dma_intr_mask = 0U; // Disable all dma interrupts.
*p_dma_intr_clear = 0xFF; // Clear the interrupts.
SSP->dmacr = 0x01; // Enable reading with DMA
p_dma_stream_2->control = 0x06U; // + 0x01 to enable transfer.
// 0x400 - status of stream 2. 1 == stream is active.
uint32_t status = *p_dma_status;
while ((status & 0x400U) != 0U)
{
OSTimeDelay(10U); // 10 milliseconds
status = *p_dma_status;
}
I'm reading incorrect values from the EEPROM when using the above example.
The DMA registers are counting correctly.
The SSP is already initialized before this code fragment, for reading bytes.
I'm looking for a working code example snippet, but haven't found any on the web.
According to this User's Guide table 5-1 it seems as SSPRX is assigned to Stream 0 and supports only half-word source data width (table 5-15).
Your code seems to use Stream 2 and byte adressing.

DMA interrupt for SPI

I'm trying to recreate a project of writing to an SD card (using FatFS) for a dsPIC33FJ128GP802 microcontroller.
Currently to collect the date from the SPI I have a do/while that loops 512 times and writes a dummy value to the SPI buffer, wait for the SPI flag, then read the SPI value, like so:
int c = 512;
do {
SPI1BUF = 0xFF;
while (!_SPIRBF);
*p++ = SPI1BUF;
} while (--c);
I'm trying to recreate this using the DMA intterupts but it's not working like I had hoped. I'm using one DMA channel, SPI is in 8 bit mode for the time being, so DMA is in byte mode, it's also in 'null write' mode, and continuous without ping pong. My buffers are only one member arrays and the DMA is matched.
DMA2CONbits.CHEN = 0; //Disable DMA
DMA2CONbits.SIZE = 1; //Receive bytes (8 bits)
DMA2CONbits.DIR = 0; //Receive from SPI to DMA
DMA2CONbits.HALF = 0; //Receive full blocks
DMA2CONbits.NULLW = 1; //null write mode on
DMA2CONbits.AMODE = 0; //Register indirect with post-increment
DMA2CONbits.MODE = 0; //continuous mode without ping-pong
DMA2REQbits.IRQSEL = 10; //Transfer done (SPI)
DMA2STA = __builtin_dmaoffset(SPIBuffA); //receive buffer
DMA2PAD = (volatile unsigned int) &SPI1BUF;
DMA2CNT = 0; //transfer count = 1
IFS1bits.DMA2IF = 0; //Clear DMA interrupt
IEC1bits.DMA2IE = 1; //Enable DMA interrupt
From what I understand from the null write mode, the DMA will write a null value every time a read is performed. However, the DMA wont start until an initial write is performed by the CPU, so I've used the manual/force method to start the DMA.
DMA1CONbits.CHEN = 1; //Enable DMA
DMA1REQbits.FORCE = 1; //Manual write
The interrupt will now start, and runs without error. However the code later shows that the collection was incorrect.
My interrupt is simple in that all I'm doing is placing the collected data (which I assume is placed in my DMAs buffer as allocated above) into a pointer which is used throughout my program.
void __attribute__((interrupt, no_auto_psv)) _DMA2Interrupt(void) {
if (RxDmaBuffer == 513) {
DMA2CONbits.CHEN = 0;
rxFlag = 1;
} else {
buffer[RxDmaBuffer] = SPI1BUF;
RxDmaBuffer++;
}
IFS1bits.DMA2IF = 0; // Clear the DMA0 Interrupt Flag
}
When the interrupt has run 512 times, I stop the DMA and throw a flag.
What am I missing? How is this not the same as the non-DMA method? Is it perhaps the lack of the while loop which waits for the completion of the SPI transmission (while (!_SPIRBF);). Unfortunately with the null write mode automatically sending and receiving the SPI data I can't manually put any sort of wait in.
I've also tried using two DMA channels, one to write and one to read, but this also didn't work (plus I need that channel later for when I come to proper writing to the SD card).
Any help would be great!

Resources