nrfx_spim_xfer() asserting with NRFX_SPIM_FLAG_HOLD_XFER and ss_pin

[Nicolas Brunner]

Using NCS 1.3.1.

Why is nrfx_spim_xfer() asserting when using NRFX_SPIM_FLAG_HOLD_XFER flag and a ss_pin ?

When not using a ss_pin in the spi config but configuring with instance.p_reg->PSEL.CSN, the ss_pin is working correctly.

[Einar Thorsrud]

Hi,

That is the reason for this check. The API documentation states that this is how it is, though not explaining the reason:

 * - @ref NRFX_SPIM_FLAG_HOLD_XFER - Driver is not starting the transfer. Use this
 *   flag if the transfer is triggered externally by PPI. Use
 *   @ref nrfx_spim_start_task_get to get the address of the start task.
 *   Chip select must be configured to @ref NRFX_SPIM_PIN_NOT_USED and managed outside the driver.

The reason is that when using NRFX_SPIM_FLAG_HOLD_XFER the driver does not start the transfer, and therefore it cannot control the SS pin either.

[Nicolas Brunner]

The hardware allow the control of the SS pin, if the driver use the hardware for controlling the SS pin it would also be able to use the SS pin when using NRFX_SPIM_FLAG_HOLD_XFER.

It's a shame that we can't use the full capability of the hardware when using the driver.

[Einar Thorsrud]

Hi,

You are right. I discusses this with the driver developers and they agree that this is too strict. The CSN pin should be handled correctly also when the start task is triggered from outside the driver. The assert will probably be changed in the next nrfx release.

[Nicolas Brunner]

Thank you