SPIM STOP task isn't getting triggered by PPI

RE: SPIM STOP task isn't getting triggered by PPI

kv1980 — Mon, 16 Nov 2020 23:27:12 GMT

Ahhhhh, I saw that 4 CC register thing, but somehow it didn't sink in at the time. I already switched to COMPARE0, but it was still bothering me Thanks for that!

As for the shorts, I think I posted an "answer" about the same time you posted this, but yes, that was the issue. I didn't realize that the SHORTS can't be turned off in hardware, so I came up with a solution just using PPI and channel groups (since those have enable/disable tasks that can be triggered).

Thanks for all of your help!

RE: SPIM STOP task isn't getting triggered by PPI

kv1980 — Mon, 16 Nov 2020 20:31:57 GMT

Just had a moment of inspiration to solve the SPIM SHORTS problem. Instead of using SHORTS, I just made a new PPI channel from SPIM END Event to SPIM START Task, then added is to PPI CHG[0]. Then I added a FORK to PPI[2] to trigger a PPI CHG[0].DIS Task, thus disconnecting the short from SPIM END to SPIM START.

Still curious about COMPARE5 though. If I don't hear back by tomorrow on that I will close this out since I answered my own question and open a new ticket for COMPARE5.

EDIT: Per Daniel Chisholm, the datasheet indicates that there is no COMPARE5 for TIMER0-2, so that answers that.

RE: SPIM STOP task isn't getting triggered by PPI

Daniel Chisholm — Mon, 16 Nov 2020 20:08:23 GMT

Just had a look at the nrf52840 Product Specification and section 6.5.30 "Registers" indicates that TIMER0-TIMER2 have 4 CC registers, and TIMER3-TIMER4 have 6 CC registers. So COMPARE5 doesn't exist for TIMER1. Why not try COMPARE3 and see if that works, or try COPMARE5 with TIMER3 or TIMER4? (BTW ii seems remarkable to me that CH[2].EEP reads back "0" when you wrote 0x40009154 to it (where TIMER1.EVENTS_COMPARE[5] would be, if it were to exist)..... I can't begin to think how that might be implemented in the silicon?)

BTW2, I noticed in your debugger output that SPIM3.SHORTS = 0x0020000, which means "Shortcut between event END and task START".... so maybe in fact your COMPARE0 really is stopping SPIM3, but as soon as it ends then this shortcut immediately restarts it? (EVENTS_STARTED also shows "1")

RE: SPIM STOP task isn't getting triggered by PPI

kv1980 — Mon, 16 Nov 2020 19:48:45 GMT

So I think I finally grok the problem here. Kicking off the STOP take for SPIM does nothing if SHORTS are still set. Somehow you have to disable SHORTS, which I'm guessing requires software intervention? I disconnect it first thing in my TIMER1 COMPARE0 handler, but I still get a two byte overrun since SPIM is still running in the background. I can just discard this data for my purposes here, but is there a better way? It feels like there should be a DISCONNECT SHORTS task in SPIM, or some other equivalent but I'm not finding it.

Still would like to know why COMPARE5 doesn't work though...

RE: SPIM STOP task isn't getting triggered by PPI

kv1980 — Mon, 16 Nov 2020 14:56:41 GMT

OK, so after a little testing, I am very confused. Per Daniel Chisholm, I fixed my COMPARE0 bug, but now I notice that cannot set PPI to the COMPARE5 event. Is there some reason that this event cannot be used?

Here is what happens if I use COMPARE0:

    /* PPI Configuration - NOTE that we DO NOT enable PPI here, but in the SPIM FIFO read
     * Configure PPI channel 0 to increment TIMER1 counter on SPIM END event.
     */
    NRF_PPI->CH[0].EEP  = (uint32_t)((uint32_t)NRF_SPIM3_BASE   + (uint32_t)NRF_SPIM_EVENT_END);  // EVENTS_END
    NRF_PPI->CH[0].TEP  = (uint32_t)((uint32_t)NRF_TIMER1_BASE  + (uint32_t)NRF_TIMER_TASK_COUNT);  // TASKS_COUNT

    /* Configure PPI channel 2 to initiate a SPIM STOP task on TIMER1 COMPARE event.
     */
    NRF_PPI->CH[2].EEP  = (uint32_t)0x40009140UL; // Address for COMPARE0
    NRF_PPI->CH[2].TEP  = (uint32_t)((uint32_t)NRF_SPIM3_BASE   + (uint32_t)NRF_SPIM_TASK_STOP);  // TASKS_STOP

But with COMPARE5:

    /* PPI Configuration - NOTE that we DO NOT enable PPI here, but in the SPIM FIFO read
     * Configure PPI channel 0 to increment TIMER1 counter on SPIM END event.
     */
    NRF_PPI->CH[0].EEP  = (uint32_t)((uint32_t)NRF_SPIM3_BASE   + (uint32_t)NRF_SPIM_EVENT_END);  // EVENTS_END
    NRF_PPI->CH[0].TEP  = (uint32_t)((uint32_t)NRF_TIMER1_BASE  + (uint32_t)NRF_TIMER_TASK_COUNT);  // TASKS_COUNT

    /* Configure PPI channel 2 to initiate a SPIM STOP task on TIMER1 COMPARE event.
     */
    NRF_PPI->CH[2].EEP  = (uint32_t)0x40009154UL; // Address for COMPARE5
    NRF_PPI->CH[2].TEP  = (uint32_t)((uint32_t)NRF_SPIM3_BASE   + (uint32_t)NRF_SPIM_TASK_STOP);  // TASKS_STOP

I also notice that the app does a full rebuild when I make this change, indicating that something bigger has changed with the app as a whole. So... what's the deal COMPARE5?

EDIT: I should also add that even after changing back to COMPARE0, SPIM3 is still not stopping even though the STOP event has occurred:

I break in the TIMER1 compare handler (so COMPARE0 has happened, and therefore PPI CH[2] should have stopped SPIM3):

and here are the SPIM3 registers:

Even if I uncomment the TASKS_STOP trigger at the top of the handler, it still doesn't stop. The only way it stops is if I disable SPIM3 in the handler.

RE: SPIM STOP task isn't getting triggered by PPI

kv1980 — Mon, 16 Nov 2020 14:23:35 GMT

Hmm I tried this and just noticed something weird, PPI CH[2].EEP never gets set, it just stays =0x00. Maybe there is something that blocks using PPI CH[2]? It is the only thing I can see that isn't set correctly when I step through the debugger.

RE: SPIM STOP task isn't getting triggered by PPI

kv1980 — Mon, 16 Nov 2020 13:56:20 GMT

Ah yes I changed from Compare0 to Compare5 but never updated the PPI address (earlier when something else want working I got to thinking that Compare0 might be reserved by the SoftDevice like Timer0 is, I don't think that's the case though). I'll have to give this a try.

RE: SPIM STOP task isn't getting triggered by PPI

Daniel Chisholm — Mon, 16 Nov 2020 10:54:32 GMT

In line 35 you are connecting to event COMPARE0, however in the code you provide nothing us setting CC[0] to 6; by default it will be 0, i.e. effectively 65536. And in line 24 you setting CC[5] to 0xffff but it (COMPARE5) seems unused?

(BTW a lot of sympathy for your rant. And I think timer SHORTS can be accessed through the SDK function "...extended_compare...", which is not an immediately intuitive naming choice!)