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.
Hello,
Is there a chance you can share your project with us? You can do it here o through a case, please let me know.
best Regards,
Estephania
Hi Estephania,
Yes, i can share the code. Please let me know how to share it privately/through a case...
Regards
- Rishi
Hello,
Please enter to the NXP support page (Support|NXP) and there will be an option for support request.
You can find more information on the process here: How to submit a new question for NXP Support
Best Regards,
Estephania
Hi Estephania,
I only have the Keil project. It will work on the 32K limited version of Keil IDE also with J-Link selected as the debugger in the debug configuration. I have not used the run-time environment of Keil for configuration. You can open and compile the project as is in the attachments. You might have to upload the 24_OpenSDA_FRDM-KW41Z.bin bootloader just in case it fails to work with your boards.
Regards
- Rishi
Hello,
I'm currently working on your case, as there are no development boards for the KW31 I will be using the KW41Z instead.
Best Regards,
Estephania