How to reset the M24LR04E Discovery Board that comes with the M24LR Discovery Kit to starting conditions?

[DRich.1]

My M24LR04E Discovery Board is not showing up when using the CR95HF Development Software's "Auto Detect tool" or the "Vicinity Tags - NDEF Message user interface" tool. In these tools the tag just doesnt show up as seen when you scan for tags. In the "Tag Detection tool" however, the tool is shown (however this isnt very usefull, it only shows that its a ISO15693 tag). The M24LR04E Board itself still has the functionalities to show the voltage of the field or to show the temperature sensor output. The NDEF message however reads:

"NOT A NDEF TEXT MESSAGE"

How this (probably) happened:

I was playing around with the discovery board for my internship, to get to know NFC. I have installed the CR95HF Development Software that goes along with the M24LR04E Discovery Kit.

When playing around with the Vicinity Tags - NDEF Message user interface, I could read and write away NDEF messages to the M24LR04E Discovery Board.

After that I opened this program: the ISO15693 User Interface M24LR04E. Here I started playing around (my fault, I didnt know really what I was doing). I think I may have overwritten data here that wrecked the functionality of the M24LR04E Discovery Board, or locked something with the sector password stuff. Honestly Im not sure what I did.

Is there any way to fix this/reset the M24LR04E Discovery Board to starting conditions? I cannot seem to fix this or find a way to reset the board.

[Brian TIDAL]

Hi,

you probably have erased/modified the tag memory content.

You can dump the tag memory content and check the NDEF Capability Container in first block. It should be E1 40 40 01

You can restore the NDEF in the following way:

In NFC Type 5 - NDEF message user interface,

• use READ WRITE CC FILE and write the following content: E1 40 40 01
• use PREPARE NDEF and add a Text (e.g. FIELD ON)
• use WRITE NDEF and write the text record to the tag

The M24LR-discovery should now display FIELD ON

I would recommend you to use the ST25PC-NFC software with the CR95HF RF transceiver demonstration board rather than the legacy CR95HF development software.

Rgds

BT

[DRich.1]

Hi,

Thank you for your response. I have followed your steps. Althought it did not fix all problems, it did solve some as the tag is now detected again in the auto detect tiik, I put the log output below:

09-26-2019 08:51:16   INVENTORY

         >>> CR95HFDLL_SENDRECEIVE, 260100

         <<< 800D00FF866E866CE15902E0178300

09-26-2019 08:51:16   Inventory : UID = E00259E16C866E86

09-26-2019 08:51:16   WRITE Block 0 with DATA :

         >>> CR95HFDLL_SENDRECEIVE, 022100E1404001

         <<< 800501120C2500

09-26-2019 08:51:20   TEXT record added

09-26-2019 08:51:23   INVENTORY

         >>> CR95HFDLL_SENDRECEIVE, 260100

         <<< 800D00FF866E866CE15902E0178300

09-26-2019 08:51:23   Inventory : UID = E00259E16C866E86

09-26-2019 08:51:23   READ CC : Block 0

         >>> CR95HFDLL_SENDRECEIVE, 022000

         <<< 80050115B35100

09-26-2019 08:51:23   !!! TAG NOT CONFIGURED (MAGIC NUMBER NOT FOUND IN CC FILE)

I am sorry for not being able to give more data, I do not know that much yet about working with NFC (still in the learning process!). I havent dumped the tag memory content or checked the NDEF Capability Container in first block since I dont know how. I also couldnt find any information on it on the internet or in the datasheet of the CR95HF develop software.

I thank you for your help and advice

[DRich.1]

For clarification: The screen doesnt show FIELD ON as when I executed your 3rd step:

"use WRITE NDEF and write the text record to the tag"

I got the output:

09-26-2019 09:07:38   INVENTORY

         >>> CR95HFDLL_SENDRECEIVE, 260100

         <<< 800D00FF866E866CE15902E0178300

09-26-2019 09:07:38   Inventory : UID = E00259E16C866E86

09-26-2019 09:07:38   READ CC : Block 0

         >>> CR95HFDLL_SENDRECEIVE, 022000

         <<< 80050115B35100

09-26-2019 09:07:38   !!! TAG NOT CONFIGURED (MAGIC NUMBER NOT FOUND IN CC FILE)

How can I fix this?

[Brian TIDAL]

Hi,

It seems the CC in block 0 is not correct. Can you try to rewrite the block0 with the proper values E1 40 40 01 and then read the block 0 to check that its value is correct?

Rgds

BT

P. S.: I would suggest you use the ST25PC-NFC software and rewrite the NDEF and then dump the memory content.

[DRich.1]

