Hi.
I have managed to communicate via RS232 (HSU 115200 bps)with the PN532 NFC RFID Module board and a microcontroller.
I'm reading a MIFARE ISO14443A tag, but the last bytes that correspond to the id (4 bytes) of the card come from different values, that is to say altered and the true value rarely arrives.
To avoid erroneous data being processor, I enabled the checking of the DCS byte and the last byte of Postamble and almost all the frames arrive altered.
I agree that in RS232 communication errors are likely to be common, but in this case it is too much.
The distance between the microcontroller and the board is 18 cm. Do you think that is the problem?
As I mentioned before the problem is in the last bytes.
Any suggestions and comments are welcome.
Solved! Go to Solution.
Hi.
I think I already found out what the error is.
I connected Vcc to 5V and the problem was the same.
So I decided to connect the NFC module to a PC COM port and send the same frames, and it works very well, the module has no problems.
Then I reconnected the logic analyzer, to see what the microcontroller sends to the PN532 on this occasion and I discovered that it sends more bytes than it should, for example the frame to read the tag should be like this:
{00} {00} {FF} {04} {FC} {D4} {4A} {01} {00} {E1} {00}
But it was actually sending this:
{00} {00} {FF} {04} {FC} {D4} {4A} {01} {00} {E1} {00} {00} {00} {00}
It is a problem with the microcontroller that although I disabled the interrupt by transmission in the last byte, it still transmitted 3 more bytes.
By means of an auxiliary flag I have controlled the sending of bytes is correct and the module responds correctly.
Hi, I'm still looking for the solution.
I thought there was possibly a defect in the module, so I bought a new one, but the result is the same.
I also used a logic analyzer to check if there was no misinterpretation of the data returned by the PN532, but the frame is correct as in the image I attached above.
I think I have to open a technical thread.
Hi.
I have read in document 141520 (PN532 User Manual) that when the frame has an error of some kind, a NACK must be sent to the module so that it returns the next frame again.
But the problem is that the DCS byte is always wrong, and there is only the problem when I read the RFIF tag, for the other frames to configure the module there is no problem.
Here is an image of the frames received from the PN532:
The first column on the left in the first reception that contains the ACK frame plus the information frame.
The next two are those obtained after sending the NACK to the PN532.
The sum of the bytes that are enclosed in the orange rectangle must be equal to zero, otherwise the DCS byte is incorrect.
The sum is 0xC9.
And whenever I resend the NACK, it always returns the same frame.
Hi @dominusdrr ,
Not only DCS byte but also TFI byte is wrong, and the check sum is always wrong in above cases, so I think most likely it is a hardware design issue, which module do you have? Where did you buy from?
Have a great day,
Kan
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
@Kan_Li
TFI is 0xD5. Why is it wrong?
Hi @dominusdrr ,
Sorry for the confusion! I mean PD0 indeed, it is the command code but it should not be 0x14 in the response data.
Have a great day,
Kan
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi.
I think I already found out what the error is.
I connected Vcc to 5V and the problem was the same.
So I decided to connect the NFC module to a PC COM port and send the same frames, and it works very well, the module has no problems.
Then I reconnected the logic analyzer, to see what the microcontroller sends to the PN532 on this occasion and I discovered that it sends more bytes than it should, for example the frame to read the tag should be like this:
{00} {00} {FF} {04} {FC} {D4} {4A} {01} {00} {E1} {00}
But it was actually sending this:
{00} {00} {FF} {04} {FC} {D4} {4A} {01} {00} {E1} {00} {00} {00} {00}
It is a problem with the microcontroller that although I disabled the interrupt by transmission in the last byte, it still transmitted 3 more bytes.
By means of an auxiliary flag I have controlled the sending of bytes is correct and the module responds correctly.
And those 3 extra bytes make the module behave strangely.
Hi
Thanks a lot for answering, it is the module of this image:
They sell it in any electronic store.
This is the schematic of the module, it seems that Vcc should be 5V. I'm going to use that voltage level to see what happens.
Hi @dominusdrr ,
Actually I have no idea of this module, did you order it from your local Disty? For example, https://www.digikey.com/en/products/filter/evaluation-boards-expansion-boards-daughter-cards/797?s=N... .
Have a great day,
Kan
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi supposedly the module can work with voltages of 3.3V and 5V.
I'm applying 3.3V to the Vcc terminal.
Checking the schematic of the module and the datasheet, the main power pin is VBAT which supposedly can work from 2.7V, in theory there would be no problem, but for other pins that need 3.3V, the internal regulator of the chip is being used.
If I used 3.3V in VBAT, it implies that the internal regulator would not work properly and would be delivering voltages less than 3.3V.
Could that be the problem?
Hi @dominusdrr ,
The host interface's ref voltage is PVDD, not VBAT, which is the input of the internal LDO. so you have to check if the voltage on PVDD pin meets the spec of the host controller, in other words, better use the same power supply for PVDD and the host controller. Please kindly refer to the following for more details.
Have a great day,
Kan
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------