• State Not Answered
  • Replies 9 replies
  • Subscribers 25 subscribers
  • Views 232 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)?

  • 0 in reply to user115850

    When I do not do the Fork, then the suspend is triggered: the CS pin stays low but the clock stops toggling.

    So I actually seem to have a problem with the resume now rather than with the suspend.

  • 0 in reply to user115850

    Hi Henrike

    I didn't realize that you trigger several SPI tasks at the same time. This is not tested, and could have unpredictable consequences. 

    You should try to trigger START, SUSPEND and RESUME separately, like I do in my example. 

    It is possible to set up separate events on the falling and rising edge of the interrupt pin, in case this makes it easier?
    You just need to configure two GPIOTE IN channels on the same pin. 

    Best regards
    Torbjørn

  • 0 in reply to user2116

    Okay, I'm afraid that's not possible. But I will think of options. Maybe I can trigger the SPI START manually, and only have the RESUME as an event of the rising edge of a pin (and SUSPEND for another pin).

    What happens, though, when the RESUME event is triggered while no START has been done, i.e. no SPI transmission is ongoing ? Is it simply discarded (desired for me here)? Or will it be taken into account as soon a transmission has started or suspended later? Is this tested?

    Thank you! Best regards!

  • 0 in reply to user115850

    Hi Henrike

    I am pretty sure the RESUME task will simply be ignored if you haven't started a transaction yet, but I have asked the hardware team for a confirmation regarding this. As soon as I hear back from them I will let you know. 

    Best regards
    Torbjørn

  • 0 in reply to user2116

    Hi Henrike

    The hardware guys confirmed my suspicion. Below is the full reply:

    "Yes, triggering TASKS_RESUME before TASKS_START won't have any effect. TASKS_RESUME will only have an effect after a TASKS_SUSPEND when a transaction is currently ongoing."

    Best regards
    Torbjørn

Reply Children
No Data
Related
Terms of service