PN5190 GPIO3

[ignacioS]

hi all,

hope you can help me. We are using PN5190B and we are trying to measure the consumption at ULPCD. Unfortunatly we are in a 2mA value so we are trying to find were is the mistake. We are not sure yet if it is hardware or firmware.

But what we are seeing is that GPIO3 , that is managed by an expander (pin set as input) , is when we set ULPCD in high but with each polling it goes a bit low (goes to around 2volts...). Looks that PN5190 is pushing it to low in each polling, Is that normal? 

thanks!

ignacio

[EduardoZamora]

Hello @ignacioS

Hope you are doing well.

Are you performing this test with the PN5190 Development Board, or is it with your custom board? Where is the current being measured?

Are you using NFC Cockpit to configure ULPCD mode? What is the procedure you are following?

Also, please test ULPCD with GPIO3 disconnected from the expander and left as a clean signal and let me know your findings.

Regards,
Eduardo.

[ignacioS]

Hello Eduardo,

Thank you for your reply, and apologies for my delayed response as we are currently quite busy with this topic.

The testing is being done directly on the final product. I already received the prototypes, and all development and validation is now being carried out on them.

The initial setup consists of a host directly controlling the SPI of the PN5190B and an I/O expander handling the VEN and GPIO3 lines. This approach comes from the fact that this is a modification of an already existing product, and I no longer had free GPIOs available on the microcontroller, so I was forced to use two GPIOs from an expander.

The issue is that we are unable to achieve the very low current consumption specified for ULPCD mode. This is the schematic I currently have around the PN5190B:

 Tests I have performed:

• I disconnected the VEN and GPIO3 lines from the expander and connected them directly to the microcontroller. In this configuration, when entering ULPCD mode, the system consumes around 2.8 mA. At this point, I tried different pin configurations (input/output/high/low, etc.), keeping the pins configured as SPI as well as completely disabling SPI. No success. The minimum current consumption I get is still around 2.8 mA, or even higher.
• I desoldered pull-up resistors R52 (VEN), R53 (GPIO3), and R38 (Chip Select) at different stages and in different combinations, but the behavior remains exactly the same, still consuming around 2.8 mA.
• With this last hardware configuration (pins connected directly to the microcontroller and without the pull-ups), if I send the Standby command, I do obtain a current consumption of around 50 µA, which matches quite well with the 45 µA specified by NXP plus around 5 µA from my own circuitry.

These are the instructions we are using to enter ULPCD mode, which, based on what I see on the evaluation board, should be correct unless I am mistaken.

Do you have any idea what I could be doing wrong? Any help would be greatly appreciated, as I cannot proceed with manufacturing the first pre-series until this issue is resolved.

Thank you very much in advance.

Best regards,
Ignacio

[EduardoZamora]

Hi,

Could you please confirm that you have configured the corresponding EEPROM settings (DCDC and ULPCD) properly? Please refer to PN5190 design-in recommendations, Section 4.3; and PN5190 Data Sheet, Section 9.15.3.

Regards,
Eduardo.

[ignacioS]

Thanks Eduardo for your support. Yes, we checked your recommendations and we were already following them. I think we have found the issues that were affecting us.

On one hand, it was related to the SPI. We were leaving the SPI channel configured in the same way as we did during the Standby test, and apparently the PN5190 does not like that very much. Completely closing/disabling the SPI is what finally allowed us to reduce the consumption.

In addition to that, instead of connecting the VEN and GPIO3 pins to the expander, I connected them directly to the microcontroller for the test, without external pull-ups, configuring VEN as Output High and GPIO3 as Input Pull-up (with GPIO3 on the PN5190 configured so that ULPCD mode aborts if it detects LOW).

With this setup (polling every 500 ms) I now have a current consumption of around 25 µA, which is fantastic.

However, this is on the setup I assembled on my bench. After analyzing my product and thinking about the next phase, I see two possible options:

1. (My preferred option) Connect VEN directly to the microcontroller (Output High) and not use GPIO3 at all. In practice, with other transceivers I have never needed to wake them up while they were polling, so I do not really see what GPIO3 would be useful for. And if I ever needed to exit ULPCD mode, I could simply reset it through VEN.

