NFCのトピックLost Page Write on Ultralight EV1 even after read verify

Lost Page Write on Ultralight EV1 even after read verify

eljeffo — Thu, 26 Dec 2019 10:51:38 GMT

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?

Re: Lost Page Write on Ultralight EV1 even after read verify

IvanRuiz — Fri, 03 Jan 2020 22:36:41 GMT

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.

Re: Lost Page Write on Ultralight EV1 even after read verify

eljeffo — Tue, 14 Jan 2020 10:17:41 GMT

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

Re: Lost Page Write on Ultralight EV1 even after read verify

IvanRuiz — Sat, 18 Jan 2020 00:02:06 GMT

Hi,

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

Thanks,

Ivan.

Re: Lost Page Write on Ultralight EV1 even after read verify

eljeffo — Mon, 27 Jan 2020 09:36:13 GMT

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.

Re: Lost Page Write on Ultralight EV1 even after read verify

IvanRuiz — Wed, 29 Jan 2020 17:15:39 GMT

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.

Re: Lost Page Write on Ultralight EV1 even after read verify

eljeffo — Mon, 24 Feb 2020 00:29:12 GMT

Sure. What do you need?

Re: Lost Page Write on Ultralight EV1 even after read verify

eljeffo — Sat, 14 Mar 2020 18:34:10 GMT

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?