Get stuck on while (! spi_xfer_done) when using spim

Hi all,

I had a problem using the spim function of nrf52832 to drive st25r3911, and now I'm pretty sure it's the problem here in spi.

here is the code for transmission:

and when st25r3911 triggers an interrupt, the following code is called:

PlatformSpiTxRx () in the code is equivalent to nrf_spi_tx_rx ();

Then spi will send and receive data normally, but no other code will be executed when it is executed here, so it seems to be stuck in this place:

In addition, I used the logic analyzer to capture the data at this stage:

Where D4 is the interrupt signal, and the others from d0 to d3 are: cs,mosi,miso,clk;

As you can see from the data, after executing the 0x57 instruction, I received the data 0x028000 from miso, but then the program got stuck, and I couldn't find any reason.

Parents
  • Hello,

    Sorry to say, but I don't see any reason why this should fail. You can find some nrfx spim examples here for comparison:
    https://github.com/zephyrproject-rtos/hal_nordic/tree/master/nrfx/samples/src 

    The nrf_drv_spi_transfer() is one abstraction layer higher than using the nrfx api directly.

    Kenneth

  • Hi,

    To supplement today's findings, according to the timing diagram in the manual below,

    we can see that both endtxand endrxshould be generated by events in spi sending, so I compared the timing diagrams in spi sending and found that some of them are different.

    The actual waveform is missing the waveform generated by the endtx/endrx event.

    The code that refers to this part of the code is in the spim_xfer() function

    I think the code has executed the code in position 1, but it is stuck in position 2, because the second position is followed by a pull up of the cs pin.

    The next direction I want to look for is what caused the code to get stuck in the second position, or what caused the endtx and endrx events not to occur.

    -----------------------------------------------------------------------------------------------------------------

    here is the latest findings, the spim didn't trigger the stoped event when end event is triggered, so the code is stuck in the left arrow.

  • Hello,

    Any way you can recreate this on a DK and send the project here so I can test also?

    I can't see any obvious reason why this should fail, other than there is actually an spim interrupt handler enabled that clear the event for you.

    Kenneth

  • Hi,

    this is the project address, https://github.com/LNqueen/miaomiao_ble.git, another reminder is that this project needs to be used in conjunction with the st25r3911 development board, thank you for helping me find out about this.

  • Hi,

    I have found the cause of the problem, which is the problem of interrupt priority.

    In the sdk_config, there are three interrupt priorities related to spi, namely nrfx_spim_default_config_irq_priority,nrfx_spi_default_config_irq_priority and spi_default_config_irq_priority. since the third is at the bottom of the comparison, the priority levels I have been adjusting are the first two. however, I only found out today that the third is the main parameter in the setting. after I adjusted the third priority level to 5 (the priority of external interrupt is 6), this problem did not occur.

Reply
  • Hi,

    I have found the cause of the problem, which is the problem of interrupt priority.

    In the sdk_config, there are three interrupt priorities related to spi, namely nrfx_spim_default_config_irq_priority,nrfx_spi_default_config_irq_priority and spi_default_config_irq_priority. since the third is at the bottom of the comparison, the priority levels I have been adjusting are the first two. however, I only found out today that the third is the main parameter in the setting. after I adjusted the third priority level to 5 (the priority of external interrupt is 6), this problem did not occur.

Children
  • Hi 

    Good to hear you found the problem!

    Kenneth is currently out in Christmas holiday, but if you have more questions to this case he will be back next week. 

    Best regards
    Torbjørn