2338871_en-US

[#1]

PN5190B2 over USB CDC/VCOM partially works in fcC00ckpit 8.3.0.0, but still fails with HAL,BUFFER0

Hi NXP team,
I am using a custom board with:
• STM32F411
• PN5190B2
• USB CDC (virtual COM port)
My goal is to make it work with NxpNfcC0ckpit 8.3.0.0 through the legacy VCOM_PN5190 path.
What already works
• USB CDC enumeration is OK
• Cockpit can open the COM port
• Low-level PN5190 SPI/IRQ communication is working
• PN5190 host commands execute correctly
• Some legacy board probe commands already return valid data:
◦ 5E 0A → board FW version
◦ 0E 30 → board EE version
◦ C0 EB → board HW version
What I changed in the bridge firmware
I added compatibility handling for legacy Cockpit commands such as:
• 01 0E FE 02
• 01 0E FF 01
I also adjusted the frontend response behavior:
• stripped the PN5190 leading success status byte from read/query payloads
• reordered GET_VERSION to the NXP reader-library format
• changed immediate 01 05 response to pure ACK with zero payload
• made status-only commands return zero-length FE payload
Current behavior
For GET_VERSION, Cockpit now receives only 4 bytes:
• request payload to PN5190: 7F 27 00 00
• immediate ACK: 01 05 00 00 00 00
• FE fetch response: 01 0E 00 00 04 00 02 03 53 03
For EEPROM read, Cockpit now receives only 1 byte:
• request payload to PN5190: 7F 07 00 04 00 00 01 00
• immediate ACK: 01 05 00 00 00 00
• FE fetch response: 01 0E 00 00 01 00 E4
Remaining problem
Cockpit still reports:
• HAL,BUFFER_OVERFLOW occurred while getting Firmware Version
• HAL,BUFFER_OVERFLOW while reading EEPr0m at 0x0
So the responses are already very small and look valid, but Cockpit still rejects them.
Question
Could NXP please clarify the exact expected legacy VCOM_PN5190 semantics for:
• 01 05
• 01 0E 09
• 01 0E FE 02
• 01 0E FF 01
Especially:
• should 01 05 contain payload or only ACK?
• should 01 0E 09 return raw FE data only, or status + data, or another wrapper?
• what exact payload format does Cockpit expect for PN5190 GET_VERSION and READ_EEPROM over the legacy VCOM bridge?
It seems the remaining issue is not PN5190 communication itself, but an undocumented detail in the old VCOM transaction model.
Thanks.

2. More formal support-ticket version
Subject: Request for official legacy VCOM_PN5190 protocol details for NxpNfcC0ckpit 8.3.0.0
Hello NXP Support,
I am working on a custom board based on:
• STM32F411
• PN5190B2
• USB CDC virtual COM
I am trying to make this board compatible with NxpNfcC0ckpit v8.3.0.0 via the legacy VCOM_PN5190 / UcBal-VC0mBal path.
The low-level PN5190 communication is functional, and Cockpit can open the COM port, but initialization still fails with HAL,BUFFER_OVERFLOW errors. I suspect the remaining issue is in the exact legacy VCOM transaction semantics rather than in the PN5190 host interface itself.
Environment
• Custom hardware: STM32F411 + PN5190B2
• Transport: USB CDC
• Host software: NxpNfcC0ckpit 8.3.0.0
• Operating system: Windows
Current implementation status
The following are already confirmed working:
• USB CDC enumeration
• COM port open by Cockpit
• PN5190 SPI/IRQ communication
• PN5190 host command execution
• legacy board metadata probe responses
Legacy probe commands already handled successfully
The bridge now responds correctly to:
• 5E 0A → board firmware version string
• 0E 30 → board EEPROM version string
• C0 EB → board hardware version string
Firmware-side compatibility changes already implemented
I made the following adjustments in the CDC bridge firmware:
• Added explicit handling for:
◦ 01 0E FE 02
◦ 01 0E FF 01
• Stripped the leading PN5190 success status byte (0x00) from read/query response payloads
• Reordered GET_VERSION payload to match the NXP reader library structure:
◦ [HW][ROM][FW_L][FW_H]
• Changed the immediate 01 05 response to a pure ACK with zero payload
• Suppressed 1-byte fake payloads for status-only PN5190 commands
Remaining Cockpit errors
Cockpit still reports:
• Error HAL,BUFFER_OVERFLOW occurred while getting Firmware Version
• Error HAL,BUFFER_OVERFLOW while reading EEPr0m at 0x0
• sometimes also Input string was not in a correct format.
Relevant transaction examples
1) GET_VERSION
Observed PN5190 request payload:
• 7F 27 00 00
Current bridge behavior:
• immediate response:
◦ 01 05 00 00 00 00
• follow-up FE fetch response:
◦ 01 0E 00 00 04 00 02 03 53 03
So Cockpit receives only 4 bytes of FE payload, but still reports:
• HAL,BUFFER_OVERFLOW occurred while getting Firmware Version
2) READ_EEPROM
Observed PN5190 request payload:
• 7F 07 00 04 00 00 01 00
Current bridge behavior:
• immediate response:
◦ 01 05 00 00 00 00
• follow-up FE fetch response:
◦ 01 0E 00 00 01 00 E4
So Cockpit receives only 1 byte of FE payload, but still reports:
• HAL,BUFFER_OVERFLOW while reading EEPr0m at 0x0
Why this looks like a legacy VCOM protocol mismatch
At this point:
• transport is functional
• payload sizes are very small
• board probe commands work
• status-only commands no longer return stray 00 bytes
• GET_VERSION uses canonical byte order
Because of this, I suspect the remaining incompatibility is in the exact expected behavior of the legacy VCOM bridge, for example:
• how 01 05 is supposed to behave
• what exactly 01 0E 09 should return
• what 01 0E FF 01 is expected to return
• whether an additional wrapper/status byte/length convention is required
• whether Cockpit expects something other than raw PN5190 FE data in the follow-up fetch
Questions for NXP
Could you please clarify the official expected behavior for the legacy VCOM_PN5190 transport used by NxpNfcC0ckpit?
Specifically:
• What are the exact semantics of:
◦ 01 05
◦ 01 0E 09
◦ 01 0E FE 02
◦ 01 0E FF 01
• Should 01 05 return only ACK/status, or also frontend payload?
• Should 01 0E 09 return:
◦ FE data only
◦ FE status + data
◦ or another wrapped structure?
• What exact payload format does Cockpit expect for PN5190:
◦ GET_VERSION
◦ READ_EEPROM
• Is there any public or internal reference firmware/documentation for the older UcBal-VC0mBal / VCOM_PN5190 protocol?