DA14850 SPI的奴隶。主接收数据结合起来d byte.

5 posts / 0 new
Last post
Ralf S.
Offline
Last seen:4 years 3 months ago
Joined:2016-02-16 08:06
DA14850 SPI的奴隶。主接收数据结合起来d byte.

Hallo,

I have setup the Dialog board as SPI slave with additional flow-control lines. When the slave sends data to the master, the master receives them on the third byte. Except the first one or two messages after a restart of the board where the data starts at the second byte, as expected. I am not using the FIFO buffers (SPI_FIFO_MODE = 0x03). I have no Idea why this is happening. Debugging has shown that spidrv_buffer_tx holds the data like it's supposed to do, without an additional zero-byte. Is there something that I'm missing here?

The SPI driver looks like this:

void SPI_Handler_RxTx(void)
{
/* indicate TXRDY INACTIVE to master = no further reception from master until application is ready! */
SPIDRV_TXRDY_L;

/* indicate RXPEND INACTIVE to master = no further transmission to master until application is ready! */
SPIDRV_RXPEND_L;

/* lock the buffers for ISR usage */
spidrv_cntrl.isr_lock = SPIDRV_CS_H_DETECTCNT;

/* Wait until data is ready */
while ( spi_data_rdy_getf() )
{
/* -------------------------------------------------------------------------------- */
/* SPI RX PART - read the received byte (if possible) */

/* transfer this byte into our rx buffer (if possible) */
if ( spidrv_cntrl.rx_wr_idx < SPIDRV_BUFFSIZE_RX )
{
spidrv_buffer_rx[spidrv_cntrl.rx_wr_idx] = 0xFF&GetWord16(SPI_RX_TX_REG0);
spidrv_cntrl.rx_wr_idx++;
}
else
{ /* do nothing, indicate an overflow error */
spidrv_cntrl.rx_overflw++;
}

/* -------------------------------------------------------------------------------- */
/* SPI TX PART - transfer one pending byte from tx buffer into tx register (if any) */
if ( spidrv_cntrl.tx_rd_idx < spidrv_cntrl.tx_cnt )
{
SetWord16(SPI_RX_TX_REG0, 0xFF&(spidrv_buffer_tx[spidrv_cntrl.tx_rd_idx]));
spidrv_cntrl.tx_rd_idx++;
}
else
{ /* tx read index reached last byte: all done! */
SetWord16(SPI_RX_TX_REG0, 0x00);
}

/* Clear pending flag */
SetWord16(SPI_CLEAR_INT_REG, 0x01);
}

// clear IRQ (raised again, if something pending)
SetWord16(SPI_CLEAR_INT_REG, 0x01);
}

Device:
MT_dialog
Offline
Last seen:4 months 2 weeks ago
Staff
Joined:2015-06-08 11:34
Hi Ralf S,

Hi Ralf S,

In case you are using a high frequency without using the FIFOs, the interrupt hits at the end of the first 8-bit transmition (since that is the time the data is ready to be read from the SPI peripheral), so you have allready lost one complete cycle, i assume that most probably you are going to lose an additional complete cycle when reading the data from the register and placing the data to your TX buffer (the time you spend servicing the ISR). So in the 3rd transmition your SPI TX register has the desired data allready in and will be transmited. Try reducing the SPI frequency of the master and check if the issue persists or place a delay to the master between the first SPI transaction and subsequent ones in order for the SPI TX register to have the time to get the desired value.

Thanks MT_dialog

Ralf S.
Offline
Last seen:4 years 3 months ago
Joined:2016-02-16 08:06
Thanks for answering! I tried

Thanks for answering! I tried to lower the frequency of the master, but the behavior of the slave didn't change. What do You mean by placing a delay to the master? A delay between the bytes sent?

And do You have a guess why the slave sends the first frame after a reset on the second byte and only the following transmissions on the third?

Ralf S.
Offline
Last seen:4 years 3 months ago
Joined:2016-02-16 08:06
I have it working now. When I

I have it working now. When I was done with sending the message and the master still sent bytes I wrote 0x00 in the TX register. When I removed this line everything was OK, but the ISR was called too late in some cases, which lead to zero-bytes in my frame.

I implemented the RX-FIFO and I preload it when I am sending data, so the master is receiving data on the first byte and everything works fine.

But now I have a different problem when waking up from an external interrupt. Therefore I'll open a new thread!

MT_dialog
Offline
Last seen:4 months 2 weeks ago
Staff
Joined:2015-06-08 11:34
Hi Ralf S.

Hi Ralf S.

Glad you found it and thanks for letting us know. Also a big thanks you for not posting your new question on the same post.

Best Regards MT_dialog