• State Not Answered
  • Replies 9 replies
  • Subscribers 25 subscribers
  • Views 236 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 289295
Options
nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs

Minimum Time Delay between TASKS_START and TASKS_STOP/SUSPEND for PPI ?

user115850

Hello,

I am reading the FIFO buffer of a sensor via SPIM3 with nRF52840. What I want to do is that by the use of PPI, the start of the transmission (PPI channel 0, to TASKS_START / RESUME) is triggered by an event and also TASKS_SUSPEND (PPI Channel 1) for SPI is triggered by an event. The start works. The hardware CS flag goes low automatically using the hardware Select of SPIM3 and we read some bytes.

After about 10us, the other event occurs and should therefore suspend the SPI transmission shortly. But this does not happen, the transmission is continued until the buffer is empty which is not what I want. I checked that the PPI is implemented corrently - other tasks, except from TASKS_SUSPEND or TASKS_STOP, are succesfully performed.

So my question is:

Is there a minimum time delay between the SPI Start and Stop Task for the Stop Task to be performed successfully? Any reasons why the suspend or stop does not react on the event happening?

The plan is that after suspending the SPI transmission, again only a few microseconds later, the first event will be triggered again, which should cause the SPI to resume (I forked TASKS_RESUME to TASKS_START for PPI channel 0). Is there any other reason why this should not work? Any problem with the hardware CS here?

Help would be really appreciated.

Parents
  • 0

    Hi Henrike

    I am not aware of any such minimum delay, but a suspend or stop task will not be effective until the current byte is transmitted successfully. Is there any chance you are triggering multiple start/stop/resume/suspend tasks within the same byte?

    What is the frequency you use on the SPI bus, and how fast are you activating these tasks?

    How do you verify that the suspend is not working?

    Best regards
    Torbjørn

  • 0 in reply to user2116

    Hi,

    thank you for your example! I see that you took two different PPI channels for TASK_START and TASK_RESUME, triggered by different events.

    For me, I have only one event that should in the first run start the SPI transmission and then, after a suspend, should resume it. It's the same event. That's why I forked the PPI channel 0 to do both, START and RESUME.

    Is this maybe a problem?  That maybe the SUSPEND is directly cut off by the RESUME which was not triggered in the first run (because START was triggered instead)?

Reply
  • 0 in reply to user2116

    Hi,

    thank you for your example! I see that you took two different PPI channels for TASK_START and TASK_RESUME, triggered by different events.

    For me, I have only one event that should in the first run start the SPI transmission and then, after a suspend, should resume it. It's the same event. That's why I forked the PPI channel 0 to do both, START and RESUME.

    Is this maybe a problem?  That maybe the SUSPEND is directly cut off by the RESUME which was not triggered in the first run (because START was triggered instead)?

Children
Related
Terms of service