• State Verified Answer
  • Replies 4 replies
  • Subscribers 63 subscribers
  • Views 7014 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 111634
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrf_drv_spi_transfer larger transfer size

kane

Hi,

I'm working with an SPI FLASH chip that has a page size 256. I noticed that when I call nrf_drv_spi_transfer(), the rx length of 256 rolls over the uint8_t container and is zero!

Digging deeper, I found that the RX size is used for nrf_spim_rx_buffer_set(), also taking the argument as uint8_t. This function sets p_spim->RXD.MAXCNT = length; MAXCNT is size uint32_t. Is there a reason I shouldn't mess with these sizes?

I'm also thinking I'd need a tx buffer size at least 256 to write a page at a time.

Parents
  • 0

    I just ran into the same issue, but on an nRF51 without the EasyDMA limitation. I ported code from against an older SDK to SDK 10, and am transferring a 520 bytes stream from a SPI slave.

    I have changed the nrf_drv_spi uint8_t to uint16_t in a few spots as when using programmed I/O (i.e. byte-by-byte, driven by the CPU) there is no limitation in the SPI message lengths.

    I agree that silicon should have provided 256+ lengths.

    Also, it is a pity that driving the CS# line is not something the SPI or DMA can do.

    In another application where I am driving a 16-bit DAC, I have to toggle the CS# line active every other byte. I am doing this through the CPU. Both the PPI and DMA (on nRF52) do not seem to help me here.

    (I have tried the PPI, but as it every other byte, enabling/disabling PPI takes as much CPU synchronization as does toggling CS#).

Reply
  • 0

    I just ran into the same issue, but on an nRF51 without the EasyDMA limitation. I ported code from against an older SDK to SDK 10, and am transferring a 520 bytes stream from a SPI slave.

    I have changed the nrf_drv_spi uint8_t to uint16_t in a few spots as when using programmed I/O (i.e. byte-by-byte, driven by the CPU) there is no limitation in the SPI message lengths.

    I agree that silicon should have provided 256+ lengths.

    Also, it is a pity that driving the CS# line is not something the SPI or DMA can do.

    In another application where I am driving a 16-bit DAC, I have to toggle the CS# line active every other byte. I am doing this through the CPU. Both the PPI and DMA (on nRF52) do not seem to help me here.

    (I have tried the PPI, but as it every other byte, enabling/disabling PPI takes as much CPU synchronization as does toggling CS#).

Children
Related