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

[taspon98]

My SPIM seems to stopped working when migrating from NCS 2.5.0 to 2.7.0, so I decided to downgrade to 2.6.0, and it seems the issue is still there. When migrating to 2.6.0, all the changes I have made during the migration that might impact the driver is for GPIOTE due to the API changes, so I don't understand what could be causing the change in behavior of the hardware.... I checked the change log, and I couldn't really find anything that impacts the behavior of these modules. If anyone is also going through the migration and can provide any insights or help it would be greatly appreciated. Thanks! 

[Susheel Nuguru]

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?

[taspon98]

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. 

[Susheel Nuguru]

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.

[taspon98]

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?

[taspon98]

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....

[taspon98]

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;

[Susheel Nuguru]

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.

[taspon98]

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.