• State Not Answered
  • Replies 9 replies
  • Subscribers 25 subscribers
  • Views 234 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 Torbjørn, thanks for the response.

    The second event which should trigger the suspend or stop only occurs as soon when the FIFO undergoes a certain watermark. Thus, when the event appears I can be quite sure that I am not trigggering start/resume and suspend/stop within the same byte but that at least one byte must have been read from the FIFO.

    I also attached two pictures which show the same situation (I only have a 4 Channel logic analyzer thats why it is 2 pictures). On the first picture one can see both INT1 and INT2 which are to trigger the tasks both on a rising edge - INT1 should start the SPI, which it obvously does, since the Clock starts and the CS pin goes down, and the INT2 rising edge should suspend it. On the second picture one can see the MISO pin and thus the reading of the bytes, and also that INT2 has the rising edge after one byte has been read.

    This is how I verify that the suspend is not working - despite the rising edge of INT2 the clock keeps toggling and we still read bytes.

    The frequency on the bus is 8Mbps, but also with 4Mbps it is not working.

    Do you have any ideas here?

Reply
  • 0 in reply to user2116

    Hi Torbjørn, thanks for the response.

    The second event which should trigger the suspend or stop only occurs as soon when the FIFO undergoes a certain watermark. Thus, when the event appears I can be quite sure that I am not trigggering start/resume and suspend/stop within the same byte but that at least one byte must have been read from the FIFO.

    I also attached two pictures which show the same situation (I only have a 4 Channel logic analyzer thats why it is 2 pictures). On the first picture one can see both INT1 and INT2 which are to trigger the tasks both on a rising edge - INT1 should start the SPI, which it obvously does, since the Clock starts and the CS pin goes down, and the INT2 rising edge should suspend it. On the second picture one can see the MISO pin and thus the reading of the bytes, and also that INT2 has the rising edge after one byte has been read.

    This is how I verify that the suspend is not working - despite the rising edge of INT2 the clock keeps toggling and we still read bytes.

    The frequency on the bus is 8Mbps, but also with 4Mbps it is not working.

    Do you have any ideas here?

Children
  • 0 in reply to user115850

    Hi Henrike

    I did my own little test to verify that the suspend functionality of the SPIM3 module works as expected, and I had no problems suspending the SPI after the first byte was transmitted, and resuming it again some time later:

    As you can see from the code I suspend the SPI 2 microseconds after it starts, and then I resume it 20 microseconds after. I verified the result on the scope:

    Are you sure that the pin events are actually received properly in your firmware, so that the SPIM tasks get activated properly?

    Best regards
    Torbjørn

Related
Terms of service