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;

  }

[superK]

It's a circuit error. It is currently being used as output.

[superK]

I used the X-NUCLEO-NFC06A1 example.

Everything you said...

It is implemented in platform.h.

But in the IRQ handler

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

If you do not implement this, you will not communicate with st25r3916.

The example is also implemented as follows.

void EXTI0_IRQHandler(void)

{

 BSP_SPI1_IRQHandler();

}

[superK]

The code is adapting.

The end goal is to drive 2 chips.

[Brian TIDAL · Accepted solution]

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

[bchalant]

Hi,

I've tried to change priority of EXTI0 and USB to 1 but same issue appears...

Maybe i have to change tick implementation in platform.h with a hardware timer ?

I think you're right it's a deadlock but i cant find why it's happend...

Best regards

[Brian TIDAL]

Hi,

using the debugger, can you try to break execution while the system is stuck and have a look to where the execution is. If the execution is inside hard fault handler, it is likely a crash (stack overflow, etc.). If the execution is around HAL_Delay() or HAL_GetTick(), it is likely a deadlock.

No need to use HW timer, this should work with the Systick. By the way, what is the priority of the SYSTICK interrupt?

Rgds

BT