Response to 2nd SELECT without RF off in HCE (PN5180)

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Response to 2nd SELECT without RF off in HCE (PN5180)

3,141件の閲覧回数
kwokkei_leung
Contributor I

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.

nexus5_fail.JPG

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.

タグ(4)
5 返答(返信)

2,813件の閲覧回数
a_ivanov
Contributor II

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:Captura.PNG

Thank you

0 件の賞賛
返信

2,304件の閲覧回数
ASKalpa
Contributor II

@a_ivanov 

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). 

ASKalpa_0-1636036676524.png

I always read 0 in the bit RX_IRQ.

How did you solve this?
Thanks,

Alessio

0 件の賞賛
返信

2,931件の閲覧回数
markvanophalven
Contributor I

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

0 件の賞賛
返信

2,931件の閲覧回数
kwokkei_leung
Contributor I

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

2,931件の閲覧回数
markvanophalven
Contributor I

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

0 件の賞賛
返信