Add initialization sequence to SPIM interface

[kfxkaplan]

I am developing for NRF52840 on a custom board (SDK 15.0, Segger), and working on integration with a HTRC110 RFID HITAG reader chip. This chip supports 3-wire SPI, for which I'm using the NRFX_SPIM driver. I am able to get the driver to transmit bytes as expected, as shown below.

However, the chip specifies that SCLK and DIN (MOSI) must go high before beginning to send a byte on DIN.

Once I've initialized the SPIM driver via nrfx_spim_init, I am unable to manually drive the SCLK and MOSI pins to perform that initialization. I have tried calling nrfx_spim_uninit, driving the pins high, then re-initializing the SPIM driver, but this results in a delay of 15us between the falling edge and the beginning of the driver's transmit operation.

Is there any other way of configuring the driver to perform this initialization? Should I be using a different driver rather than NRFX_SPIM?

Thanks

[haakonsh]

Try this:

Set up a transfer with the NRFX_SPIM_FLAG_HOLD_XFER flag --> disable(not uninitialize) the SPIM peripheral --> set start conditions manually (CPU toggling of CLK and MOSI pins) --> enable SPIM periheral --> start SPIM transfer. 

See the following API docs:

• nrfx_spim_xfer
• nrf_spim_disable
• nrf_spim_enable
• nrf_spim_task_trigger(NRF_SPIM_TASK_START)

[kfxkaplan]

Thanks for the feedback haakonsh! I implemented the steps as follows

    nrfx_spim_xfer_desc_t xfer_desc = NRFX_SPIM_XFER_TX(&cmd_byte, sizeof(cmd_byte));    
    nrfx_spim_xfer(spi_inst, p_xfer_desc, NRFX_SPIM_FLAG_HOLD_XFER);
    task = nrfx_spim_start_task_get(spi_inst);
    nrf_spim_disable(spi_inst->p_reg);
    nrf_gpio_pin_set(RFID_SPI_SCK_PIN);
    nrf_delay_us(1);
    nrf_gpio_pin_set(RFID_SPI_MOSI_PIN);
    nrf_spim_enable(spi_inst->p_reg);
    nrf_spim_task_trigger(spi_inst->p_reg, task);

I tried this with and without the nrf_delay_us call. Initially, the waveform would look fine, like below.

However, by the second or third spim operation the waveform would look like the following, with both MOSI and SCLK going high nearly simultaneously.

This occurred both with and without the nrf_delay_us call between clearing the 2 pins.

Should I be disabling the spim driver again after the transfer and clearing both pins manually, or is something off with my implementation?

[haakonsh]

SCK and MOSI will return to their last configured state when the SPIM peripheral is disabled, that might be what's happening. 

Try calling nrf_gpio_pin_clr(RFID_SPI_SCK_PIN) and nrf_gpio_pin_clr(RFID_SPI_MOSI_PIN), after you've enabled the SPIM. The pins should not immidiately change state as the GPIO peripheral is overridden by the SPIM peripheral, for as long as the SPIM peripheral is enabled. 

[kfxkaplan]

This did the trick, thank you so much for your help!

[haakonsh]

kfxkaplan said:

This did the trick, thank you so much for your help!

I'm glad to hear it worked out, let me know if you do find any issues. 

One scenario you might want to be aware of is if an ISR executes between sending the start-condition and triggering the SPIM start task, then you will likely experience similar issues as before. You should therefore make your application tolerant to this SPI fault.