We're using SPI over SPORT on the bf534 in our products to communicate with a SD-Card.
We've recently noticed a problem with the data being transfered using DMA.
Very rarely the last 4 bytes of the transfer simple are not written to even though they where included in the count and the DMAx_CURR_COUNT register shows 0, and the DMAx_CURR_ADDR points to the address after the data that was not written. Doing a memset of the area before the transfer to anything will show that the last bytes just was not written to.
interruptsEnabled = cli();
/* Receive from SPORT */
*pDMA3_START_ADDR = pRx;
*pDMA3_X_COUNT = length;
*pDMA3_X_MODIFY = 1;
*pDMA3_CONFIG = ( FLOW_STOP | DI_EN | WNR | WDSIZE_8 | DMAEN );
/* Transmit to SPORT */
*pDMA4_START_ADDR = &dummy;
*pDMA4_X_COUNT = length;
*pDMA4_X_MODIFY = 0;
*pDMA4_CONFIG = ( FLOW_STOP | WDSIZE_8 | DMAEN );
*pSPORT0_STAT = ( TUVF | TOVF | RUVF | ROVF ); // Clear any status bits that might be set
*pSPORT0_RCR1 |= RSPEN; /* Enable receive/transmit */
*pSPORT0_TCR1 |= TSPEN;
sti( interruptsEnabled );
Is how we set up the transfer. Length is anywhere between 1 to 512 bytes as that is our block size on the SD-Card. We've checked with an oscilloscope and made sure that the data is actually transfered correct, it just isn't handled correct somehow with what seems to be the DMA.
The only thing we've noticed that is relevant each time the problem occurs is that a core timer interrupt happens and the timer is setup again. We're using the Green Hills Velocity operating system that handles the core timer so we're not 100% sure what it actually does but it should not break the DMA transfer anyway.
Is this something that has happened to anyone else or anyone that has any input on why it happens or how to fix it?
We've looked through the errata data sheet and nothing seems really relevant to this issue.