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
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
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
What sort of SPI device are you using?
we are using accelerometer.
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?
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
What accelerometer? I have a couple laying around.
we are using adxl355.
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.
docs.nordicsemi.com/.../anomaly_840_193.htmlWe are not using TASK_SUSPEND. this wont be the possible suspect.
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.
[/quote]
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.
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
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
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
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
Hi,
Thanks for the reply
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.
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.
Could this be what you are seeing?
no this is not the case.
Madhukeshwar said: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.
Then I guess it either didn't have the time to properly start, or it wasn't started before the uninit, which will hang like you see if you are using the HOLD_XFER flag.
To work around this, make sure that you don't have a pending transaction with NRFX_SPIM_FLAG_HOLD_XFER, by transmitting it.