Dear TI Support Team,
the request is made based upon SPICC26XXDMA.c implementations present in tidrivers_cc13xx_cc26xx_2_16_00_08 and tirtos_simplelink_2_13_00_06.
Currently there is no way to switch back from hardware controlled chip select to software based operation for SPI master mode unless the read only SPICC26XX_HWAttrs structure is initialized into software mode and SPI_close() and than SPI_open() are called again whenever software mode needs to be used again after hardware controlled chip select had been selected.
According to the CC26xx technical reference manual (revision: swcu117d) chapter 20.4.4 "Frame Formats", the SSI peripheral of CC26XX is not capable to perform multiple frame transfers in Motorola SPI mode 0 (SPO = 0 and SPH = 0) and mode 2 (SPO = 1 and SPH = 0) using hardware based chip select control without deasserting the chip select pin after each transferred frame. A frame could be 8 to 16 bits long.
The reference manual describes the limitation as follows: For continuous back-to-back transmissions, the SSIn_FSS signal must pulse high between each data word transfer as the slave-select pin freezes the data in its serial peripheral register and keeps it from being altered if the SPH bit is clear. The master device must raise the SSIn_FSS pin of the slave device between each data transfer to enable the serial peripheral data write. When the continuous transfer completes, the SSIn_FSS pin returns to its IDLE state one SSIn_CLK period after the last bit is captured.
Most SPI slaves consider deassertion of the chip select line as abort request for the ongoing read operation. Thus there are valid use cases where a given SPI slave supporting only Motorola SPI mode 0 would require software based chip select handling for continuous multi-frame transfers and as software based chip select handling is several times slower in asserting and deasserting the chip select line wasting a lot of power by keeping the sensors' bus interface active for longer than needed it is crucial to use hardware chip select whenever possible and only revert to software based operation where it is absolutely necessary.
The limitation is inside the SPICC26XXDMA_control() API within the SPICC26XXDMA_CMD_SET_CSN_PIN command handler code which does not accept PIN_UNASSIGNED as a new chip select pin which would eventually switch back to software mode at the end.
/* Attempt to add the new pin */
if (PIN_add(object->pinHandle, pinConfig) == PIN_SUCCESS) {
/* Configure pin mux */
PINCC26XX_setMux(object->pinHandle, *(PIN_Id *)arg, (hwAttrs->baseAddr == SSI0_BASE ? IOC_PORT_MCU_SSI0_FSS : IOC_PORT_MCU_SSI1_FSS));
/* Remove old pin and revert to default setting specified in the board file */
PIN_remove(object->pinHandle, object->csnPin);
/* Keep track of current CSN pin */
object->csnPin = *(PIN_Id *)arg;
/* Set return value to indicate success */
ret = SPI_STATUS_SUCCESS;
}
PIN_add() only accepts valid PIN_Ids and all the chip select PIN update procedure is conditionally bound to successful execution of PIN_add().
To enable disabling hardware chip select without the need to close and reopen the SSI peripheral SPICC26XXDMA_control() needs to accept PIN_UNASSIGNED as arg parameter value and shall revert back the previous hardware chip select pin definition to safe default state with the peripheral mux reverted to GPIO mode.
Please consider the above described change request and if possible provide information on whether it had been accepted by the Designer Team and if so whether the change would make it into the next CC26xx BLE-SDK release.
Thank you in advance for your kind support.
Best regards,
Tamas
_
