Lost Page Write on Ultralight EV1 even after read verify

[eljeffo]

Is there any chance that an Ultralight EV1 chip could lose a write?

Is Read after write from Flash or RAM? (Ultralight EV1)

I have a situation where I use a CLRC663 with the C NFC Reader Library where my writes are not saved to the RFID Chip.

My sequence of operation is as follows:

In a single authenticated session

• Write to Page W [0x00112233]
• Write to Page X [0x00112233]
• Write to Page Y [0x00112233]
• Write to Page Z [0x00112233]
• Read 16 Bytes from Page W through Page Z
• Verify that Page W-Z as read matches the intended bytes written
• No mismatch, write verified and done

Then later when I read the chip, I find that one of the pages does not have the expected value ( I do not know if it is random, corrupted, or reverted)

I have this with about 0.1% of all my chips (among thousands)

Is it possible in theory that I am reading from the Ultralight EV1's RAM, but it is not fully committed to flash because of say... a weak NFC Field?  Or am I guaranteed that all reads only read from committed flash?

[IvanRuiz]

Hello,

Could you please provide more information about your Tag's configuration such as Lock bytes, password protection, whether it is read only, specific addresses where you are trying to write to and read from, command construction and response (if possible a log); please share the same requested information for thread: https://community.nxp.com/thread/521103 to help you with both.

Thank you.

BR,

Ivan.

[eljeffo]

So I have a custom password, but I have already passed the authentication stage.

I know this because I prevent reads of all pages above say 0x08 prior to authentication

No lock bytes active (thanks for asking)

Session 1 (provision)

Access Byte 0x80

Auth0 0x8

Session 2 (write and readback)

Authenticate with PASS/PACK

Write pages 8, 9, A, B (4 bytes at a time, all no errors) (phalMful_Write)

Read Back 8, 9, A B (all no errors) (phalMful_Read)

Session 3 (failure to save detected)

Authenticate with PASS/PACK

Read Back 8 through B (all no errors)  (phalMful_Read)

Read Back does not match target content <- this is the core of my problem

Session 4 (retry write)

Authenticate with PASS/PACK

Write pages 8, 9, A, B (4 bytes at a time, all no errors)

Read Back 8, 9, A B (all no errors)

Session 5 (okay tag isn't broken)

Authenticate with PASS/PACK

Read Back 8, 9, A B (4 bytes at a time, all no errors)

Read Back matches target content

[IvanRuiz]

Hi,

That sounds strange, could you please send us your project?

Thanks,

Ivan.

[eljeffo]

Sure.  What do you need?

[eljeffo]

Sure, we are writing data to a tag to allow people entry into various facilities.  We update their permissions over time as they use, gain or lose permissions. 

Not sure if that has any impact on the function of the tag.

Technically, is it possible to lose a write after reading back the data?  I just don't know the internal data flow of the chip which is why I'm asking.  I'm not sure if I'm reading RAM or FLASH, and not sure whether the NFC Chip itself has any guaranteed architecture.

[IvanRuiz]

Hi,

I do not think that should happen. The write/read operations are made to EEPROM. Have you tried to implement a delay between write and read operation?

BR,

Ivan.

[eljeffo]

I think I mis-read your reply.  Let me try a better reply :smileyhappy:

Okay first, great, we are writing directly to EEPROM.  So that rules out my "RAM fault"idea.

As far as delay between write and read, currently in reference to this:

Session 2 (write and readback)

Authenticate with PASS/PACK

Write pages 8, 9, A, B (4 bytes at a time, all no errors) (phalMful_Write)  <-- here I have no delay

Read Back 8, 9, A B (all no errors) (phalMful_Read) <-- I assume that reading back matching means EEPROM was correctly programmed since there is "NO RAM"

<-- Here I have a few minutes delay between session 2 & 3

Session 3 (failure to save detected)

Authenticate with PASS/PACK

Read Back 8 through B (all no errors)  (phalMful_Read)

Read Back does not match target content <- this is the core of my problem

Do you think that delaying a read back in session 2 would expose a write failure to EEPROM?  Like the readback in session 2 only works because I read the EEPROM quickly before it reverted?