ST25R3917 doesn't commnicate on the I2C

[TWirt.2061]

ST25R3917 doesn't commnicate on the I2C (Address 0x50) it seems like the chip doesn't start. Maybe a problem with the crystal?

- Drawn current is 50uA

- Signal on MCU_CLK is a 32.5kHz Squarewave

- IRQ line stays low

I assume that the capacitance on the 27.12MHz crystal might be a problem (10p) an has to be lowered. Before changing the capacitance I would like to ask if there might be another reason for the problem.

As far as I understand one should get a high signal on the IRQ line once the chip started correctly. What should be the frequency on the MCU_CLK pin after a cold start and how much current should the device draw if its unconfigured?

[Ulysses HERNIOSUS]

Hi,

register access to the ST25R3917 is possible without (running) oscillator/external crystal.

When software enables the oscillator (en bit) and the I_osc interrupt is not masked the IRQ line will be driven high once the oscillator is deemed stable. Such does not happen automatically.

The 32kHz on MCU_CLK indicates that the internal low power oscillator got enabled.

I would start looking at the I2C protocol - most common is a shift of the address - whether direction bit is included or not.

As reference you will find here a read from ST25R3916 (with address 50h, shown here as 0xA0) from register 02h. I recommend starting with read from register 3Fh (IC identity), where you will need to send 7Fh instead of the shown 42h.

BR, Ulysses

[Ulysses HERNIOSUS]

Hi,

maybe a silly question, so please don't feel offended, but: Did you connect I2C_EN to VDD_D?

BR, Ulysses

[TWirt.2061]

Hello Ulysses,

thank you very much for the fast reply. It's good to know that the external crystal isn't required for the communication. That makes debugging much easier. No worries, I'm not offended by the question about the I2C_EN (I ask those questions a lot when dealing wih customers). And what should I say: The I2C_EN is connected to the 3V3 rail. Typical case of "better check twice and make no assumtions". I maybe burned the first two prototypes but also learned something in the process ;) I will get the botch-wire and a cutter and hopefully get the third board working.

Thanks again!

BTW: It seems like Saleae changed the I2C address interpretation in the new version:

[Ulysses HERNIOSUS]

Hi,

Likely not important for now: Better to connect I2C_EN to VDD_D and not your 3V3 rail. I2C_EN is in the domain of the internal regulator for VDD_D. Connecting it to your 3V3 will likely produce some currents which become visible in power down current.

BR, Ulysses

[TWirt.2061]

I tested the third board with I2C_EN connected to VDD_D instead of 3V3. Unfortunately with the same result. As the waveform used for communication seems correct, we might have a PCB assembly problem. Does the BSS line need to be tight to GND when operating in I2C mode? I couldn't find any information on that.

Is 2.01V a normal reading on the VDD_D (when VDD, VDD_TX, VDD_IO @ 3.3V)?

[Ulysses HERNIOSUS · Accepted solution]

Hi,

BSS tight to GND should not be needed. Also I didn't expect a functional change when connecting I2C_EN to VDD_D instead of 3V3.

A 2V on VDD_D with 3V3 supply seems normal if oscillator is not yet enabled.

Possible checks:

1. Verify Pull-ups on SCL/SDA
2. Check connections into ST25R3916 chip: open SCL and SDA and measure ST25R3917 protection diodes using multimeter (red on GND, black on I2C line).
3. Attach scope and perform signal integrity on I2C lines - not relying on logic analyzer threshold levels.

Best Regards, Ulysses

[TWirt.2061]

Hello Ulysses,

thank you for the good instructions. I solved the problem with the scope. The SDA signal dropped a couple of hundred mV during the ACK phase. Its a bit embarrassing but the GPIO configuration was the problem. I assumed that the alternative function mode will take care of the output configuration in HW and disables the normal IO stages. As this isn't the case it was set to default (push-pull) so the master kept the SDA line high. Simple problem, simple fix but not easy to find on a friday afternoon ;) Thanks again.

Tobi

[Newto]

This post just saved me potentially hours of pulling out my hair. Turns out I forgot pull-ups on my test board for the i2c, so my st25r3916b wouldn't respond. The problem is the DAC that was also on the board *did* respond without the pull-ups, so I wasn't looking at the i2c for problems...

So thank you Tobi for accidentally pointing me in the right direction, and I hope one day this post helps someone else who made the same mistake.