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.
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.
1 ACCEPTED SOLUTION
Accepted Solutions
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.
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.
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.
