PN532 corrupt data in RS232 mode

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

PN532 corrupt data in RS232 mode

Jump to solution
4,646 Views
dominusdrr
Contributor IV

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.

 

 

0 Kudos
Reply
1 Solution
4,537 Views
dominusdrr
Contributor IV

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.

View solution in original post

0 Kudos
Reply
12 Replies
4,609 Views
dominusdrr
Contributor IV

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.

0 Kudos
Reply
4,627 Views
dominusdrr
Contributor IV

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:

NFC problem.png

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.

0 Kudos
Reply
4,598 Views
Kan_Li
NXP TechSupport
NXP TechSupport

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.
-------------------------------------------------------------------------------

4,583 Views
dominusdrr
Contributor IV

@Kan_Li 
TFI is 0xD5. Why is it wrong?

0 Kudos
Reply
4,549 Views
Kan_Li
NXP TechSupport
NXP TechSupport

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.
-------------------------------------------------------------------------------

4,538 Views
dominusdrr
Contributor IV

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.

0 Kudos
Reply
4,536 Views
dominusdrr
Contributor IV

And those 3 extra bytes make the module behave strangely.

0 Kudos
Reply
4,584 Views
dominusdrr
Contributor IV

Hi

Thanks a lot for answering, it is the module of this image:


imagen_2021-01-05_095340.png

 

They sell it in any electronic store.

0 Kudos
Reply
4,540 Views
dominusdrr
Contributor IV

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.

 

 

imagen_2021-01-06_071327.png

 

 

 

 

0 Kudos
Reply
4,546 Views
Kan_Li
NXP TechSupport
NXP TechSupport

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.
-------------------------------------------------------------------------------

0 Kudos
Reply
4,567 Views
dominusdrr
Contributor IV

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?

0 Kudos
Reply
4,547 Views
Kan_Li
NXP TechSupport
NXP TechSupport

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.

 

pn532 schematics.png

 

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.
-------------------------------------------------------------------------------

0 Kudos
Reply