cancel
Showing results for 
Search instead for 
Did you mean: 

ST25R3916 transparent mode details

NV
Associate II

The details on transparent mode are fairly lacking in the datasheet. I've found in another thread a few years ago a comment by Ulysses HERNIOSUS which revealed a bunch of extra info (Transparent mode (similar as in ST25R3911B) allows to have all necessary modulation and demodulated signals available on ins MOSI (modulation), MISO, IRQ (both demodulated), SCLK (receiver enable), MCU_CLK (extracted clock), EXT_LM (field detector) as digital signals. The configuration of the current modulation/demodulation/field detector parameters is done by configuring the registers.) which isn't in the datasheet, but there's still a lot of unknowns.

To pre-empt some questions, I'm using transparent mode mostly for card emulation of otherwise unsupported protocols (like ISO 15693, and hopefully soon also ISO 14443b) so stream and other modes don't help, and I've got dedicated hardware that can operate synchrnously driven by the MCU_CLK to avoid issues with timing.

* When in card emulation + transparent mode I've noticed the MCU_CLK does not appear to use the dividers configured in IoConf1 (Reg Space A / 0x00) register out_cl0/out_cl1 bits and is often 13.56MHz even when configured to be eg 3.39 MHz. Is this expected? Sometimes (when the reader is doing OOK modulation) it appears that the MCU_CLK disappears entirely as well for part of the modulation - it also appears to be absent when first entering transparent mode until it is brought into a field. This could be explained if MCU_CLK is being directly driven by the detected field except that after the external field is removed, MCU_CLK keeps oscillating. Is this configurable? I would have expected the MCU_CLK to be disciplined against the detected field so that it can continue to operate even during OOK modulation by the reader which would explain the continuation of the signal after leaving the field, but the drops of MCU_CLK during modulation would suggest otherwise.

* A lot of the registers are not appliciable in transparent mode for obvious reasons. Is there a list of what registers are and are not valid in transparent mode for both reader and card emulation?

* What does the RxConf3 (Reg Space A / 0x0D) lf_en bit do? While in transparent mode as a reader I've noticed this changes the output on the MISO pin, but there's very little description of what this is actually doing. The only reference I could find is in Figure 7 the receiver block diagram has it pointing to the MUX block.

* How important is the Mode register (Reg Space A / 0x03) om0/om1/om2/om3 bits when in transparent mode? What should they be set to for eg ISO 15693 card emulation use. I'd noticed the RFAL appears to have more definitions for target operating modes than the datasheet suggests which was interesting. Similarly does the tr_am bit (Select RF modulation mode - OOK vs AM) refer to TX or RX modulation, and does this change when in reader vs card emulation mode?

* As per Ulysses HERNIOSUS in the other thread, I discovered the IRQ line is also driven similar to MISO when in transparent mode. That said there appear to be some subtle differences between the two. I'm guessing that one of the two pins is tapped off either before or after some filtering or other steps are performed. Is there any additional info between the two?

* Do the miso_pd1/miso_pd2 bits in IoConf2 (Reg Space A / 0x01) affect the behavoiur of transparent mode? It mentions SPI mode only, but it's not clear if this also affects the signals when entering transparent mode from SPI.

* Finally is there any guidance on setting receive configuration for particular card emulation mode. I've got some working code for ISO 15693 card emulation, but so far it's only working when the reader is using OOK modulation and not when the reader uses 10% AM modulation (ISO 15693 requires cards to support receiving from readers using both types of moudlation). This might be covered earlier with the questions around MISO vs IRQ lines and register configs.

There was some mention of additional internal documentation covering more of the transparent mode, I'd love if this could be cleaned up or even shared privately as-is. The ST25R3916 chip definitely appears to be the most versatile NFC chip that exists (well that and the almost-identical ST25R3916B which I haven't played with yet), but it's usage is currently hindered by a lack of documentation on the transparent mode functionality to build out the features not directly supported in the silicon.

The other thread I've quoted is: https://community.st.com/s/question/0D50X0000BiCmALSQ0

1 ACCEPTED SOLUTION

Accepted Solutions
Ulysses HERNIOSUS
ST Employee

Hi NV,

