AnsweredAssumed Answered

PN7150 Data Packet Corruption

Question asked by testbed on Jul 28, 2017
Latest reply on Aug 25, 2017 by testbed

I am having two OM5578 PN7150 boards that are are interfaced over I2C to a KW31Z MCU. I have enabled passive P2P mode in the NCI software obtained from the FRDM-NXPNCI example. In my scenario i am transmitting a string to the target, the target jumbles the string and sends it back to the initiator which verifies the jumbled string and prints it if no errors occured. There are two methods that i am evaluating for data transmission. I am NOT using LLCP/NDEF/SNEP. The data is transmitted using the NCI_DATA_MSG format.

 

Method 1 [same as the NXP-NCI example]
1. Wait for discovery.
2. Transmit data from Initiator

3. Wait for response from target and verify response
3. Close and restart discovery.

Repeat

 

Method 2
1. Wait for discovery
2. Transmit data from Initiator

3. Wait for response from target and verify response

4. Transmit data from Initiator

...

...

...

Repeat

 

Method 1 runs without any failures, so no problem there.

 

Method 2 runs fine for sometime after which one error shows up frequently. The packet is shown below

 

[116]: the lazy over The quick jumps fox dog brown
NCI >> 00 00 2b 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e 20 66 6f 78 20 6a 75 6d 70 73 20 6f ...
NCI << 60 06 03 01 00 01
NCI << 00 00 2c 74 68 65 20 6c 61 7a 79 20 6f 76 65 72 20 54 68 65 20 71 75 69 63 6b 20 6a 75 6d ...
[117]: the lazy over The quick jumps fox dog brown << Correct data received
NCI >> 00 00 2b 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e 20 66 6f 78 20 6a 75 6d 70 73 20 6f ...
NCI << 60 06 03 01 00 01
NCI >> 00 00 2b 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e 20 66 6f 78 20 6a 75 6d 70 73 20 6f ...
NCI << 60 06 03 01 00 01
NCI << 00 00 2c 30 d5 07 02 74 68 65 20 6c 61 7a 79 20 6f 76 65 72 20 54 68 65 20 71 75 69 63 6b ...
Error in reception
[118]: 0›”he lazy over The quick jumps fox dog br
NCI << 00 00 2c 74 68 65 20 6c 61 7a 79 20 6f 76 65 72 20 54 68 65 20 71 75 69 63 6b 20 6a 75 6d ...
[119]: the lazy over The quick jumps fox dog brown
NCI >> 00 00 2b 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e 20 66 6f 78 20 6a 75 6d 70 73 20 6f ...
NCI << 60 06 03 01 00 01
NCI << 00 00 2c 74 68 65 20 6c 61 7a 79 20 6f 76 65 72 20 54 68 65 20 71 75 69 63 6b 20 6a 75 6d ...
[120]: the lazy over The quick jumps fox dog brown
NCI >> 00 00 2b 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e 20 66 6f 78 20 6a 75 6d 70 73 20 6f ...
NCI << 60 06 03 01 00 01

 

As shown in the NCI debug messages above. Packet 118 that is transmitted from the Target is getting corrupted.

Byte 0 & Byte 1 of the packet indicate it is a data packet. Byte 3 is the packet length and from Byte 4 onwards there should be the payload as per the NCI format. But there are 4 bytes that are highlighed in red that are in the payload. 0xd5 and 0x7 are always present in the erraneous pcket. Additionally the actual data follows the extra bytes in the data stream as highlighted in orange.

 

Packet 119 and 120 turn out to be fine. But the behaviour indicated by packet 118 frequently occurs at random intervals of time.

 

Now then,  the error bytes 0xd5 and 0x7 are actually part of the Data Exchange Protocol response sent by the target as per NFC-IP 1 table 3. Also this behavior only happens during data transfer from target to initiator and not vice versa.

 

Just want to know if the above understanding is correct. If so, why is the data getting corrupted ? Why those two specific bytes are coming in a data packet. I verified on the target side packet and seen that the target is sending the data packet correctly.

Outcomes