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

[MPeli.1]

Hello,

here a brief setup scheme that shows our electrical connections and the trace derived from waveforms software.

For controlling the st25r3916 i am currently using a nrf51822 mcu, while for tag-a slave we are using a nrf52822 mcu with nfc that acts like a card slave.

I also include the source code used, that i derived from the st25r3916 discovery demo sources and rfal documentation.

rfalNfcDiscoverParam nfcParam;
rfalWakeUpConfig wuCfg ;
static rfalDpoEntry dpoSetup[] = {
// new antenna board
{.rfoRes=0, .inc=255, .dec=115},
{.rfoRes=2, .inc=100, .dec=0x00}
 
};
 
int main(){
 
 wuCfg.period = RFAL_WUM_PERIOD_200MS;
	wuCfg.irqTout = false;
	wuCfg.indAmp.enabled = true;
	wuCfg.indPha.enabled = false;
	wuCfg.cap.enabled = false;
	wuCfg.indAmp.delta = 2U;
	wuCfg.indAmp.reference = RFAL_WUM_REFERENCE_AUTO;
	wuCfg.indAmp.autoAvg = true;
	wuCfg.swTagDetect = false;
	wuCfg.cap.reference = 0;
 
	nfcParam.compMode = RFAL_COMPLIANCE_MODE_NFC;
	nfcParam.techs2Find = (uint16_t)RFAL_NFC_POLL_TECH_A;
	nfcParam.devLimit = 1;
	nfcParam.maxBR = RFAL_BR_106;
	nfcParam.totalDuration = 4000u;
	nfcParam.wakeupEnabled = false;
	nfcParam.wakeupConfigDefault = false;
	nfcParam.wakeupConfig = wuCfg;
	nfcParam.notifyCb = NULL;
	nfcParam.lmConfigPA.nfcidLen = RFAL_LM_NFCID_LEN_10;
 
 
	if(rfalNfcInitialize() != ERR_NONE)
	{
 
	}
	else
	{
		rfalNfcDiscover(&nfcParam);
		rfalDpoInitialize();
		rfalDpoSetMeasureCallback( rfalChipMeasureAmplitude );
		rfalDpoTableWrite(dpoSetup,sizeof(dpoSetup)/sizeof(rfalDpoEntry));
		rfalDpoSetEnabled(true);
		rfalSetPreTxRxCallback(&rfalPreTransceiveCb);
 
 while (1)										
	 {
 rfalNfcWorker();
	 }
 }
}

 Thank you very much,

Regards

[MPeli.1]

Here the brief electrical scheme

[Ulysses HERNIOSUS]

Hi,

unfortunately the trace is not usable. In the beginning it looks ok but later on (when the field got turned on?) it gets unreadable. Please try to see to improve the quality - twist wires, move them away from the antenna, etc.

For your reference I am attaching two screenshots of clearing an interrupt. The first one which looks ok. and a second one where the payloads make no sense at all.

Regards, Ulysses

[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

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

[vcaia.1]

Thank you for the prompt answer.

Indeed I just prepared some analyzer traces, which I attach here. First part is before the "1" second part is after the "1"s

The logic analyzer detects some errors (missing acks?), but for our MCU the communication is fine (no I2C errors detected). Also the payloads interpreted by the MCU match the ones on the analyzer, so I suppose that part is fine.

I shot a picture of the setup, I will upload it in a while, in the meantime I will try to follow your suggestions.

[Ulysses HERNIOSUS]

Hi,

the Logic analyzer trace this time only decodes Error-Error-Error. I would try to twist the 4 wires going to the logic analyzer.

Regards, Ulysses

[vcaia.1]

Yes I can, but it's not just "errors" in the trace.

This is the beginning of firstpart.dwf3logic inside the .zip file. We actually just found out that most of ERRORs are missing STOP bytes after the 4 IRQ register read.

Do you see the same thing or you can't read my files properly?

[Ulysses HERNIOSUS]

Hi,

my traces never showed real data but only Error-Error-Error which seems to have been a logic analyzer artifact: After removing the I2C decoder and re-adding it I could see useful data similar to yours.

As the NACK and STOP are generated by the master and immediately afterwards the task level performs I2C transfers I am suspecting a missing lock / premature unlock in your I2C code causing the missing STOP. From a first glimpse it seems not to cause bad effects but I would definitely repair this.

Reading the secondpart everything looks normal from RF comm: 93 20 (AC CL1) -> 88 39 2C 00 9D and >1sec later: 93 70 88 39 2C 00 9D -> 04 (SAK byte). The second cascade level could not be seen in the trace.

No idea about the long pause. Did you step through using the debugger? Or maybe an issue of your timer adaptions for the RFAL (platformTimerCreate(), platformTimerIsExpired(), platformDelay().

Definitely no sign of noise on the receiver.

Regards, Ulysses

Regards, Ulysses

[vcaia.1]

Thanks on the hints, we'll keep digging following your suggestions.

These tracks are not from step-debugging, but we print a lot of debug serial data which takes time. But less than 1s for sure, if that's the delay you referring to. From my debug, all of that time the state machine is looping into this branch without ever entering any other branches (indeed it just prints "1")

	if( ((gNfcDev.techsFound & RFAL_NFC_POLL_TECH_A) != 0U) && ((gNfcDev.techs2do & RFAL_NFC_POLL_TECH_A) != 0U) ) /* If a NFC-A device was found/detected, perform Collision Resolution */
	{
		static rfalNfcaListenDevice nfcaDevList[RFAL_NFC_MAX_DEVICES];
 uart_putstring_buf((uint8_t*)"1");