M24sr64-Y Tag Lockup issues

[Luke Iliffe]

I have a few thousand units using these tags in the field and have found that under some condition that I'm yet to replicate in the office the tags seem to be able to get into a state where they are unable to be interacted with by either an app (I've tried our own,the ST25 app and taginfo from NXP) whilst the host MCU is held in reset. Also I have found that they don't even detect the tag.

Likewise the first thing that the MCU does on bootup is a M24SR_ReleaseSession() command which fails with a NACK from the M24SR. All subsequent comms also fail. The only way that I have found of rescuing the chip is to power the M24SR off and then power it on again after a delay.

has anyone else found this at all and anyone got any ideas as to how to try rescuing them apart from the power option?

[JP Miller]

​Dear customer,

M24SR64 has an arbitration scheme between the RF master and the I2C master for accessing its resources. This arbitration relies on a session mechanism where either the RF master or the I2C master is granted the access to M24SR64 resources (1 access token is available to M24SR and can be granted to either the RF master or the I2C master. While the session is running for one master, it is not possible for the other master to have access to M24SR64 in general (please note the I2C master can force its access to M24SR64 if desired when an RF session is going on).

In the particular case you are describing it is possible that the session was not properly terminated by either the RF master or the I2C master.

The RF master can either terminate its session by shutting down the RF power, or Deselect the M24SR (see section 6.3 Close an RFsession of the datasheet)

The I2C master needs to terminate its session with a I2C token release sequence as explained in the datasheet section 7.4 I²C token release sequence. The proper timing requirements must be met.

Hoping this will help you resolve the issue.

Have a good day.

[Luke Iliffe]

Hi JP thanks for the fast responce.

In my setup what happens when the phone is removed without doing a properly terminated by the RF master but with 3.3V supplied permenatly? As it stands I have a board with no phone near it and I'm unable to do the I2C token release sequence as it just gets NACKed and when that happens the I2C periferal immediatly sends its stop bit and i'm not sure how to stop it from doing so so any ideas from that, I'm using the M24SR_I2CTokenRelease() function that came with the M24SR library. This works with other units and does the appropriate 40ms delay as long as it recieves the ACK.

Thanks for your time

Luke

[JP Miller · Accepted solution]

Dear Customer,

The fact it works except on a few units is puzzling.

the I2C token release sequence is useful when the I2C master was accessing the M24SR, and it has concluded its transfer with M24SR. The I2C token release sequence will then enable the phone to have access to M24SR. So it needs to be applied right at the end of the needed I2C transfer between the I2C master and M24SR.

​One thing to try possibly to see if the M24SR comes out of this situation on that particular unit is to perform a KillRFsession command and repeat it till it works, then perform the I2C token release sequence and try with the phone.

if the VCC (3.3V) can be switched off in your application, it might be worth trying to switch if off after the I2C transfer, and on again to start a new one.

Regards,