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
And do you see the callstack that brought it there?
yeah,
I have attached the screenshot of the call stack.
I have checked status of SPI Un-initialization and initialization with the error code it returns. It returned NRF_SUCCESS but the issue still exist.
Have you tried sending it an SPI message,
yeah. This issue is occurring when we send an SPI message i.e. in spim_xfer function it is getting stuck. The issue is occurring at the same location. but not every time. out of 12 hrs. it can occur up to 4times.
Do you need to use some external device (SPI device)?
Yeah, we need to use some external device. you can tell us what need to checked. will check that and update you.
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 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
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
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.
