• State
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 18 views
  • Users 0 members are here
Support feedback
Options
Options
Related

Original question:

MSPM0G1505: Minimum reset of SPI peripheral

MSPM0G1505: Detect SPI CS deassertion

Alan
Prodigy 245 points

Part Number: MSPM0G1505

In a previous ticket (linked?) it was discussed that the SPI IDLE interrupt doesn't fire when the SPI peripheral is being used in slave/peripheral mode and the TX FIFO still contains data - which means that it's hard to detect when the controller has deasserted the CS line to finish the transaction.  I'd like to use a timeout, based on either the RXTIMEOUT facility of the SPI peripheral or a separate timer.  However, to be sure that the transaction is over I'd like to be able to check the state of the CS line manually.  Is it possible to read its state while it is still configured to be part of the SPI peripheral?  I don't want to have to switch it to be connected to the GPIO if possible, as that makes managing the SPI peripheral more tricky.

  • 0
    Expert 1460 points

    RXTIMEOUT only indicates that no receive activity occurred for a configured period; it does not reliably prove that CS has been deasserted.

    The cleanest solution is to configure the SPI peripheral in three-wire mode and assign CS permanently as a GPIO input. Then use GPIO interrupts on both CS edges:

    • Falling edge: start a new transaction and reset counters.
    • Rising edge: finalize the transaction, discard unused TX FIFO data and start any timeout handling.

    For general background, this SPI communication overview describes CS as the signal that selects and frames communication with a peripheral. In this application, monitoring its rising edge through a GPIO is therefore more reliable than inferring the end of a transaction from missing SPI activity.

    This does not require dynamically switching the pin between SPI and GPIO—the CS pin remains GPIO throughout operation.

    If hardware-controlled CS behaviour is required by the SPI peripheral, route the controller’s CS signal to both the SPI-CS pin and another GPIO input. The second pin can then provide a reliable rising-edge interrupt. Reading or interrupting the GPIO path while the same pin is muxed exclusively to SPI is not generally supported through DriverLib.

    TI has suggested the same three-wire plus GPIO-monitoring approach for manually observing chip select on MSPM0: related TI discussion.

  • 0 in reply to Zain Nasir
    Prodigy 245 points

    Zain

    Thanks for the reply.  Indeed, the RXTIMEOUT is not quite sufficient, hence wanting to add an explicit check for the state of the CS line in the RXTIMEOUT ISR - then if the CS line is still asserted after the timeout I can choose to wait longer.

    Your suggestion (and the one in the linked comment that I was part of) is to use a GPIO as the CS line and manually handle the start and end of the transaction.  As stated in that conversation I would ideally like to avoid this as it adds extra time between the controller asserting CS and then being able to start clocking data, as the POCI line must be configured by the ISR.  Similarly, using another GPIO line in parallel with the CS line might use more pins than I really have available.  Hence, trying to understand the limits of what seems like perfectly reasonable behaviour - how the deassertion of CS in peripheral mode is expected to be used.

    You mentioned that "Reading or interrupting the GPIO path while the same pin is muxed exclusively to SPI is not generally supported through DriverLib". Does this mean that the hardware makes it possible, but you haven't exposed it in software? Or is it undefined behaviour in hardware?  I'm happy to use direct register access to exercise the functionality and bypass DriverLib, if I had confidence that it would work.