Code hangs when using SPI3

[Madhukeshwar]

we are using SPI3 in nrf52840 with nrf SDK 16.0

we are using this as below

1. SPI3 init -polling mode  

2. SPI3 unint

3. SPI3 init - DMA mode

4. SPI3 unint 

5. SPI3 init -polling mode

6. SPI3 unit

 

The code gets hanged when we write through SPI3 after SPI3 is intialized in polling mode (STEP 5) in above steps 

Can anyone help us in identifying the reason for the hang? 

Thanks in advance,

 

 

Madhukeshwar P

[Edvin]

Ok, so on what function does it hang? Is it waiting in a while loop? Or is it some function that doesn't return?

Are you checking the return values for your SPI calls? Does any of the functions return != 0 when the issue occurs?

BR,
Edvin

[Madhukeshwar]

Hi,

the code hangs in  the below line
while (!nrf_spim_event_check(p_spim, NRF_SPIM_EVENT_END)){} in the file nrfx_spim.c

[Edvin]

Madhukeshwar said:

Yeah, we need to use some external device. you can tell us what need to checked

I suspected that. Is there a chance you can try to check if you are able to reproduce if you use another DK as the SPIS? (SDK\examples\peripheral\spis)

Can you grab another screenshot of the issue and expand the view of the callstack? 

Actually, it looks a bit weird:

What sort of transaction is this? Are you trying to read or write? Because the TX buffer has a length of 0x00, and the RX buffer is located in 0x00000000, but I can't see it's length. So either it means that you are trying to send a message with length 0, or you are trying to receive a message and store it in a buffer located at 0x00000000 (which will cause your device to crash if it was actually stored there, but I guess it is a NULL pointer, because this is a TX transaction, and not an RX or a two way transaction). 

So if you could expand the callstack to show more than just two lines, and try to do some research as to what kind of transaction that is ongoing. Why does it try to send a message with length 0?

BR,

Edvin

[Madhukeshwar]

Edvin said:

What sort of transaction is this? Are you trying to read or write?

We are trying to write with length 2. I have checked by logging. 

//logs printed to check tx_buffer_length
<info> app: p_spi_instant     5DB38
<info> app: p_tx_buffer       2002CBE2
<info> app: tx_buffer_length  2
<info> app: p_rx_buffer       0
<info> app: rx_buffer_length  0

Edvin said:

Why does it try to send a message with length 0?

I am not getting in the call stack why it is showing length as 0.
In the call stack, sometimes TX buffer length is zero. sometimes it has some value. but the issue occurred at the same location each time.

I have taken the multiple screenshots whenever the issue got reproduced. I have attached below.

[Edvin]

What sort of SPI device are you using? Is it possible (for you or me) to write a dummy SPIS device running on another DK that can be used to reproduce the issue? What sort of SPIS commands does it need to respond to? Is it possible to provide a set?

BR,
Edvin

[Madhukeshwar]

Edvin said:

What sort of SPI device are you using?

we are using accelerometer. 

Edvin said:

s it possible (for you or me) to write a dummy SPIS device running on another DK that can be used to reproduce the issue?

I am trying to reproduce the issue. 

I found out that NRF_SPIM_EVENT_ENDTX is not getting generated and so the NRF_SPIM_EVENT_END  event. 
what could be the possible reason for NRF_SPIM_EVENT_ENDTX to not get generated?

[Edvin]

What accelerometer? I have a couple laying around. 

Madhukeshwar said:

what could be the possible reason for NRF_SPIM_EVENT_ENDTX to not get generated?

well, I haven't seen any of your code yet, so difficult to say. But I would say that if you didn't actually send an SPI command, but queued it up, that may lead to these kinds of deadlocks. 

However, this also looks like a possible suspect:
https://docs.nordicsemi.com/bundle/errata_nRF52840_Rev3/page/ERR/nRF52840/Rev3/latest/anomaly_840_193.html#anomaly_840_193

The workaround for this errata would either be to make sure that the transmission is completed before you uninit/suspend it, or you can use a timer or something to detect that a certain amount of time has passed without it returning, and power cycle the SPIM3 using the snippet in the errata documentation.

BR,
Edvin

[Madhukeshwar]

Edvin said:

What accelerometer? I have a couple laying around. 

we are using adxl355.

Edvin said:

I haven't seen any of your code yet, so difficult to say.

Our project is too huge. we are trying to reproduce it in another project. we aren't able to reproduce the issue in another project. 

Edvin said:

docs.nordicsemi.com/.../anomaly_840_193.html

We are not using TASK_SUSPEND. this wont be the possible suspect.

Edvin said:

you can use a timer or something to detect that a certain amount of time has passed without it returning, and power cycle the SPIM3 using the snippet in the errata documentation.

After executing this code snippet it is again returning to that while loop.
Even I tried to abort the spi transfer, after executing this abort function it is returning to while loop only. it is coming out of while loop only when the device resets. 

[/quote]

[Madhukeshwar]

hey,

we wanted to follow up on this issue.even when using timer as suggested our code still stucks in the while loop.Please suggest if there are any other workaround or other ways to look into this issue

[Edvin]

Hello,

Sorry for the late reply. I had to work on some non-DevZone related tasks last one and a half week. 

It is still not clear to me exactly what your issue is. What API is hanging? And how did you disable it in step 4, and how did you enable it in step 5?

Best regards,

Edvin

[Edvin]

Do you use NRFX_SPIM_FLAG_HOLD_XFER when transferring your SPI messages?

I have seen occasions of this behavior during uninit when the NRFX_SPIM_FLAG_HOLD_XFER is being used, and they used some event + PPI to trigger actually sending the transfer. 

In this case, p_cb->transfer_in_progress is set to true in nrfx_spim_xfer(), but the NRF_SPIM->TASKS_START is never triggered. Later, when the nrfx_uninit() is being called, this part:

    if (p_cb->handler)
    {
        nrf_spim_int_disable(p_spim, NRF_SPIM_ALL_INTS_MASK);
        if (p_cb->transfer_in_progress)
        {
            // Ensure that SPI is not performing any transfer.
            nrf_spim_task_trigger(p_spim, NRF_SPIM_TASK_STOP);
            while (!nrf_spim_event_check(p_spim, NRF_SPIM_EVENT_STOPPED))
            {}
            p_cb->transfer_in_progress = false;
        }
    }

will try to stop the ongoing transaction, and wait for the NRF_SPIM_EVENT_STOPPED, which will never occur, since it was not started. 

Could this be what you are seeing?

BR,

Edvin

[Madhukeshwar]

Hi,

Thanks for the reply

Edvin said:

Do you use NRFX_SPIM_FLAG_HOLD_XFER when transferring your SPI messages?

we are using NRF_DRV_SPI_FLAG_HOLD_XFER during DMA mode. 

Edvin said:

What API is hanging? And how did you disable it in step 4, and how did you enable it in step 5?

In API- spim_xfer the code is hanging. that to in the below mentioned while loop. 
I have checked the flow. NRF_SPIM_TASK_START is already triggered. only NRF_SPIM_EVENT_ENDRX is generated , but not the  NRF_SPIM_EVENT_ENDTX, so It got stuck the while loop.

 if (!p_cb->handler)
    {
        while (!nrf_spim_event_check(p_spim, NRF_SPIM_EVENT_END)){}

To disable spi3 we are using, nrf_drv_spi_uninit() and then nrf_spim_event_clear to clear NRF_SPIM_EVENT_END.

Edvin said:

Could this be what you are seeing?

no this is not the case.