the documentation containing all the details is confidential and cannot be shared. As the transparent mode was not regarded really a feature for customers we also did not invest in documenting/evaluating it in full depth.

However I think I can share the important bits to your questions:

  1. MCU_CLK in card emulation with transparent mode will have the extracted clock. I cannot offer details on why you see it keeping oscillating (unless you are switching to reader mode (clearing targ))
  2. I cannot offer you a list of registers being valid or not for transparent mode. The principle is that everything concerned with stuff after demodulation is not relevant.
  3. lf_en defines whether the internal RC oscillator (32kHZ) output will be routed to MCU_CLK when Xtal oscillator is not running and the MCU_CLK output is not disabled
  4. Of the bits in Mode register only the targ bit should have an influence
  5. MISO will have the demodulated OOK signal, IRQ will have the ASK demodulation
  6. My expectation is that the miso_pd1/2 don't affect the behavior in transparent mode. Chip is driving.
  7. Important is the "P2P receiver configuration register 1" (space: B Address: 0Bh) it needs to be adapted for the reader coding - both OOK and ASK.

Best Regards, Ulysses

View solution in original post

3 REPLIES 3
Ulysses HERNIOSUS
ST Employee

Hi NV,

the documentation containing all the details is confidential and cannot be shared. As the transparent mode was not regarded really a feature for customers we also did not invest in documenting/evaluating it in full depth.

However I think I can share the important bits to your questions:

  1. MCU_CLK in card emulation with transparent mode will have the extracted clock. I cannot offer details on why you see it keeping oscillating (unless you are switching to reader mode (clearing targ))
  2. I cannot offer you a list of registers being valid or not for transparent mode. The principle is that everything concerned with stuff after demodulation is not relevant.
  3. lf_en defines whether the internal RC oscillator (32kHZ) output will be routed to MCU_CLK when Xtal oscillator is not running and the MCU_CLK output is not disabled
  4. Of the bits in Mode register only the targ bit should have an influence
  5. MISO will have the demodulated OOK signal, IRQ will have the ASK demodulation
  6. My expectation is that the miso_pd1/2 don't affect the behavior in transparent mode. Chip is driving.
  7. Important is the "P2P receiver configuration register 1" (space: B Address: 0Bh) it needs to be adapted for the reader coding - both OOK and ASK.

Best Regards, Ulysses

That's great info, although a couple of clarifications on some of your answers would be great.

  1. With the MCU_CLK, is it expected that this sometimes stops when the reader modulating? I found when the reader was doing OOK modulation the MCU_CLK would sometimes stop oscillating part way through the modulation - are there any other registers that would help here? Or is this a raw carrier signal (which during OOK the carrier goes away entirely) so it'd expected to disappear during reader modulation periods? Are the "en_fd_c*" (external field detection) register bits in the operation control register (space A address 02, bits 0 and 1) relevant for either MCU_CLK or generally at all in transparent mode?
  2. Fair enough, I guess the specifics I was after is around the registers described in "Figure 7. Receiver block diagram", specifically is it accurate in that only the tag_dem register bits (which I assume are the P2P receiver configuration register 1 register bits you described) are relevant when in target mode, while "ch_sel" (and related "rx_chn" and "rx_man" regs?), "amd_sel", "lf_en", "lf_op", "demod_mode", and "rgN_*" register bits are only relevant in reader mode? Aside from this diagram there's no indication if these receive registers affect target vs reader modes.
  3. That sounds more like what the lf_clk_off bit in IO configuration register 1 (Register space A, address 00, bit 0) does. I was asking about lf_en in Receiver configuration register 3 (Register space A, address 0D, bit 1 - and I guess lf_op in bit0 is likely related too). This register bit is referenced in Figure 7. Receiver block diagram - which from the diagram I suspect may only be relevant in reader mode not target mode.
  4. Does this mean tr_am of the mode register isn't used either when modulating in transparent mode?

Hi,

ad 1) I don't know the exact behavior of MCU_CLK in CE. en_fd_c* should not be related.

ad 2) I think your are correct.

ad 3) Sorry, I mixed up lf_clk_off with lf_en. lf_en allows to use an external demodulator on RFI pins.

ad 4) tr_am should not have any effect when modulating as passive target

Regards, Ulysses