hi all, hope you can help me due we are out of ideas...
We have a custom board with a PN5190B1HN/C121E (host: CC1352 MCU over SPI). A new production lot of ~100 units shows a ~75% failure rate: the device stops responding on SPI the moment the RF field is switched on for the first time, and only recovers after a VEN reset. Units from the previous lot (prototypes 5 pcs), same design and BOM, work correctly. We have ruled out antenna/matching, TX short, static supply, SYS3V brownout, chip FW and silicon lot with measurements. We are looking for the confirmed root cause, a possible silicon erratum, or an EEPROM/power configuration we may be missing.
Hardware
- NFC frontend: PN5190B1HN/C121E — GetVersion reports HW=0x52, ROM=0x02, FW=0x0201.
- TX supply = internal TX_LDO. VUP_TX (pin 6) = 3.3 V (LDO input). VDDPA (pin 9) = TX_LDO output (decoupled to GND only). VBAT / VBATPWR = 3.3 V. Internal DC-DC not used (no BOOST_LX inductor fitted).
- Main rail SYS3V = 3.3 V from a TPS62840 buck (0.7 A max).
- 27.12 MHz crystal (Murata XRCGB27M120F3M00R0).
- DPC disabled. ULPCD (ultra-low-power card detection) used. VDDPA set to minimum (TX_LDO_VDDPA_HIGH/LOW, EE 0x06/0x07 = 0x00).
- Differential antenna TX1/TX2, EMC filter (L = 160 nH) + matching. Measured resonance ≈ 12.56 MHz (with no final metallic enviroment)(identical on good and bad units).
Symptom (precise characterization)
- Full SPI works before field ON: SWITCH_MODE_NORMAL, GetVersion, GetDieId, EEPROM read/write all return SUCCESS (status 0x0000).
- On the first FieldOn (RF_ON) the host times out waiting for the field-on event. Immediately after, every SPI register read times out (reading CLIF_STATUS, SYSTEM_CONFIG, GetDieId all return a HAL IO timeout). The chip is completely unresponsive on SPI until a VEN reset.
- After a VEN reset the chip is healthy again (GetVersion OK), then FieldOn corrupts it again → endless retry loop.
- No RF field is radiated (NFC test LEDs do not light). Board draws ~20 mA and never returns to low power.
- Good vs bad units are identical in FW (0x0201), DIEID lot, EEPROM config, antenna (VNA) and DC resistances. The only difference is that bad units get corrupted on FieldOn.
- The host MCU stays alive during the hang (the I²C keypad expander keeps responding), so it is specifically the PN5190 that dies, not the whole board.
- Good vs bad current draw is identical up to ~2.7 s; at ~2.7 s the good unit completes and drops to low power, the bad unit stays stuck at ~20 mA.
Ruled out (each with a measurement, not intuition)
| Antenna / matching / tuning | miniVNA on 4 good + 4 bad units → indistinguishable: resonance good 12.565 MHz / bad 12.593 MHz, RL ≈ −9 dB, |Z| ≈ 24.7 Ω, SWR ≈ 2.08 on both |
| TX short / overcurrent | DC resistance TX1–TX2 ≈ 1.2 kΩ, TX1–GND ≈ TX2–GND ≈ 1.15 kΩ, identical good vs bad |
| Static supply leak / decoupling | Current draw identical good vs bad until ~2.7 s |
| SYS3V brownout | Measured stable at 3.3 V; added 47 µF bulk on all 3.3 V rails → no change, still fails |
| Chip FW | Updated a unit to the latest PN5190 firmware → still fails, same behaviour. (Untouched good and bad units both report FW 0x0201.) |
| Silicon lot | DIEID good 00000000 0DD0945E 5B38BDDC 892C0810 vs bad 00000000 0DD095A6 6938BDDC 892C0E64 — same prefix/lot structure |
| TX driver amplitude | Reduced CLIF_SS_TX1/2_RMCFG CW amplitude before FieldOn → no change |
| TX_LDO overcurrent protection | Disabled it via TX_LDO_CONFIG bit 11 (0xAE → 0xA6) → no change |
| TX_LDO output capacitor | Removed VDDPA output caps (4.7 µF + 100 pF) → no change |
EEPROM configuration (identical on good and bad units)
- DCDC_PWR_CONFIG (0x00) = 0x21 (DC-DC off, VUP = VBATPWR, ULPCD enabled)
- TX_LDO_CONFIG (0x02 / 0x03) = 0xA7 / 0xAE (default)
- TX_LDO_VDDPA_HIGH / LOW (0x06 / 0x07) = 0x00 (minimum, ≈ 1.5 V)
- DPC disabled
Questions
- This matches the reported "PN5190 chip corruption during the first start / first RF field ON." Can you confirm the root cause and the definitive fix? (Note: flashing a unit with the latest PN5190 firmware did not resolve it — same failure.)
- Is there a silicon erratum for this lot / date code? We can provide the full DIEID and a photo of the chip marking.
- For our topology (internal TX_LDO, VUP_TX = 3.3 V, VDDPA = LDO output, DC-DC off, DPC off, ULPCD, VDDPA at the minimum 1.5 V): is this configuration valid? Is running VDDPA at the minimum a problem, and what is the correct EEPROM power configuration we should compare against (vs the PNEV5190B)?
- Is there a power-up sequencing requirement (VEN vs supply ramp) that would cause this if violated? Note: vs the previous (working) lot we moved VEN from an I²C expander output to a direct MCU GPIO, and the VEN pull-up is DNP, so VEN floats during host boot.
- With brownout, overcurrent, FW, silicon and antenna all excluded by measurement, what else in the RF_ON path can make the chip stop answering SPI until a VEN reset?
Thanks in advance ,
Ignacio
Hello sir,
There are no published known issues that can cause the RF Fiel ON command to hang the IC.
Could you please clarify whether the issue was resolved on all affected PN5190 devices after updating the firmware and cloning the EEPROM contents? This information would help us better understand the scope of the problem.
If the issue persists on some units, have you had the opportunity to perform an A/B comparison test between a working and a failing device? Such a test could help determine whether the root cause is related to the IC itself or to another element of the system.
Regarding the lot tracking, could you please check with your distributor whether they can provide additional information about the production lot and manufacturing history of the affected components?
The puzzling part: working and failing units have the same firmware version (v2.01), the same silicon revision (B1), the same hardware, the same antenna tuning, and — after cloning — the same EEPROM content. Yet some work and most do not.
Upgrading the PN5190 firmware to v2.0D fixes the failing units. We would like to understand why, and whether there is a known issue in v2.01.
1. Sympton:
On a failing unit:
- Boot and initialization proceed normally.
- At the first RF Field ON, the chip draws no meaningful current, generates no RF field (verified with NFC-powered LED test cards — they do not light up), and stops responding on SPI entirely.
- The host reports IO_TIMEOUT. Soft Reset also fails (it needs an SPI response).
- Only a hardware reset / power cycle recovers the chip. It then works normally until the next RF Field ON, where it hangs again. Fully reproducible.
- Supply rail (3.3 V) stays stable throughout — no brownout.
- On the very first power-up in the life of a board, we observe a one-time ~600 mA event (0.62 A measured with a Nordic PPK2) that never occurs again on subsequent power-ups.
Log from the NFC Cockpit on a failing unit:
INFO:RFProtocolTuningService_PN5190:Load protocol: RM_A_106
INFO:TypeACardViewModel:RM_A_106 Protocol loaded successfully.
INFO:RfFieldControlService:RF On
WARN:ABalDelegate:Waited for PIN_IRQ to go High. Timed out.
ERROR:RfFieldControlService:Error 240,IO_TIMEOUT while during field on.
Log from a working unit, same firmware, same setup:
INFO:RFProtocolTuningService_PN5190:Load protocol: RM_A_106
INFO:TypeACardViewModel:RM_A_106 Protocol loaded successfully.
INFO:RfFieldControlService:RF On
INFO:RfFieldControlService:RF Off
ATQA 04 00 / SAK 0x08 / UID 04 8D 12 33
2. TEST SETUP
To rule out our own host firmware, we connected the production boards directly to a PNEV5190BP used as a USB↔SPI bridge, following the NXP Knowledge Base article “How to connect external PN5190 to PNEV5190BP Evaluation Board” (R5/R7 placed, R6 open; R20 placed; VBAT/VBAT_PWR/VUP jumpers removed; SPI_CLK, SPI_MOSI, SPI_MISO, SPI_CS, NFC_IRQ, NFC_VEN, GND wired to the external board).
- NFC Cockpit v9.0.0
- PNEV5190BP with uC FW NNC_uC_VCOM_04.00.00
- External board powered from a Nordic PPK2 at 3.3 V (allows current measurement)
The failure reproduces identically with the NXP host and NXP software, so it is not caused by our host firmware.
3. What we ruled out (with measurements):
Hypothesis | How it was ruled out |
Supply collapse / brownout | 3.3 V rail measured stable throughout |
Short circuit on TX | DC resistance TX1-TX2, TX1-GND, TX2-GND identical on good and bad units (several kΩ) |
Leakage on PA decoupling | Identical current consumption good vs bad until the field-on moment |
Antenna detuning / matching | VNA measurement, 4 good + 4 bad units — see below |
Physical damage to the IC | The chip recovers with a hardware reset and fails again reproducibly |
Our host firmware | Reproduced with NFC Cockpit + PNEV5190BP |
PN5190 firmware version | Both good and bad units are on v2.01, Hw B1 |
User EEPROM content | Cloned the complete EEPROM of a good unit into a bad unit → still fails |
Difference: ~29 kHz (0.2%), within measurement noise. Confirmed on 8 boards. Antennas are indistinguishable.
4. THE EEPROM COMPARISION - one single byte
We dumped the complete user EEPROM of a good unit and a bad unit, both on FW v2.01, and diffed them.
Out of 648 parameters, exactly one differs:
Region: DPC_SETTINGS
Param: DPC_CONFIG
Offset: 0x76
GOOD unit: 0x77
BAD unit: 0x76
Everything else is byte-identical.
This looked like the answer, especially given the precautionary note in RN00003:
Do not disable the DPC and activate the RF field for ICs connected to antennas matched “Symmetric” (for example, customer development board antenna). Possible damage of the transmitter drivers due to overcurrent over a long period might occur.
Our antenna is symmetric (differential TX1/TX2), and the one-time ~600 mA event on first power-up is consistent with an overcurrent condition.
However, copying the byte does NOT fix the unit
Test | Result |
Write DPC_CONFIG = 0x77 to a bad unit (v2.01), verify readback, power cycle | Still fails |
Load the complete EEPROM dump of a good unit into a bad unit (v2.01), power cycle | Still fails |
Good unit, unmodified, v2.01 | Works perfectly |
So DPC_CONFIG correlates with pass/fail but is not the cause. Whatever the real difference is, it is not in the user EEPROM area.
5. what does fix it: secure firmware upgrade to V2.0D
Performing a Secure Firmware Upgrade with PN5190Firmware_2.0D.esfwu (LEDL folder, legacy download for B0/B1) makes the failing units work:
- Idle: ~33 mA
- RF Field ON: ~240 mA sustained, stable, LEDs light up
- Activate Layer3 returns ATQA 04 00, SAK 0x08, UID 04 8D 12 33
- Verified working afterwards with our own product firmware
Two units recovered this way so far, both fully functional.
Side effect: PwrConfig is overwritten and causes overheating
After the upgrade, EEPROM offset 0x0000 (PwrConfig) changes from 0x21 to 0xE4. With 0xE4:
PwrConfig 0xE4 | PwrConfig 0x21 (restored) | |
Idle current | ~290 mA | ~33 mA |
Die temperature (PMU_TEMP_REG@0x5B) | 100 °C | 40 °C |
290 mA at idle with no RF field, and the internal temperature sensor reading 100 °C (Tj max is 125 °C). We restore PwrConfig to 0x21 after every upgrade.
Is 0xE4 the intended default for PwrConfig in v2.0D? This looks like it could be a problem for other users too.
The 16 EEPROM parameters changed by the upgrade
Parameter | Offset | Before (v2.01) | After (v2.0D) |
PwrConfig | 0x00 | 0x21 | 0xE4 |
DPC_CONFIG | 0x76 | 0x76 | 0x77 |
DPC_GUARD_TIME | 0x87 | 0x64 | 0xFF |
DPLL_CONTROL | 0x2AE | 0x00000C03 | 0x00000C63 |
DpllPhaseRfON | 0x2D2 | 0x012C | 0x00A0 |
DpllPhaseCeA | 0x2D4 | 0x012C | 0x00A0 |
RssiCtrl_00_AB | 0x2DE | 0x09 | 0x0C |
rssi_no_samples | 0x4CA | 0x02 | 0x00 |
polarity | 0x4CC | 0x00 | 0x01 |
LpcdExtDcdcDelayToOn | 0xCE1 | 0x00 | 0x64 |
LpcdExtDcdcDelayToOff | 0xCE2 | 0x00 | 0x64 |
ClifRXFrameLen | 0xCE4 | 0x00000000 | 0x00EF0003 |
RxGuardTO_Multiple | 0xCE8 | 0x00 | 0x01 |
DigitalTBSignalIndex | 0xCE9 | 0x00 | 0x9B |
DigitalTBSignalBit | 0xCEA | 0x00 | 0x04 |
AnalogTBSignal | 0xCEB | 0x00 | 0x78 |
Since cloning a good unit’s complete EEPROM into a bad unit does not fix it, the fix cannot be in these 16 bytes alone — something in the firmware code itself must be involved.
6. Die IDs
All units are Hw B1, FW v2.01 as received:
BAD #1: 00 00 00 00 0D D0 94 5A 5F 38 BD DC 89 2C 04 22
BAD #2: 00 00 00 00 0D D0 95 A6 69 38 BD DC 89 2C 0E 64
BAD #3: 00 00 00 00 0D D0 95 62 5F 38 BD DC 89 2C 08 10
GOOD #1: 00 00 00 00 0D D0 95 0E 5D 38 BD DC 89 2C 08 10
7. Questions
- Is there a known issue in FW v2.01 that can cause RF Field ON to hang the IC with no field generated and no SPI response? We note that DPC_CONFIG as a register was only introduced in v02.03 (per RN00003), and that v02.07→v02.08 and v02.08→v02.09 both contain DPC regulation fixes.
- Why do ~25% of units work and ~75% fail with identical firmware, silicon revision, hardware and EEPROM? Is there anything outside the user EEPROM area (factory trims, internal state) that could differ between units of the same lot?
- Can the Die IDs above be traced to different production lots or wafer batches?
- Is PwrConfig = 0xE4 the intended value after upgrading to v2.0D? It results in ~290 mA idle consumption and 100 °C die temperature on our design.
- Can PN5190 devices be ordered with a specific firmware version pre-programmed? Shipping with v2.01 while the tool itself warns it is obsolete has cost us a full production batch.
- Is upgrading to v2.0D before first power-up the recommended mitigation for the remaining ~80 unused units, to avoid the one-time 600 mA event entirely?
Any guidance appreciated.