This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SPIM3 sending wrong data/byte

I am using SPIM3 to drive a peripheral, only using tx. And I noticed that SPI is sending wrong/corrupt bytes once in a while. See below image where the code tries to send 0x12 but 0x00 goes through the wire. 

I am using below code to send the data where I have a  struct keeping the the data(pointer to it) and length of it. After each transfer (spi transfer ended event) i increment cursor to point the next chunk.. (some of the chunks are longer than 255)

Fullscreen
1
2
3
4
5
6
static bool sendBuffer(void){
xfer_desc.p_tx_buffer = epd_driver_state.buff[ epd_driver_state.cursor ].buffer;
xfer_desc.tx_length = epd_driver_state.buff[ epd_driver_state.cursor ].bufferLen;
spi_sending = true;
APP_ERROR_CHECK(nrfx_spim_xfer_dcx(&spiM, &xfer_desc, 0, epd_driver_state.buff[ epd_driver_state.cursor ].hasCmd));
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

I have several questions, first, I am wondering what could be wrong with the corrupt byte. Also note MOSI hanging high after the preceding byte, I don't know if it is related..

Second question is whether I am doing something wrong by sending data that is longer than 255 bytes. I read about spi, easyDMA etc. but cannot say that I really understood it. 

Parents
  • Hi 

    Have you tried to use SPIM0, 1 or 2 instead to see if the problem is the same?

    It is possible that you are affected by Errata 198, which affects the SPIM3 module and can lead to data corruption. 

    The workaround to this issue as explained by the errata is to put the SPI TX buffer in a separate RAM block to that used by the MCU. 


    For instance the RAM7 block, located at address 0x2000E000, would normally be free:
    https://infocenter.nordicsemi.com/topic/ps_nrf52840/memory.html?cp=3_0_0_3_1

    For more information regarding putting variables in specific memory ranges there are some existing devzone cases that you can use for reference, such as this one

    Best regards
    Torbjørn

Reply
  • Hi 

    Have you tried to use SPIM0, 1 or 2 instead to see if the problem is the same?

    It is possible that you are affected by Errata 198, which affects the SPIM3 module and can lead to data corruption. 

    The workaround to this issue as explained by the errata is to put the SPI TX buffer in a separate RAM block to that used by the MCU. 


    For instance the RAM7 block, located at address 0x2000E000, would normally be free:
    https://infocenter.nordicsemi.com/topic/ps_nrf52840/memory.html?cp=3_0_0_3_1

    For more information regarding putting variables in specific memory ranges there are some existing devzone cases that you can use for reference, such as this one

    Best regards
    Torbjørn

Children
No Data