nRF52840 Dongle + s140 softdevice + SPI

[fe-hadella]

I am working on a device driver for the W25Q128JV flash device. This is the first SPI device I've used with the nRF52840. I had some observations and questions about SPI programming on this mcu.

int w25q128_flash__read_device_id(w25q128_flash f, uint8_t *device_id)

{

    uint8_t buf[5] = {0};

    buf[0] = 0xAB;

    ret_code_t ret = nrf_drv_spi_transfer(f->spi, buf, 4, buf, 5);

    *device_id = buf[4];

    return ret;

}

This is functionally the same as this:

int w25q128_flash__read_device_id(w25q128_flash f, uint8_t *device_id)

{

    uint8_t wr_buf[4] = {0};

    uint8_t rd_buf[5] = {0};

    wr_buf[0] = 0xAB;

    ret_code_t ret = nrf_drv_spi_transfer(f->spi, wr_buf, 4, rd_buf, 5);

    *device_id = rd_buf[4];

    return ret;

}

The second example is more like the spi example provided in the sdk. In the command, the 0xAB is an instruction, but is then followed by 3 dummy bytes. The next byte is then the id, which reads as 0x17. 

 

It seems like moving forward, I could use the single buffer and then offset the data like in the first example. This seems cleaner than the second example. What is typical on the nrf52840? Is the data read offset the way it should work, or is there a possible setup issue somewhere? I've implemented several functions using this offset approach, and it works fine, but wanted some opinions of other folks who have used SPI on the nrf52 series...

[fe-hadella]

I made some logical updates which make the code make more sense to me. This handles the offset issue I described previously.

int w25q128_flash__read_jedec_id(w25q128_flash f, uint32_t *jedec_id)

{

    if (NULL == f) return FLASH_NO_EXIST;

    uint8_t wr_buf[1] = {FLASH_REG_RD_JEDEC_ID};

    uint8_t rd_buf[3] = {0};

    ret_code_t ret = local_spi_xfer(f, wr_buf, 1, rd_buf, 3);

    *jedec_id = rd_buf[0] << 16 | rd_buf[1] << 8 | rd_buf[2];

    return ret;

}

int w25q128_flash__read_device_id(w25q128_flash f, uint8_t *device_id)

{

    if (NULL == f) return FLASH_NO_EXIST;

    uint8_t wr_buf[4] = {FLASH_REG_RD_DEVICE_ID, 0x00, 0x00, 0x00};

    return local_spi_xfer(f, wr_buf, 4, device_id, 1);

}

static int local_spi_xfer(w25q128_flash f, uint8_t const *wr_buf, uint8_t wr_len, uint8_t *rd_buf, uint8_t rd_len)

{

    uint8_t *rbuf = malloc(wr_len + rd_len);

    if (NULL == rbuf)

        return FLASH_MALLOC_ERR;

    uint8_t rlen = wr_len + rd_len;

    ret_code_t ret = FLASH_SUCCESS;

    nrf_gpio_pin_clear(f->cs_pin);

    ret = nrf_drv_spi_transfer(f->spi, wr_buf, wr_len, rbuf, rlen);

    nrf_gpio_pin_set(f->cs_pin);

    if (NULL != rd_buf)

        memcpy(rd_buf, rbuf + wr_len, rd_len);

    free(rbuf);

    return ret;

}

This brings up a question. There is a size limitation imposed by the call to nrf_drv_spi_transfer().

__STATIC_INLINE

ret_code_t nrf_drv_spi_transfer(nrf_drv_spi_t const * const p_instance,

                                uint8_t const * p_tx_buffer,

                                uint8_t         tx_buffer_length,

                                uint8_t       * p_rx_buffer,

                                uint8_t         rx_buffer_length);

The actual struct internally uses a size_t which is certainly larger than 255 max length. The flash itself has the ability to write up to 256 bytes at once, before a cyclic page overwrite occurs. This sort of implies I need to write a full page in two chunks.

If I were to call nrfx_spi_xfer() instead, I would be able to setup the nrfx_spi_xfer_desc_t data structure directly. I guess my question is the 256 bytes thing a hardware limitation or not? I only used the nrf_drv_spi_transfer() call since that's what the spi demo was using.

[JONATHAN LL]

Hi,

Not certain the first approach you suggest is the best, since it re-write the write buffer in RAM with what's showing up on the MISO at the same time as it sends out data on MOSI. In theory the peripheral is probably done reading the relevant byte from RAM before the transfere starts. 

255 byte limit is correct for the nRF52832 SPIM, witch is a 8-bit MAXCNT register.

If you wish to send longer packages i would recommend to migrate to nrfx_spim as a alternative to nrf_drv_spi diver. 

Regards,
Jonathan

[fe-hadella]

I switched to use the nrfx_spim driver. I was able to remove the legacy spi driver as far as I can tell.

I updated the xfer function to look like:

static int local_spi_xfer(w25q128_flash f, uint8_t const *wr_buf, uint8_t wr_len, uint8_t *rd_buf, uint16_t rd_len)

{

    uint8_t *rbuf = malloc(wr_len + rd_len);

    if (NULL == rbuf)

        return FLASH_MALLOC_ERR;

    nrfx_spim_xfer_desc_t const xfer_desc =

    {

        .p_tx_buffer = wr_buf,

        .tx_length   = wr_len,

        .p_rx_buffer = rbuf,

        .rx_length   = wr_len + rd_len,

    };

    ret_code_t ret = FLASH_SUCCESS;

    nrf_gpio_pin_clear(f->cs_pin);

    ret = nrfx_spim_xfer(f->spi, &xfer_desc, 0);

    nrf_gpio_pin_set(f->cs_pin);

    if (NULL != rd_buf)

        memcpy(rd_buf, rbuf + wr_len, rd_len);

    free(rbuf);

    return ret;

}

There still seems to be an issue for certain write length. I can write up to 251 bytes -- with the instruction code and address bytes, that brings the total write to 255, which seems to be the max. If I write 252 bytes, then the function call has no effect at all if I then read back what is written.

Is there some setting in the sdk_config.h that controls this? In the setup, I've set the handler to NULL, so this is a blocking call.

[JONATHAN LL]

Here is a overview of the MAXCNT registers for peripherals on each 52 chip: https://infocenter.nordicsemi.com/topic/struct_nrf52/struct/nrf52.html?cp=4 

Using nrfx_spi supports longer transfers but since it is legacy SPI  peripheral the CPU need to be updated the byte that is sendt\received for each byte. 

nrfx_spim will allow you to use 16bit lengths, (65535 bytes) per transfer. 

Regards,
Jonathan

[fe-hadella]

I am confused at this point. I've read through the various headers and the data sheet for the nRF52840 and they all say the TXD.MAXCNT is a 16-bit value.

I've been able to read > 256 bytes in one call no problem. The trouble is the tx can send only 251 at once so far. I've read through many cases on the devzone, and haven't really seen anyone else clear this up completely.

I'm using the latest SDK 17.2. Not sure where in the code this weird restriction takes place.

I am missing a step here? I have attempted to set the TXD.MAXCNT variable. This is fine, but the call to static spim_xfer will override this anyway to whatever value setup via the nrfx_spim_xfer_desc_t data structure. Is there some other register that needs to be set globally?