ST25R3916irq error problem ?

[superK]

We are communicating with the st25r3916 chip normally.

But after about 14 minutes,

The value of the IRQ pin is maintained at HIGH.

You fall into an infinite loop in the function st25r3916CheckForReceivedInterruptts().

What is the problem ?

please I'd appreciate it if you let me know.

Infinite loop.

while( platformGpioIsHigh( ST25R391X_INT_PORT, ST25R391X_INT_PIN ) )

  {

    st25r3916ReadMultipleRegisters( ST25R3916_REG_IRQ_MAIN, iregs, ST25R3916_INT_REGS_LEN );

    

    irqStatus |= (uint32_t)iregs[0];

    irqStatus |= (uint32_t)iregs[1]<<8;

    irqStatus |= (uint32_t)iregs[2]<<16;

    irqStatus |= (uint32_t)iregs[3]<<24;

  }

[Brian TIDAL]

Hi,

can you share some details about your setup:

• do you use an X-NUCLEO-NFC06A1 reader board on top of STM32 NUCLEO MCU board or your own custom board? In case of custom board, which MCU is being used?
• which firmware package have you used (X-CUBE-NFC6, STSW-ST25R-LIB or STSW-ST25RFAL002)? Which version of RFAL do you have (RFAL_VERSION value in rfal_rf.h)?
• do you use an RTOS or a bare metal implementation?
• is the IRQ line shared with another device?

Would it be possible to connect a logic analyzer on the SPI (CLK, MISO, MOSI, SS) + IRQ_3916 and share the trace?

Thanks

Rgds

BT

[superK]

#define RFAL_VERSION                               (uint32_t)0x02000aU                    /*!< RFAL Current Version: v2.0.10                     */

​

It is a custom board and the mcu uses stm32f407.

​

RTOS is not implemented.

​

Sorry, there is currently no logic analyzer.

[Brian TIDAL]

Hi,

some additional questions:

is the IRQ line shared with another device? can you share the schematics ? How is configured the GPIO connected to the IRQ_3916?

Thanks

Rgds

BT

[Ulysses HERNIOSUS]

Hi KHyun.1,

on 3916 we have never observed the IRQ maintained at high / IRQ flood. Pleae provide a logic analyzer trace as requested by Brian.

I have seen also your other post Why does spi communication fall into an infinite loop? (st.com): Is that one now obsolete as the hang is one layer higher? If so, please comment on the other one.

Thanks, Ulysses

[superK]

​It was not that the spi communication went into an infinite loop, but that it stopped at the above IRQ.

Occurs when ATR is transmitted (RFAL_NFC_STATE_POLL_TECHDETECT)

It does not occur in case of DataExcharge. (RFAL_NFC_STATE_DATAEXCHANGE)

[Ulysses HERNIOSUS]

Hi,

likely an issue of missing locking as indicated by Brian: Inside technology detection the timing is denser and the chances of interrupts happening in vulnerable places is higher.

I saw in the other thread that you want to drive two 3916s. What you are doing here is it still with only one 3916 or did you start adapting the code?

All suggestions we are doing now are more of guesswork. A logic analyzer trace would allow us to give more definite answers.

BR, Ulysses

[Brian TIDAL]

Hi,

I had a look to your EXTI9_5_IRQHandler code and in my opinion this can cause some side effect: if a new interrupt is triggered just after line #4, it will be cleared by the HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_8); in line #6 of the code snippet. Therefore I would recommend the following implementation:

void EXTI9_5_IRQHandler(void)
{
 /* USER CODE BEGIN EXTI9_5_IRQn 0 */
 
 /* USER CODE END EXTI9_5_IRQn 0 */
 HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_8);
 /* USER CODE BEGIN EXTI9_5_IRQn 1 */
 st25r3916Isr();
 /* USER CODE END EXTI9_5_IRQn 1 */
}

Note: make sure to #include "st25R3916_irq.h" to avoid compiler warning.

Can you also double confirm that:

• PA8 is dedicated to the NFC_IRQ of a single device i.e. that nothing else is connected to PA8 (not connected to the IRQ of the second reader or to any other device).
• IRQ_ST25R_EXTI_IRQn is properly defined as EXTI9_5_IRQn in your plateform.h (feel free to share your plateform.h in private)

Rgds

BT

[bchalant]

Hi,

I have exactly same issue with ST25R3916... I've already try the fix proposed but nothing changed.

Is there any update about this issue ?

Thanks in advance,

BR

[Brian TIDAL]

Hi,

can you share more details about your setup:

• do you use ST boards (e.g. X-NUCLEO-NFC06A1 + NUCLEO-L476RG) or a custom board?
• which MCU is being used? On which pin is connected the ST25R3916_IRQ?
• Is your application based on an RTOS or is it bare metal based?
• how is protected the SPI communication? How is protected the IRQ?

Can you connect a logic analyzer on the SPI (CLK/MISO/MOSI/SS) + ST25R3916_IRQ and provide a trace?

Rgds

BT

[bchalant]

Hi,

• It's custom board with STM32L562, ST25R3916_IRQ is PA0.
• Bare metal based.
• Software protection :
  • #define platformProtectST25R391xComm() do{ globalCommProtectCnt++; \
    __DSB();NVIC_DisableIRQ(EXTI0_IRQn); \
    __DSB(); \
    __ISB(); \
    }while(0) /*!< Protect unique access to ST25R391x communication channel - IRQ disable on single thread environment (MCU) ; Mutex lock on a multi thread environment */
    #define platformUnprotectST25R391xComm() do{ globalCommProtectCnt--; \
    if (globalCommProtectCnt == 0U) \
    { \
    NVIC_EnableIRQ(EXTI0_IRQn); \
    } \
    }while(0)

I have also USB CDC communication. It's looks like USB, after a while, disturb the ST25R3916 IRQ management... But im not sure.

For the moment, i dont have any trace or SPI logic analyze.

Thanks

Best regards

[Brian TIDAL]

Hi,

if calls to the STM32 HAL are done inside the USB IRQ handler or inside the ST25R3916 IRQ handler (which is actually the case), the SYSTICK interrupt priority has to be higher than the USB or ST25R3916 interrupts. This is because the STM32 HAL has some active wait loops (e.g. SPI_WaitFlagStateUntilTimeout) based on tick being incremented by the SYSTICK handler.

I would suggest to check the priorities of the various interrupts as I suspect a deadlock. 

Regarding the priorities: The lower the number, the higher the priority, which means a priority of 0 is the highest priority an external interrupt can have.

Rgds

BT