SPI Comm Between FRDM-MCX444 and a PN7160 Module

[S_Salam555]

I am attempting to establish SPI communication between the FRDM-MCXC444 and a PN7160 module. At the moment, the PN7160 does not respond over SPI. I have verified the basic hardware connections (SPI signals, IRQ, VEN, and RESET), but the device remains unresponsive.

For firmware reference, I am following the NXP PN7160 NFC Reader firmware example originally provided for LPC microcontrollers, and I am in the process of porting and adapting it to the MCXC444 platform. Despite configuring the SPI peripheral according to the PN7160 documentation, communication is not established.

I suspect the issue may be related to:

• SPI timing or mode configuration differences between LPC and MCXC platforms

• PN7160 VEN / RESET / IRQ handling sequence

• Required delays or power-up initialization specific to PN7160

• Any platform-specific considerations when using PN7160 over SPI

• Correct configuration and adaptation of the tml.c (Transport Mapping Layer) file, particularly SPI initialization parameters, IRQ handling, and low-level read/write implementation for the MCXC444 platform  

I have attached the project I am currently working on for your reference. Any guidance, recommended configuration changes, or reference material specific to PN7160 with MCX-series MCUs would be greatly appreciated.

[S_Salam555]

Hi Celeste_Liu,

Here I provided the attach project.

Best Regards,

Shakir Salam

[Celeste_Liu]

Hello @S_Salam555 ,

Thanks for your reply. About PN7160 VEN / RESET / IRQ handling sequence, please refer to PN7160 hardware design guide.

Please note that in order to prevent PM7160 from being in download mode, please ensure that DWL_REQ does not remain at a high level during power-on reset. It is recommended to pull it down or leave it float (with internal pull-down).

Additionally, I don’t quite understand why the SPI frame requires a leading byte of 0x7F.
As far as I know, the SPI interface on the PN7160 is supposed to directly pass through the NCI frame:

For host write operations: the host simply sends the 3‑byte NCI header + payload.
For host read operations: the host “clocks out” data using dummy bytes (typically 0xFF), without needing any dedicated prefix such as a “0x7F write-command header.”

Could you help clarify the purpose of this 0x7F prefix?
Please also let me know if I have misunderstood anything.
In addition, if you could provide a hardware connection diagram between the MCXC444 and the PN7160, that would be even better.

BR

Celeste

[S_Salam555]

Hello Celeste,

Thank you for your clarification and detailed explanation.

Currently, I am working on the FRDM-MCXW71 project rather than the MCXC444 platform. Regarding the 0x7F prefix in the SPI frame, I was experimenting with a dummy leading byte during debugging. Please feel free to disregard this, as it may not be necessary for PN7160 SPI communication.

I will align with the standard NCI frame format as you described and ensure that the DWL_REQ handling follows the recommended configuration to avoid entering download mode.

Please find attached my current project for the FRDM-MCXW71 with PN7160 for your reference.

Thank you again for your guidance.

Best regards,
Shakir Salam 

[Celeste_Liu]

Hello @S_Salam555 

Thank you for updating me on the current progress of your project. However, the MCXW71 is not a general-purpose MCU and falls outside my support scope. I recommend posting a new thread on Wireless MCU - NXP Community, where engineers dedicated to this product can assist you more effectively. Thank you for your understanding.

BR

Celeste

[Celeste_Liu]

Hello @S_Salam555 ,

Sorry that we’ve only just noticed your post, possibly due to a community system issue. Apologies for keeping you waiting.
May I check how things are going with this issue? Do you still need assistance from us?
Also, I wasn’t able to find the attached project you mentioned. Could you please share it again?

Have a nice day.

BR

Celeste