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

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

ovrebekk — Mon, 13 Jun 2022 10:32:35 GMT

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

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

ovrebekk — Fri, 27 May 2022 10:29:10 GMT

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

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

lora — Tue, 24 May 2022 07:56:51 GMT

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!

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

ovrebekk — Tue, 24 May 2022 07:30:37 GMT

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

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

lora — Mon, 23 May 2022 12:57:38 GMT

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.

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

lora — Mon, 23 May 2022 12:51:52 GMT

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)?

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

ovrebekk — Mon, 23 May 2022 11:47:13 GMT

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:
devzone.nordicsemi.com/.../289295_5F00_blinky_5F00_spim3_5F00_test.zip

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

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

lora — Sat, 21 May 2022 12:12:10 GMT

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?

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

ovrebekk — Fri, 20 May 2022 06:45:36 GMT

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