send more than 255 bytes by spi, nrf52

[makouda]

I'm communicating with N25 flash memory, the page size is 256 bytes. there is a page_program command which can write up to 256 bytes. there is no way to write in the middle of page (page @ + offset).

the issue it that SPI function has size parameter as uint8_t, so by adding the instruction code and the address to the frame (4 bytes in total), I always loose 4 bytes for each page.

is there anyway to send more then 255 bytes with nrf_drv_spi_transfer

[mfdevzone]

In my opinion this is an error in the Nordic spi driver implementation, as maximum SPI write length should be set more explicitly, rather than simply because they use uint8_t for the rx_ and tx_ buffer length values.

I modified this (and tested it, though not a huge amount) by changing nrf_drv_spi.c and .h to use uint16_t for rx and tx buffers, as well as bytes_transferred in the spi_control_block_t struct.

I generally dislike modifying the stack but they provide source and this is an annoying constraint.

[RK]

it's uint8_t because the DMA is limited to 255 and the SDK is designed to be compatible with the chips which do and don't have it. And this isn't the stack, this is the SDK, and you can do whatever you like with it. I treat it as reference code.

[mfdevzone]

If the type was set to uint16_t instead of uint8_t it would still be compatible with 255-byte limits for DMA (just don't use more than 255). Pushing such a hardware specialization/restriction in to software used more broadly than DMA is a software mistake.

Re Modifying the SDK: Even if you have source, once modified, you now have to maintain it across SDK upgrades. Avoiding changes is a good idea.

Re: Stack/SDK. 'Stack' is often used as a broad term to refer to "the software stack" entire.

[Kolonka]

did you changed the xxx_buffer_length's to uint16_t or the p_xxx_buffer?

[Einar Thorsrud]

Hi,

The answer from RK describes this perfectly:

RK said:

it's uint8_t because the DMA is limited to 255 and the SDK is designed to be compatible with the chips which do and don't have it.

The point is that the DMA of the nRF52832 is limited to 8 bits length field. So it does not matter what you do in SW, you still cannot buypass this HW limitation.

Note that the nRF52832 was the only device in the 52 series when this thread was created. Now there are other nRF52 devices which support longer DMA transfers (for instance MAXCNT for the nRF52840 is 16 bit, even though it is only 8 for the nRF52832).

[Sumen]

Been a pity on 64MHz.
But BLE + ARM good work. Thanks, Nordicsemi.