Reference data not usable error when trying to set read password

[Luke Iliffe]

I have code running on a few thousand units in the field and on the whole they work perfectly, however I'm seeing this problem in a few of the packs and wondered if anyone had seen it themselves or know what causes it or even better what i need to do to stop it occuring.

I don't know what causes the problem but at some point the App we have designed is no longer able to access the NDEF record to read its data. When we get the units back and do a restart the problem doesn't go away. The restart process sets the both read and write passwords and enables them and the only failure in this process is that I get  0x69 0x84 ( Reference data not usable) back from the M24SR when trying to enable the read password. The phone cannot read it with the password i have given it, with a password of just 0's or no password so its like the m24sr has got itself into an unknown state. At no point during this entire process is the M24SR power cycled.

the code is as follows

if(M24SR_Verify( I2C_PWD ,0x10 ,pCurrentWritePassword ) == M24SR_PWD_CORRECT) 

{

/* Set new password */

M24SR_ChangeReferenceData ( READ_PWD, pNewPassword );

M24SR_EnableVerificationRequirement( READ_PWD );

status = SUCCESS;

}

what i find odd is that the write password has no issue and does the same process

/* check we have the good password */

if (M24SR_Verify( I2C_PWD ,0x10 ,pCurrentWritePassword )== M24SR_PWD_CORRECT)

{

/* Set new password */

M24SR_ChangeReferenceData ( WRITE_PWD, pNewPassword );

M24SR_EnableVerificationRequirement( WRITE_PWD );

status = SUCCESS;

}

so anybody got any ideas and also if you need more info then let me know

Thanks

Luke

[JP Miller]

​Dear Luke,

The isolated procedures for changing passwords and enabling them are correct and are expected to work.

It would be helpful if you could read out the Capability Container and let us know what it is.

On this type of commands, 0x69 0x84 is usually returned if the file being accessed is permanently locked. We would know with the Capability Container.

Could you please also specify which exact command & parameters is returning 0x69 84 as Status Word?

It might be worth to double check the File with FileID=0x0001 has been properly selected just before doing the modification of the read password.

I would recommend just after the M24SR_ChangeRefereceData for the READ_PWD to do a M24SR_Verify( READ_PWD ,0x10 ,pCurrentReadPassword ) and check the Status Word response is 0x90 00 to ensure the Read Password has been correctly written into M24SR.

And on the units not behaving as expected, would it be possible to check if a M24SR_Verify( READ_PWD ,0x10 ,previousPassword ) returns 0x90 00 if you know what the previous password was, to know if the password update occurred properly or not

Looking forward to your response.

Have a good day.

Regards,

[Luke Iliffe · Accepted solution]

Hi JP,

I found the issue once looking at the CC container data. The protection was in WRITE_ONLY state and was easily switched back to normal and is now working. What is odd however is that I never use the M24SR_EnableWriteOnly() function anywhere in the code and have never done so also the units that have failed have previously been working so I'm not sure whats happening but at least I can resolve this issue by checking for it now.

Thank you very much for your help

Luke