SPIM start task not functioning normally when migrating from 2.5.0 to 2.6.0

RE: SPIM start task not functioning normally when migrating from 2.5.0 to 2.6.0

PuffinEgg — Wed, 31 Jul 2024 16:16:38 GMT

Thank you! Greatly appreciated.

RE: SPIM start task not functioning normally when migrating from 2.5.0 to 2.6.0

Susheel Nuguru — Wed, 31 Jul 2024 16:15:32 GMT

This is a bug then in our end, I will create a bug report internally to track this and let the dev team fix it for future releases.

RE: SPIM start task not functioning normally when migrating from 2.5.0 to 2.6.0

PuffinEgg — Wed, 31 Jul 2024 16:03:53 GMT

As mentioned in the link to my other post, changing it to 4 (the default on 2.7.0 is actually 4) causes multiple IRQ registration conflict with the Zephyr BT LL stack (CONFIG_BT_LL_SW_SPLIT). I had NRF52_ANOMALY_109_WORKAROUND_EGU_INSTANCE changed to 5 and it gives me the tx and rx length issue.

RE: SPIM start task not functioning normally when migrating from 2.5.0 to 2.6.0

Susheel Nuguru — Wed, 31 Jul 2024 05:27:06 GMT

Turning off the option might give you some other side effects if your chip is effected by this Anomaly. Could you try changing the NRF52_ANOMALY_109_WORKAROUND_EGU_INSTANCE value to 4 instead to keep the anomaly workaround but still get rid of the error?

RE: SPIM start task not functioning normally when migrating from 2.5.0 to 2.6.0

PuffinEgg — Tue, 30 Jul 2024 16:46:41 GMT

The issue seems to coming from NRFX_SPIM_NRF52_ANOMALY_109_WORKAROUND_ENABLED which is resetting the xfer_dest.tx_length and rx_length to 0 in nrfx_spim.c:802. On 2.5.0 this option seems to be turned off by default. On 2.7.0, not having this option gives me the error described in one of my other post ( Multiple IRQ registration build error when migrating from NCS 2.5.0 to 2.7.0), so I can only set NRFX_SPIM_NRF52_ANOMALY_109_WORKAROUND_ENABLED = n to fix this issue.

RE: SPIM start task not functioning normally when migrating from 2.5.0 to 2.6.0

Susheel Nuguru — Tue, 30 Jul 2024 09:36:38 GMT

If you are seeing this only after migrating to later versions of SDK, it might be a possible bug in the API.

I would recommend you to put a breakpoint in nrfx_spim_xfer and step in the code since I can see in modules\hal\nordic\nrfx\drivers\src\nrfx_spim.c->nrfy_spim_buffers_set the the MAXCNT register is set for TXD if you are using the easyDma version of the SPI. Find out by stepping line by line as to why that configuration did not get set. I am guessing there might be some configuration that we might have missed? Just trying to avoid future surprises and bugs with the workaround you had to make this work. Or maybe this is a bug at our end. In any case it would be good to know for sure why this happened.

RE: SPIM start task not functioning normally when migrating from 2.5.0 to 2.6.0

PuffinEgg — Mon, 29 Jul 2024 23:43:43 GMT

I have found the issue however I am unsure why it is only happening in 2.6.0/2.7.0. Apparently, the TXD.MAXCNT register for some reason did not take in the tx_length value in nrfx_spim_xfer_desc_t after calling nrfx_spim_xfer, so I had to manually add that in. (shown below)

nrfx_spim_xfer_desc_t spim_xfer_desc = {
    .p_tx_buffer = NULL, 
    .tx_length = tx_len,
    .p_rx_buffer = NULL,
    .rx_length = 0
};

err = nrfx_spim_xfer(
        spim,
        &spim_xfer_desc,
        NRFX_SPIM_FLAG_TX_POSTINC | NRFX_SPIM_FLAG_HOLD_XFER | NRFX_SPIM_FLAG_NO_XFER_EVT_HANDLER | NRFX_SPIM_FLAG_REPEATED_XFER);
if (err != NRFX_SUCCESS) {
    return false;
}

NRF_SPIM_Type *spim1_reg = (NRF_SPIM_Type *)NRF_SPIM1_BASE;
spim1_reg->TXD.MAXCNT = tx_len;

RE: SPIM start task not functioning normally when migrating from 2.5.0 to 2.6.0

PuffinEgg — Mon, 29 Jul 2024 22:04:32 GMT

However, when I check the status flag of SPIM 1 it seems the EVENTS_END flag is set to 1, which means the transaction is successful despite not seeing any data coming through at my end....

RE: GPIOTE input not functioning normally when migrating from 2.5.0 to 2.6.0

PuffinEgg — Mon, 29 Jul 2024 19:59:15 GMT

Hi, I did some further testing with the custom hardware, and it seems like the SPI start task is not getting triggered by the PPI. However, I don't think this is a PPI issue since the fork GPIOTE task is getting triggered correctly (not seeing any data coming out using a logic analyzer).... To replicate this, are you able to correctly trigger a SPI sending task using the timer compare event and with a gpiote output toggle as the fork task?

RE: GPIOTE input not functioning normally when migrating from 2.5.0 to 2.6.0

Susheel Nuguru — Mon, 29 Jul 2024 16:39:16 GMT

There might changes in many drivers and libraries and we need to verify changes in each peripheral separately. Based on the description you wrote, I thought the issues is mainly in GPIOTE which can be verified if you are able to edit and run the sample I mentioned below with your code snippet. If that works ok, then maybe the problem is even deeper with integration.

I might need help to replicate the issue at my end to be able to debug and isolate the issue.

RE: GPIOTE input not functioning normally when migrating from 2.5.0 to 2.6.0

PuffinEgg — Mon, 29 Jul 2024 16:29:42 GMT

Hi this is just a code snippet from my project code. I guess I am just trying to figure out if there are any changes introduced to either SPI, PPI (for some reason the channel number allocated is different between 2.5.0 and 2.6.0), GPIOTE, or SPIM that could cause this issue. I have already checked all the low level registers and it seems the configure register is the same between 2.5.0 and 2.6.0/2.7.0.

RE: GPIOTE input not functioning normally when migrating from 2.5.0 to 2.6.0

Susheel Nuguru — Mon, 29 Jul 2024 16:22:31 GMT

I can give it a try to apply your changes and see if it works on my end. Just to be sure before I start, is it this sample that I should take as a template-> zephyr\samples\boards\nrf\nrfx\src\main.c?