How to fix "IRQ line not working" error in Initialization Selftest ?

[TCrav.1]

Hi ST,

We bought a ST25RU3993-HEPV last year to evaluate the RFID chip and wanted to control it using SPI (see that question, where you already helped us). The master SPI is a Cortex A15.

We managed to set-up SPI communication and to implement spiTxRx() to read/write registers (single and continuous read/write).

We started to integrate others ST functions from the ST25RU3993 STUHFL SDK package v3-0-2-0 package, especially the st25RU3993Initialize function.

Before doing anything, this function runs a selftest to check three things:

• SPI communication works (write & read 4 bytes in Modulator control register 1 register)
• Check EN pin by calling st25RU3993ResetDoNotPreserveRegisters
  • We did not connect EN pin to a GPIO for now, so the chip is always enabled. I replaced the OFF/ON of the EN pin by a Soft Init (83h) single command.
• Check that the IRQ line is working, by sending 24 bytes in FIFO register instead of the 48 announced, and waiting more than 40ms, to have a timeout triggered on ST25RU3993 side.

The first two steps are OK, but we are struggling with the last one: The Irq_fifo

(byte 5 of Interrupt register 1) doesn't trigger.

When reading the Interrupt register 2 (38h), bit 0 (Preamble detect error / FIFO overflow error) is high and bit 5 of FIFO status register too (More than 24 bytes were loaded to one of the FIFOs).

Can you help us with that ?

Here is the part of ST code that we are struggling on:

// set up 48Byte transmission, but we supply less, therefore a fifo underflow IRQ is produced
	st25RU3993SingleWrite(spictx, ST25RU3993_REG_TXLENGTHUP, 0x03);
	st25RU3993SingleCommand(spictx, ST25RU3993_CMD_TRANSMCRC);
	st25RU3993ContinuousWrite(spictx, ST25RU3993_REG_FIFO, myBuf, 4);
	st25RU3993ContinuousWrite(spictx, ST25RU3993_REG_FIFO, myBuf, 4);
	st25RU3993ContinuousWrite(spictx, ST25RU3993_REG_FIFO, myBuf, 4);
	st25RU3993ContinuousWrite(spictx, ST25RU3993_REG_FIFO, myBuf, 4);
	st25RU3993ContinuousWrite(spictx, ST25RU3993_REG_FIFO, myBuf, 4);
	st25RU3993ContinuousWrite(spictx, ST25RU3993_REG_FIFO, myBuf, 4);
 
	st25RU3993WaitForResponse(spictx, RESP_FIFO);
	if (!(st25RU3993GetResponse(spictx) & RESP_FIFO)) {
		dev_err(&spictx->spidev->dev, "%s(%d): IRQ line not working\n", __FUNCTION__, __LINE__);
		return 3;
	}

Here is our new implementation of st25RU3993ResetDoNotPreserveRegisters:

void st25RU3993ResetDoNotPreserveRegisters(struct st25ru3993_spi_context *spictx)
{
#if ST25RU3993_ENABLE_CONTROL
	gpio_set_value(spictx->enable_gpio, LOW);
	delay_ms(1);
	gpio_set_value(spictx->enable_gpio, HIGH);
	delay_us(10);
#else
	st25RU3993SingleCommand(spictx, ST25RU3993_CMD_SOFT_INIT);
#endif
	st25RU3993WaitForStartup(spictx);
}

Regards,

Thomas.

[Ulysses HERNIOSUS]

Hi Thomas,

I would suspect your MCU is not jumping into st25RU3993Isr() and thus not updating the global variable.

BR, Ulysses

[TCrav.1]

Hi Ulysses, thank you for your answer !

You are right, the st25RU3993Isr() function is not called in this case, but it is in other cases:

The two first actions of the selftest of the st25RU3993Initialize function triggers IRQ, that are well handled:

The first one triggers st25RU3993Isr() and we can read IRQ registers 1 & 2 in st25RU3993Response: 0x40a0, corresponding to "IRQ due to the end of Rx" and "IRQ due to an change of the oscillator, PLL, or RF field status ".

The second one triggers st25RU3993Isr() and we can read IRQ registers 1 & 2 in st25RU3993Response:

0x4000, corresponding to "IRQ due to the end of Rx"

The last selftest, about the IRQ handling, doesn't trigger the st25RU3993Isr() function, and we end up reaching the timeout of 45ms of the st25RU3993WaitForResponse() function.

I can't understand why.

-Thomas

[Ulysses HERNIOSUS]

Hi Thomas,

Please observe whether the IRQ line goes high during that procedure. If it does then it should be something in your MCU/porting code which fails to correctly execute the ISR.

BR, Ulysses

[TCrav.1 · Accepted solution]

Hi Ulysses,

We found the problem ! When declaring the IRQ to my Linux Kernel Driver, I put the detection on Falling Edge instead of Rising !

Changed the value, and the selftest works like a charm !

Thanks for your help, have a good day!

-Thomas