10-10-2019 13:13:32   INVENTORY

         >>> CR95HFDLL_SENDRECEIVE, 260100

         <<< 800D00FF866E866CE15902E0178300

10-10-2019 13:13:32   Inventory : UID = E00259E16C866E86

10-10-2019 13:13:32   WRITE Block 0 with DATA :

         >>> CR95HFDLL_SENDRECEIVE, 022100E1404001

         <<< 800501120C2500

10-10-2019 13:13:33   INVENTORY

         >>> CR95HFDLL_SENDRECEIVE, 260100

         <<< 800D00FF866E866CE15902E0178300

10-10-2019 13:13:33   Inventory : UID = E00259E16C866E86

10-10-2019 13:13:33   READ CC FILE : Block 0

         >>> CR95HFDLL_SENDRECEIVE, 022000

         <<< 80050115B35100

10-10-2019 13:13:33   !!! TAG NOT CONFIGURED (MAGIC NUMBER OT FOUND)

---------------

This is the output that I get when following your steps:

Step 1: Write CC file block0 (bit0: support Multiple Block commands) with values E1 40 40 01

Step 2: Read CC File block0 (selected bit0: support multiple block commands)

Still the magic number not found error

When trying to use the ST25PC-NFC software, I tried to write text NDEf data. When trying to write the data, I have to give a password. I do not have a password. Maybe I have accidently set up a password? How do I remove the password or reset the tag?

[JL. Lebon]

​Hello,

Has suggested by Brian, your CCFile is probably corrupted.

Here is the value of memory inside the M24LR04E discovery board "out of the box":

You can check the content of your memory's tag using the CR95HF GUI:

• go in ISO15693->DYNAMIC NFC TAGS->M24LR04E
• then in the User Mode tab, select addresses from 000 to 00F and click on "Read Single Block"

You should now see the content of your tag's memory.

CCFile is the first 4 bytes of the memory at address 00. Then comes the NDEF file, terminated by "FE"

You can restore the content of the tag's memory by two ways: using the ISO15693->DYNAMIC NFC TAGS->M24LR04E interface and directly write correct values in the memory, or use the ISO15693->NDEF Management->Vincinity Tags - NDEF Message user interface to directly write CCfiel and NDEF message.

If using the ISO15693->DYNAMIC NFC TAGS->M24LR04E interface, you will need to send 'Write Single Block" commands with correct data and correct addresses in memory.

If using ISO15693->NDEF Management->Vincinity Tags - NDEF Message user interface , you need first to "INITIALIZE YOUR VINCINITY TAG". This will write the CCFile. Just put the correct value in "Data memory size in bytes/8", which is here 40, and click the button.

Then you can write the NDEF message itself: select the "text" button, write your message, and clock on Write NDEF message.

Please note that the firmware inside the STM8 on the M24LR04E discovery board (the red board) is able to decode and display only text type NDEF message. if you write an NDEF containing other type, it will not display it.

IF it is still not working, you can check the content of your memory's tag again using the Read Single Block command. You can also check the log of the "Vincinity Tags - NDEF Message user Interface" tool to check that all commands have been correctly acknowledged and didn't respond any error (for exemple, if you have locked the memory sector where the CCFile is written, it respond you an error when trying to write CCFile).

Best regards.

[JL. Lebon]

​Hello

Looking at the log, it looks like your the sector 0 of your tag is locked in read and in write. Which explain that you can't read/write a CCFile.

In the answer to the write block command to block 0, the answer is:  800501120C2500. 8005 is the code returned by the CR95HF. The 01120C25 is the response from the M24LR (0C25 is the CRC).  The first byte of the response of M24LR is 01h, which means "error". The second byte is the error code 12h, which is "block locked".

In the answer to the read block command to block 0, the answer is: 80050115B35100. 8005 is the code returned by the CR95HF. The 0115B351is the response from the M24LR (B351 is the CRC). The first byte of the response of M24LR is 01h, which means "error". The second byte is the error code 15h, which is "block is read-protected".

So it looks like that your tag have the block 0 (and all the first sector) locked in write and in read.

You can check which password is protecting the sector and which read/write protection is used by reading the Block Security Status byte of the block 0. To do this, you have to send a "et Multiple Block Security Status" command of block 0. The tag will then answer you with the Block security status:

• command to send: 022C0000
• response will be: 8005 00xxYYYY 00 with xx the Block security status and YYYY the CRC

The block security status is like this:

With the security status, you can know which password is protecting your sector. 00 in password control bits means you cannot unlock the sector with any password, so I hope you will not have this value.

By default, passwords in the tag are all set to value 00000000.

Best regards.