Hi,
I am implementing card emulation based on the HCE example in the NXP reader library. Since I am not working on any OS platform, multi-threading is not supported, so I have to port the code on my own and this should be alright since I just need to support the READBINARY command. I test my work with an old Android phone Nexus 5 but cannot get the NDEF message. The communication between Pn5180 and the Nexus5 is OK upon a point after Nexus 5 issue DESELECT and try to activate the card (PN5180) again, PN5180 doesn't response to the SELECT command anymore, until Nexus 5 timeout and reset the RF field. I attached the message capture here.
The above pattern keep repeats.
The functions I called in my program is as below:
do { /* Turn OFF RF field if already on */ phhalHw_FieldOff(...); phhalHw_Autocoll(...); if ((wStatus & PH_ERR_MASK) == PH_ERR_EXT_RF_ERROR) { /* Reset SLEEP_AF state (Respond to WUPA/REQA as field OFF is observed. */ phhalHw_SetConfig(pHal, PHHAL_HW_CONFIG_MFHALTED, PH_OFF); } if ((wStatus & PH_ERR_MASK) == PH_ERR_SUCCESS) { phpalI14443p4mC_Activate(...); if ((wStatus & PH_ERR_MASK) == PH_ERR_SUCCESS) { wStatus = phceT4T_Activate(pT4t_Params); if ((wStatus & PH_ERR_MASK) == PH_ERR_SUCCESS_DESELECTED) { /* Set SLEEP_AF state (Respond only to WupA ("52"), not to * ReqA ("26")), so set MFHalted bit. After this setting is * done "phhalHw_Autocoll" should be called immediately from * Application so that HAL will know if there is any Field * reset in "phhalHw_Autocoll" API and reset this setting. */ phhalHw_SetConfig(pHal, PHHAL_HW_CONFIG_MFHALTED,PH_ON); } } phpalI14443p4mC_ResetProtocol(&pI14443mC_Params); phceT4T_Reset(pT4t_Params); } phOsal_EventClear( (&pT4t_Params)->T4TEventObj.EventHandle, E_OS_EVENT_OPT_NONE, (E_PH_OSAL_EVT_RXDATA_AVAILABLE | E_PH_OSAL_EVT_TXDATA_AVAILABLE | E_PH_OSAL_EVT_ABORT | E_PH_OSAL_EVT_ERROR | E_PH_OSAL_EVT_RTO_TIMEOUT), NULL); } while (!timeout);
It seems to me that after the card (PN5180) is DESELECT for the first time and call phhalHw_Autocoll() again to switch PN5180 into Autocoll mode, it will not response to SELECT from the reader anymore, until the reader reset (RF reset). Is there any register setting, command or EEPROM config to make PN5180 response to SELECT after DESELECT? I have tried comment out the MFHALTED config from the above code but no luck.
Thanks for the help.
Hello,
We are developing a new project using PN5180 in Autocoll mode. In our custom firmware I can comunicate to PN5180 and configure it to be in card Emulation Mode until the reader activates the card.
After receiving the RATS command from the reader, I can transmit ATS and the IRQ_STATUS register confirm that.
The problem is that I never receive the SELCT command wich should be the next one after sending ATS.
I can not find any documentation related with the full functionallity of Autocoll mode.
Can you help me please?
Can you share some example code of how do you comunicate PN5180 with the phone?
Here I describe every step I do until I get this problem:
Thank you
I'm stucked in the same point. I send the ATS and then I check the IRQ register waiting for RX_IRQ (never happened). I debuged the library example and they did exactly the same (but, in their case, they receive something from phone, 0xc2, the deselect command).
I always read 0 in the bit RX_IRQ.
How did you solve this?
Thanks,
Alessio
Hi,
I have the same issue with a Nexus5 and some other android based phones.
I also tested it with Moto G5S and there it works fine.
The difference is that that after the deselect, the Moto G5S does sends again a REQA and not a WUPA.
I also implemented the same behavior using a PN512 and there it works fine both on the Nexus5 and the Moto G5S.
Is this a bug in the PN5180? It seems that the SELECT is not handled by the autocoll state machine in the PN5180.
Any answer from NXP?
greetings,
Mark
Hi Mark,
finally I have sorted out this. The test I did above is on firmware v3.4. I think there is a bug in this firmware that if you use random UID, the internal generated UID is changed after DESELECT therefore the next SELECT command will fail. The solution is either update the firmware to the latest (v4.0 for my case) or not using random UID.
Hope this help.
KK
Hi,
I just tested your solution on a 3.5 version not using the random uid.This works fine now.
I will now implement the upgrade to the 4.0 version and see if this works with the random UID.
I will report this once it's done.
Thank you very much for the support.
Mark