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]

Hi Ulysses,

what are you referring to with "If you continue to use MB1414 from ST25R3916-DISCO, then please also remove the VCCs and change the MLCs to compensate for the removed VCCs. Otherwise you may/will experience unwanted effects on the wake-up system."? Can i find more informations in some documents?

Thank you very much,

Regards

[Ulysses HERNIOSUS]

Hi,

AN5320 section 6 has a bit of information.

If you set aat_en=0 then the control lines for the Varicaps will be floating. Essentially the value of the Varicaps becomes undefined. Not sure how the varicaps settle over time or how they re-settle on wake-up pulses / field-on. This has an effect on the matching and is not stable over time. Our experience is that this adds more noise to the HW wake-up system which you can only compensate by reducing sensitivity of the wake-up system (increasing delta, activate filtering).

If you decide to remove the VCCs then do it in a way that you calculate their capacitance at the default AAT_A/B control voltage (defined in analog configs) and change the other matching capacitors to achieve the same matching.

Regards, Ulysses

[vcaia.1]

Hello,

I work with Marco.

I assume that the the discovery kit works with autotune enabled?

We now power everything via 3V3. We have bad performance (only working at very close distance, a lot of collisions).

The datasheet states that VDD_A will be 3.4V in 5V mode and 3.3V in 3.3V mode, is this a difference big enough to send the varicaps out of tuning range? Or what is the problem you mentioned?

What is an MLC?

If we use double 5V - 3V3 power supply as in the original demo kit, we should get back the same performances of the demo board?

Thanks!

[Ulysses HERNIOSUS]

Hi,

MLC : Multi Layer Ceramic Capacitor. I could have written static capacitor, not introducing a new acronym, sorry for that.

You are reporting collisions, can you please detail what exactly you observe. False wake-ups, false readings, collisions in NFC-A anticollision?

rfalInitialize() calls rfalCalibrate() which will auto-tune the antenna.

The small VDD_A change should not have very visible effects.

I assume you still use aat_en=1?

Can you also describe if you did perform now any changes on the antenna or if you use MB1414-B as is?

What is the current limit on your 3V3 supply?

Regards, Ulysses

[MPeli.1]

Hello,

we detect collisions during NFC-A anticollision. RFAL actually detects that a slave device with nfc-a technology is near, but it stops at collision resolution.

We did not perform any changes to the antenna mb1414-B, we are using it as-is, we just removed the needed components to enable i2c communication.

Currently aat is enabled, as default in rfal libraries.

Current limit is to 500mA on my power supply.

Furthermore, where can i find the configuration file used in the discovery demo firmware preloaded? I am referring to file rfal_analogConfigTbl.h, i can't find it in the downloaded firmware source code.

Thank you very much,

Regards

[Travis Palmer]

Hello,

On the MB1414 boards is a switch (S100) to switch the supply of the ST25R3916 between 5V (USB) and 3.3V.

Doing so, i get the following Voltages when executing the measure amplitude (D3) direct command.

5V: 2.05716V

3.3V: 1.35408V

Reading a Type A tag:

5V: ~12cm

3.3V: ~7cm

This numbers strongly depend on the used tag. But it should give you a feeling about the performance change when switching from 5V to 3.3V.

You should get similar values when externally supplying via 3.3V.

When externally supplying, only VBUS / V_RF should be changed. VDD_IO should kept on the same voltage as the MCU I/O.

Changing from SPI to I2C the following jumper have to be changed:

J200 => close (enable i2c)

J201 => open (disable SPI)

J204 => open (disconnect SPI)

J205 => open (disconnect SPI)

J202 => close (connect i2c)

J203 => close (connect i2c)

Changing from SPI to i2c should not influence the performance.

Please let me know your D3 results.

Do the results vary when executed several times?

What is the i2c speed you are using?

Have you removed the Vccs on that board?

If so you have to change some capacitor values (only valid for MB1414 boards)

e.g. MB1414-B:

C303, C314 (series capacitors) = 150pF

C307, C312 (parallel capacitors) = 200pF (180pF in parallel with 22pF)

MB1414-A

same location different designator.

Please let me know, if this is working for you.

BR Travis

[MPeli.1]

Hello,

i obtain 100 (decimal) when reading with 3,3, that should correspond to 1,2890625V

With 5V i get 171 (decimal), corresponding to 2,204296875.

I calculated thinking of a maximum of 3,3 at 8bit, tell me if i made calculations wrong.

I am currently using 400KhZ clock on SCL, I also tried with 100 KhZ but i didn't notice any difference.

No, varicaps on my board are still there.

If i use file rfal_analog_config_custom_mb1414_b_v1.c, included in discovery demo source files, as analog custom config, should i be ok with the daughterboard connected to only 3,3V (pin 8 of j101 connector), GND (pin 7 of j101 connector) for power and SDA, SCL and IRQ pins (pin 1,2,3 of cn100 connector) to our mcu?

I attach the custom config file for clarity.

Thank you very much,

Regards

[Travis Palmer]

Hello,

1bit corresponds to 13.06mV. 100dec should be equivalent to 1,306V on the RFI pins, 171dec should be 2,23326V. In general these values are good.

Your i2c connection is not entirely clear to me. Below is a schematic of all necessary connections do drive the ST25R3916-DISCO MB1414-B with an external MCU PCB.

All these connections are mandatory for i2c.

Please let me know, if this solves your problem.

BR Travis

[MPeli.1]

Hello,

Yes mine is the same, i just took the i2c and irq, pin 1-2-3 of cn100 connector as for page 26 of the user manual of the discovery board.

Vbus (pin 2 of the image that you linked) was disconnected, but since switch is on 3v3 position it should be ok right?

I tried connecting it to 3v3 but nothing changes.

Thank you very much,

Regards

[Travis Palmer]

Hi,

At which Voltage is your MCU / MCU_IO running?

Is your MCU GND connected with the PSU GND?

Thanks, Travis

[MPeli.1]

Hello Travis,

MCU is runnin at 3,3, and ground of mb1414-b and our MCU is shared and connected to the psu gnd, communications seems to work fine indeed.

Thank you very much,

Regards

[Travis Palmer]

HI,

Does this mean, that the problem has been solved? If yes, what solved the problem?

Or does it mean that the communication is fine, but the problem still exists?

Thanks for your answer!

Br Travis

[MPeli.1]

Hello,

no, the problem is not solved, the communication seems to work fine but the problem still exists.

Thank you very much,

Regards

[Ulysses HERNIOSUS]

Hi,

we are still puzzled why you should experience such issues. It doesn't sound like a software / digital issue, but please provide anyhow:

• A picture of your setup with the card causing these collisions
• A logic analyzer trace of I2C and IRQ pin. We have good experiences with Saleae and Digiview but any should work. I2C dumps as you previously sent are harder to follow and don't give as good timing information and no information on IRQ state.

Regards, Ulysses