How do I get VHBR modes to work using the Nucleo NFC05A01 board?

[AWall]

I can operate AP2P on the NFC05A01 board using Cube example code at 424kbps and it works well with bidirectional messaging. The data throughput meets my needs but I am looking to improve the latency to <1msec for my application. I only need a high speed unidirectional comms link after establishing the link.

I have ran into two problems:-

1. The AP2P comms in the RFAL code has to be bidirectional and there is a a few milliseconds delay to switch from send to receive. I can't find any way to stop this or reduce the turnaround delay.
2. The VHBR data rates do not work - they appear to be inhibited when selected.

Any ideas to the above would be very welcome.

[Ulysses HERNIOSUS]

Hi AWall,

• ad 1. : RFAL implements protocol according to specs (ISO/NFC Forum). If you really want to use this uni-directional / broadcasting without field switches (without any chance of getting an ACK or something) then you can use for the Initiator part normal reader mode (A106/F212/F424) and for the target side it could be possible to just start a new transceive to re-enable the receiver. Not sure if the state machines will allow - worst case you need to work on register level to issue an UnmaskReceiver command and implement your own routines for reception.
• ad 2.: AP2P is only defined in A106/F212/F424 and the chip only implements these. VHBR works only in reader mode, please see another post in this community for some details.

Best Regards, Ulysses

[AWall]

Hi Ulysses

Thanks for your reply.

I thought the "proprietary" P2P mode would allow baud rates outside the ISO/NFC forum agreed limits. These modes (e.g. F848/VHBR in P2P mode) can be selected but they have been disabled somewhere in the RFAL stack to limit the options to the Forum levels. As I am not doing a Forum compliant application I think the only option will be to change the RFAL code to suit the type of link I need as you suggest.

Kind regards

AWall

[Ulysses HERNIOSUS · Accepted solution]

Hi,

AP2P means both peers are sending reader-style frames (Modulation and coding).

ST25R3911B can only receive reader-style frames in NFC-A 106, NFC-F 212 and NFC-F 424. This is a HW limit of the decoder logic of ST25R3911B.

BR, Ulysses

[AWall]

Hi Ulysses

I am back on this project again. I measured the AP2P comms performance again on the NFC05 @ 424k and the throughput is definitely quick enough when sending 64byte message packets so I can avoid any VHBR requirement. There is a measurable 2mSec delay between each packet. I think this is the time to perform field on/off listen routines for the target and initiator and is part of the NFC P2P standards so shouldn't be removed. However, if I use the NFC06, I should be able to use passive P2P and avoid these delays. If this is correct, how can I use NFC06 AP2P demo program in passive mode as I can't see a way to switch between active or passive P2P comms in the demo program?

[Ulysses HERNIOSUS]

Hi AWall,

doing passive P2P should not be much different from the active one. I would go and change the techs2Find parameter to the passive technologies and then see to start comm again over NFCDEP as already done.

I don't think you will be able to completely remove the 2ms, because also in passive you have guard times of ~500us. With AP2P you have the field switching + guard times which according to standard can even be a bit shorter. Maybe there is some overhead due to performing more actions on SPI and more interrupts being triggered.

Best Regards, Ulysses

[AWall]

Hi Ulysses

Thanks. I can't find any Passive P2P settings inTechs2Find but I think the passive target is actually acting as a FeliCa card (card emulation) so I need to use NFC-F mode for this. I have the had two NFC06 cards communicating in both AP2P and NFC-F modes (poll and listener). The passive P2P link looks like a hybrid of these two. Is this correct or I am I missing something?

Kind regards, AWall

[Ulysses HERNIOSUS]

Hi AWall,

Yes, passive P2P is on lower layer identical to reader to tag communication. When using card emulation in NFC-F you will need to put a SENSF_RES and SC according to NFC forum specs to announce NFCDEP protocol.

Moving from AP2P to PP2P is unfortunately a bit more difficult than just changing the techs2Find. I don't have here practical experience, just know a few caveats. A T3T emulation is the same from lower layers and is ready to use from bluetooth pairing demo. This may be the faster approach to evaluate the throughput of P2P communication.

Regards, Ulysses