ST25R3916B: Wakeup mode but no more wakeups

[OliM]

I am using a ST25R3916B with RFAL 4.0, connected to a STM32WB55 via SPI in a battery powered application, so naturally wakeup mode is used. Specifically inductive wakeup with auto averaging. 
For a short test on the table this works just finde, but when I let the setup run for multiple hours and thousands of wakeups, at some point it becomes unresponsive. 
If I measure the generated field via oscilloscope, I can still see the ~35µs pulses every 400ms, just as I have setup the mode, but there is no interrupt generated.

I do not want to completely dismiss the possibility that the MCU is missing one interrupt somehow, but shouldn't a consecutive change trigger a new interrupt?

What I have found in the AN is 
Values close to the edges can lead to a configuration that never wakes-up the system, so, if delta is the difference that triggers an interrupt, the reference value must always satisfy the following conditions:

• reference - delta > 0

• reference + delta < 255

Is there a known situation were auto averaging can maneuver itself into that position and not recover?

Edit: Also I have seen in the Errate that MOSI needs to be be pulled low during IRQ register read, but the RFLA seems to solve this with the following code, right?

[Brian TIDAL]

Hi Oliver,

Do you use an X-NUCLEO-NFC08A1 connected to STM32WB55 or do you use your own custom board?

Regarding the inductive wake-up, is it inductive amplitude and/or inductive phase wake-up? Could you provide the rfalWakeUpConfig being used on your side?

Could you read the Measurement auto-averaging display registers (amplitude and/or phase according to your configuration) and the Measurement display registers (amplitude and/or phase according to your configuration). You can use irqTout=true (wto=1 in Wake-up Timer Control Register) to have periodic wake up timer interrupt and to read the measurements display registers or you can use rfalWakeUpModeGetInfo() to retrieve Wake-Up Mode information.

If possible, once a periodic reading of the measurements display registers is implemented, could you connect a logic analyzer on SPI (CLK, MISO, MOSI, CS) + ST25R_IRQ pins and share the logic analyzer file?

Rgds

BT

[OliM]

Hello Brian,

I use a custom board. The phase wake-up is used.
The complete configuration is the following:

static rfalNfcDiscoverParam 	s_DiscParam;
...
s_DiscParam.wakeupEnabled       = true;
s_DiscParam.wakeupConfigDefault = false;

// ----------------- wakeup configuration ---------------------------------------
s_DiscParam.wakeupConfig.period  = RFAL_WUM_PERIOD_400MS;
s_DiscParam.wakeupConfig.irqTout          = false;
s_DiscParam.wakeupConfig.swTagDetect      = false;
s_DiscParam.wakeupConfig.refWU.enabled    = false;
s_DiscParam.wakeupConfig.indAmp.enabled   = false;
s_DiscParam.wakeupConfig.indPha.enabled   = true;
s_DiscParam.wakeupConfig.cap.enabled      = false;
s_DiscParam.wakeupConfig.indPha.delta     = 2;
s_DiscParam.wakeupConfig.indPha.fracDelta = 0U;
s_DiscParam.wakeupConfig.indPha.reference = RFAL_WUM_REFERENCE_AUTO;
s_DiscParam.wakeupConfig.indPha.autoAvg   = true;
s_DiscParam.wakeupConfig.indPha.aaWeight  = RFAL_WUM_AA_WEIGHT_32;
s_DiscParam.wakeupConfig.indPha.aaInclMeas = false;

s_DiscParam.wakeupNPolls   = 3;

 What I have done now is to connect an analyzer on the IRQ line and added a function to read all 10 wakeup registers (0x32U to 0x3B) via BLE. 
A typical reading looks like this: 32 00 00 00 00 27 00 1C 31 00 
which would mean the above settings are actually set, computed reference is currently 0x1C and the last measurement was 0x31 (which makes sense because mit test setup is pretty ideal in terms of wakeup delta)

Now to wait for the issue to come up again.

I am not sure about the proposed continuous wakeup to read the registers, because that changes the IRQ behavior significantly.

[Brian TIDAL]

Hi Oliver,

reading the registers through BLE should be fine and less intrusive than using the wake-up timer.

I ran the STEVAL-25R3916B during 2 hours with Inductive phase wake up, 400ms and auto average. The averaged reference is very stable (5dh) and I receive the interrupt as expected when a tag enters the operating volume. 

Could you share more information regarding the issue: how long does the device stay in wake-up mode before facing the issue? Is there any environmental changes (temperature, load, etc.)?

Rgds

BT

[OliM]

What I do is to wake the device up very frequently (about every 8s) by presenting a tag (actually switching the antenna connection of a tag-ic on and off via a relay instead of moving it), which is then read before the device returns to wakeup mode.
At some point the device no longer reacted to change, it just stayed in wakeup mode. Like I said after hours, the last time after I came back after one night and thought to have fixed a erroneously cleared RTOS-notification before.

What about

 I do not want to completely dismiss the possibility that the MCU is missing one interrupt somehow, but shouldn't a consecutive change trigger a new interrupt?

Is this the behavior? Or is the wakeup IRQ only a one time reaction until wakeup mode is started again?

[Brian TIDAL · Accepted solution]

Hi Oliver,

Here is the behavior if the device remains in wake-up mode with several measurements that have a phase difference greater than Δpm:

(black is the measurement, blue the AA reference, red dots are interrupts)

Note : The IRQ pin transitions to low after the interrupt bit or bits that caused its transition to high are read. The st25r3916CheckForReceivedInterrupts() function reads the interrupt registers in a loop until the IRQ pin is low.

So, if the MCU misses an interrupt (this is very unlikely), the IRQ stays high.

Could you provide information about the RTOS integration? Is the RTOS FreeRTOS™? Do you use a dedicated high-priority interrupt service routine (ISR) task to handle the interrupt pin? Is the STM32WB55 also in low-power mode during the ST25R3916B wake-up mode, and does it exit low-power mode when the IRQ moves to a high level? How do you protect the SPI bus from race conditions between the NFC task and the ISR?

Rgds

BT

[OliM]

---

@Brian TIDAL wrote:

Could you provide information about the RTOS integration? Is the RTOS FreeRTOS™? Do you use a dedicated high-priority interrupt service routine (ISR) task to handle the interrupt pin? Is the STM32WB55 also in low-power mode during the ST25R3916B wake-up mode, and does it exit low-power mode when the IRQ moves to a high level? How do you protect the SPI bus from race conditions between the NFC task and the ISR?

Rgds

BT

---

It is FreeRTOS using one low priority task for NFC "work" and one high priority task to service the interrupts. The later is activated via Notification from an rising edge EXTI. The former is woken, again by notification by, the IRQ task and then keeps running until wakeup mode is reached.
The WB55 is in Stop2 Mode with wfi if all task are sleeping and of course the EXTI is configured as an interrupt wakeup.
The SPI is shared via a (recursive) Mutex on platformProtectST25RComm()/platformUnprotectST25RComm. If an external task wants to exchange data via NFC, the data is exchanged back and force via queues so NFC itself is handled exclusively in the NFC "work" task.

Edit: This Morning my test was still running fine. Only change since then was an added timeout on SPI transceive (for bigger amounts of data the transceive is done via DMA and awaited with notifyWait, which did not time out before). Keeping my fingers crossed and thank you very much for the insights until now.

[OliM]

As the HW kept running for the last 5 days, I have set your WakeUp analysis as a solution for my original questions @Brian TIDAL 
For now it sounds like at some point our SPI driver is failing to call the finished callback after a transfer. Which would be quite an issue in its own right but no ST25R/rfal issue.