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;