This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

No SPIM Stopped Event

In the SPIM section of the product spec for the nRF52832, the spec describes sending the STOP task (even if the peripheral is already stopped) and receiving the STOPPED event (section 31.4 Low Power). However, in my experience, the STOPPED event does not always occur. The START task must be sent first (even for a zero length transfer) and then the STOP task will trigger the STOPPED event once.

Has anyone else seen this operation? I think the work around is to start a zero-length transfer and then send a stop, but maybe that's not even necessary. I'm just trying to make sure the SPIM peripheral is stopped.

Austin

Parents
  • Hi Austin

    I agree that the PS indicates that stopped event should always be triggered when SPI is enabled, even though the start task has not been called. If it is the case that STOPPED event is not fired when SPI is not started, then I suspect you could update a status register is_started so you will know when the SPI is actually started or stopped. Another option would be to have timeout for the stopped event to arrive, perhaps a few milliseconds timeout. If the timeout expires, and the STOPPED event has not arrived after calling the STOP task, then you can assume the SPI has stopped.

Reply
  • Hi Austin

    I agree that the PS indicates that stopped event should always be triggered when SPI is enabled, even though the start task has not been called. If it is the case that STOPPED event is not fired when SPI is not started, then I suspect you could update a status register is_started so you will know when the SPI is actually started or stopped. Another option would be to have timeout for the stopped event to arrive, perhaps a few milliseconds timeout. If the timeout expires, and the STOPPED event has not arrived after calling the STOP task, then you can assume the SPI has stopped.

Children
Related