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

[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]

#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

[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)

[superK]

Sorry for not speaking English.

It is a schematic and It's directly connected to the GPIO of the chip.

[Brian TIDAL]

Hi,

can you check that PA8 GPIO is configured as:

• GPIO mode: External interrupt Mode with Rising edge trigger detection
• GPIO pullup/pull down: no pull up and no pull down

Can you also check the platformProtectST25RComm() and platformUnprotectST25RComm macros (in plateform.h) to make sure the NVIC_DisableIRQ and NVIC_EnableIRQ use the correct EXTI9_5_IRQn interrupt (or its alias IRQ_3916_EXTI_IRQn if the PA8 has been labelled as IRQ_3916)?

#define platformProtectST25RComm()                    do{ globalCommProtectCnt++; __DSB();NVIC_DisableIRQ(IEXTI9_5_IRQn);__DSB();__ISB();}while(0) /*!< Protect unique access to ST25R communication channel - IRQ disable on single thread environment (MCU) ; Mutex lock on a multi thread environment      */
#define platformUnprotectST25RComm()                  do{ if (--globalCommProtectCnt==0U) {NVIC_EnableIRQ(IEXTI9_5_IRQn);} }while(0)               /*!< Unprotect unique access to ST25R communication channel - IRQ enable on a single thread environment (MCU) ; Mutex unlock on a multi thread environment */
 
 
OR:
 
#define platformProtectST25RComm()                    do{ globalCommProtectCnt++; __DSB();NVIC_DisableIRQ(IRQ_3916_EXTI_IRQn);__DSB();__ISB();}while(0) /*!< Protect unique access to ST25R communication channel - IRQ disable on single thread environment (MCU) ; Mutex lock on a multi thread environment      */
#define platformUnprotectST25RComm()                  do{ if (--globalCommProtectCnt==0U) {NVIC_EnableIRQ(IRQ_3916_EXTI_IRQn);} }while(0)               /*!< Unprotect unique access to ST25R communication channel - IRQ enable on a single thread environment (MCU) ; Mutex unlock on a multi thread environment */

Can you also check that st25r3916Isr() is called inside the EXTI9_5_IRQHandler

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 */
}

Rgds

BT

[Ulysses HERNIOSUS]

Hi,

NFC_SS is denoted as an input from MCU side in the schematic, it should be an output.

BR, Ulysses

[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