SPIS trickery - is this behaviour correct and well defined?

[Charlie]

In an nRF51-based application I'm working on, I am using the SPIS peripheral and a generated clock signal to send a large buffer out over serial using DMA. I want to use the same SPIS process to clear another large buffer in RAM to 0 at the same time, to save CPU overhead. Simply setting the MOSI pin to NRF_DRV_SPIS_PIN_NOT_USED, and pointing RXDPTR at the clear-target seems to work fine, but this behaviour doesn't seem to specifically get defined in the user manual. Is this behaviour (the value read by SPIS when PSELMOSI is in the disconnected state) reliable and unlikely to change between chip revisions? All the manual says is

If a value of 0xFFFFFFFF is specified in any of these registers, the associated SPI slave signal will not be connected to any physical pins

I've also noticed that if MAXRX is set to 0, the receive buffer will have data written to it regardless (up to the total number of bytes that the master requests?). This seems to contradict the manual's description of the MAXRX register:

The MAXRX register specifies the maximum number of bytes the SPI slave can receive in one granted transaction. If the SPI slave receives more than MAXRX number of bytes, an OVERFLOW will be indicated in the STATUS register and the incoming bytes will be discarded.

I haven't checked the contents of the OVERFLOW register when this happens yet, but the "incoming bytes will be discarded" part of this description appears to be being violated regardless. It behaves as expected when MAXRX is set to 1 (one byte is written). Is the behaviour when MAXRX=0 a special case/anomaly?

[Kenneth]

Hi, I think what you are describing are essentially two corner cases.

In general it's highly unlikely that we will change behavior of this kind between chip revisions, and if we were that would trigger a PCN in due time with sampling and notice for customer to implement changes.

I don't think it's realistic I can get time from our design team to simulate these corners cases, as the usage is slightly on the side of normal operation. But to comment on your two observations:

Simply setting the MOSI pin to NRF_DRV_SPIS_PIN_NOT_USED, and pointing RXDPTR at the clear-target seems to work fine, but this behaviour doesn't seem to specifically get defined in the user manual.

If you have an unused GPIO in your design, I would suggest to ground it, and use it for the purpose of clearing RAM instead of NRF_DRV_SPIS_PIN_NOT_USED.

Is the behaviour when MAXRX=0 a special case/anomaly?

Most likely, considering it's an SPI slave I would think MAXRX is intended to be >0.

[Charlie]

Thanks for your answer - good to know that this behaviour is unlikely to change. I think there's a spare GPIO that I can use as a logic 0 signal - I'll make sure that this is put on to the next revision of the board, just to be safe.

I can work around the MAXRX behaviour by using a dummy byte as the target and setting MAXRX to 1 when I don't want anything to be cleared. A bit inelegant, but not a problem.