ST25R3916 Wake-up mode

[MPeli.1]

Hello,

i have been trying to put the st25r3916 in wake-up mode but i detect high power consumptions (around 900 uA). I am using a very basic code just to test current consumtion, i2c communication seems to work, but maybe i am missing some parts.

int main(){
       rfalAnalogConfigInitialize();
 
	if(rfalInitialize() != ERR_NONE)
	{
 
	}
	else
	{
		rfalWakeUpModeStart(NULL);
        }
}

Am i missing some api calls?

Thanks,

Regards

[Ulysses HERNIOSUS]

And here the good interrupt handling. You can see the device address, the 5Ah for reading interrupt status and all the received bytes.

[MPeli.1]

Hello,

should be better in this trace, sometimes wires gets underneath the mb1414-b board where there is the rf field and that could influence the communication, however the result is the same, our nfc-a tag is not correctly being read.

Thank you very much,

Regards

[vcaia.1]

Additional note: the NFC-A tag we're using is a tag based on Nordic's nrf52 chipset, produced by us. It is read correctly when the discovery board is assembled.

[Ulysses HERNIOSUS]

Hi,

With the last interrupt the an Anticollision response is received - without any errors: 88 C6 C4 11 9B. I don't see any indication why that frame should be treated as a collision.

The trace makes me think that you have an issue on I2C/signal integrity. I have seen cases where I think the logic analyzer is not correctly receiving due to noise but in e.g. the last frame also the I2C from the MCU is weird:

S - 50Wr - FB - Re-Start - 50Wr - FB - 4D - Re-Start 50Rd - 00

All bytes receive an ACK. What the bytes mean is:

50Wr: Address 3916, following bytes are to be written

50Rd: Address 3916, following bytes are read from 3916.

FB : address space B

4D : start read from register 0D, with the previous prefix FB it is register 0D in space B

00 : The byte from the ST25R3916

On the I2C the first FB is for sure not triggered by the RFAL. I am more suspecting that MCU has not received the ACK to that byte and goes into re-transmission. I mean I never have seen such retransmissions triggered by I2C block or driver but maybe now is the first time.

I don't mean to say that this last frame is causing problems but maybe at other points the MCU is also receiving errors/wrong data from I2C.

I would advice to do signal integrity, shorten wires, shield wires, ....

Maybe in close distance of the tag the reader gets detuned, the field strength reduces and less noise gets injected into I2C lines.

Regards, Ulysses

[MPeli.1]

Hello,

The software initialization is correct in your opinion? I posted the code yesterday monday 23rd​.

Thank you very much,

Regards​

[Ulysses HERNIOSUS]

Hi,

software initialization looks correct. I would just move the rfalNfcDiscover(&nfcParam); after the DPO stuff before the while(). But I don't see a real problem with it.

Seeing the last traces there a appear a lot of errors in I2C communication.

You could actually remove the DPO stuff. For the given board it is not necessary and was activated to demonstrate it to customers.

Regards, Ulysses

[Ulysses HERNIOSUS]

Hi,

some tips also from Travis Palmer: Better to connect the I2C on J101 to be able to move the lines perpendicularly away from the antenna. Also connect close by a ground to avoid loops built by signal line + ground which will pick up NFC field. Also guide the GND + I2C lines together to the MCU board.

Ulysses

[vcaia.1]

Hello Ulysses,

we made some progress, but we're still not able to read NFC-A effortlessly.

We did better wiring, shorted cables, and we tweaked some software. Now we can read NFC-V instantaneously, and we can read NFC-A, but the later takes approximatively 12s, mostly spent in the anticollision loop...

I tried to insert some extra debug information, but I can't make any sense out of it. I am currently logging the changes in the state machine of rfal_nfc.c and the content of the IRQ registers, as they are read right after the IRQ.

I attach here an excel file where in the white part the board is functioning without any tag; the grey part is while reading an NFC-V, and the last part is about reading the NFC-A tag.

Actually the sequence of "1" is much much longer than what you find in the excel.

Do you have any hint?

Thanks a lot,

Vito.

[vcaia.1]

attached .xls file

[Ulysses HERNIOSUS]

Hi,

I feel that you removed some noise from the system, maybe I2C is now clean from it but receiver may pick-up noise and falsely interpret it as collisions. Such things you would see inside rfalNfcaPollerGetFullCollisionResolutionStatus(). I assume it spends a lot of time in it trying to resolve collisions - and eventually fails in doing so.

You could:

• Verify this using a logic analyzer / debug this.
• Further improve your cabling, measure the supplies. Maybe it is solved by just using thicker wires for supplies/gnd. I asked you before, if you send a photo we could give more educated hints
• Reduce the gain in the analog configs, this costs read range but may cure the wrongly recognized collisions.

Regards, Ulysses

P.S.: In your xls you are wrongly interpreting the interrupts, probably wrong endianess, the interrupts seen there are I_txe, I_rxs, I_rxe and I_nre. I would expect to also sometimes see I_col, not sure if you really see all interrupts, better to use a logic analyzer.