On this version of the hardware I have done several tests, but I cannot get back down to 25 µA — I am staying around 70 µA.

I would like to ask two things:

• Is there any risk in leaving the VEN line without an external pull-up and keeping it configured as Output High?
• If I do not use the NXP GPIO3 and I am not going to connect it to the microcontroller, how should I leave it? Should I add a pull-up? Leave it floating? Any special configuration required?

2. Connect VEN to the microcontroller (Output High) and also connect GPIO3 (Input Pull-up). This will make the layout more complicated, but if it is necessary to achieve low consumption, then we will do it.

So, is it essential to have GPIO3 connected to something?

Thanks again for your help. I am already very close to considering this finished.

[EduardoZamora]

Hi,

For VEN pin, it can be directly managed by the Host.

When using ULPCD, GPIO3 abort is available by default and cannot be used for other purpose. Leaving GPIO3 floating may cause some false wake-up in some cases.

If GPIO3 will not be controlled by your Host, please consider adding a pull-up/pull-down resistor depending on your abort polarity configuration (refer to PN5190 Data Sheet,9.2.166).

Regards,
Eduardo.

[ignacioS]

hi, sorry, intructions were not paste on previous post:

Initialize the chip
pn5190_ulpcd_calibrate(&g_lpcdRefValue);
phhalHw_FieldOff(&hal);
pn5190_ulpcd_wait_for_card(g_lpcdRefValue, 200);

static phStatus_t pn5190_ulpcd_calibrate(uint32_t *pRefVal)
{
phStatus_t status;

status = phhalHw_Pn5190_Instr_LPCD_SetConfig(&hal,
PHHAL_HW_CONFIG_SET_LPCD_WAKEUPTIME_MS,
330U);
if ((status & PH_ERR_MASK) != PH_ERR_SUCCESS) return status;

status = phhalHw_Pn5190_Instr_LPCD_SetConfig(&hal,
PHHAL_HW_CONFIG_LPCD_MODE,
PHHAL_HW_PN5190_LPCD_MODE_DEFAULT);
if ((status & PH_ERR_MASK) != PH_ERR_SUCCESS) return status;

status = phhalHw_Pn5190_Instr_LPCD_SetConfig(&hal,
PHHAL_HW_CONFIG_LPCD_CONFIG,
PHHAL_HW_PN5190_LPCD_CTRL_ULPCD_CALIB);
if ((status & PH_ERR_MASK) != PH_ERR_SUCCESS) return status;

status = phhalHw_Lpcd(&hal);
if ((status & PH_ERR_MASK) != PH_ERR_SUCCESS) return status;

return phhalHw_Pn5190_Instr_LPCD_GetConfig(&hal,
PHHAL_HW_CONFIG_LPCD_REF_VAL,
pRefVal);
}

static phStatus_t pn5190_ulpcd_wait_for_card(uint32_t refVal, uint16_t wakeupMs)
{
phStatus_t status;

status = phhalHw_Pn5190_Instr_LPCD_SetConfig(&hal,
PHHAL_HW_CONFIG_SET_LPCD_WAKEUPTIME_MS,
wakeupMs);
if ((status & PH_ERR_MASK) != PH_ERR_SUCCESS) return status;

status = phhalHw_Pn5190_Instr_LPCD_SetConfig(&hal,
PHHAL_HW_CONFIG_LPCD_MODE,
PHHAL_HW_PN5190_LPCD_MODE_POWERDOWN);
if ((status & PH_ERR_MASK) != PH_ERR_SUCCESS) return status;

status = phhalHw_Pn5190_Instr_LPCD_SetConfig(&hal,
PHHAL_HW_CONFIG_LPCD_CONFIG,
PHHAL_HW_PN5190_LPCD_CTRL_ULPCD);
if ((status & PH_ERR_MASK) != PH_ERR_SUCCESS) return status;

status = phhalHw_Pn5190_Instr_LPCD_SetConfig(&hal,
PHHAL_HW_CONFIG_LPCD_REF_VAL,
refVal);
if ((status & PH_ERR_MASK) != PH_ERR_SUCCESS) return status;

return phhalHw_Lpcd(&hal);
}