usage of the PN5180 causes reset of the microcontroller

[jensboettcher]

hello community,

i have a problem to use the PN5180. the situation is that i have developed a custom board with a microcontroller, the PN5180 and a pcb-antenna. when i put it into operation the microcontroller resets several times. my first guess was an influence of the electromagnetic field. so i put the different parts in spatially separated locations. the microcontroller gets his own supply and the tranceiver with antenna gets his own supply too. only the data signals (MISO, MOSI, SCK, NSS, BUSY and RESET) and GND are connected from the microcontroller to the tranceiver. to avoid conducted faults every line gets a 5 MHz low pass filter and the GND between filter and tranceiver gets a choke. the SPI speed is 1 Mbps. the filter works fine.

the antenne has a distance of 36 cm and the tranceiver of 30 cm to the microcontroller.

when i read and write registers or the eeprom everything is fine, but when i take the field on the microcontroller restarts. the field strength is on the lowest power level, i only use one gear. after a couple of restarts the microcontroller starts the provided operation. the actual operation is to read out the uid of ISO15693 and ISO14443A transponders and send it over a com port (UART) to the pc. but when the provided operation is active and i put a transponder in the field, the controller begins to restart again. in other applications with tranceiver-chips of other manufacturer the microcontroller works fine, even in the middle of the pcb-antenna. the problem only exist with a matched antenna nearly 50 ohm. with other antennas (i tried a 400 ohm antenna for example) theres no restart but with this antenna the tranceiver couldn't read out a transponder. the same result with no antenna connected. there's no considerable field strength measurable close to the microcontroller in the spatially separated setup. i try the same with the evaluation board (PNEV5180B V2.0) an the supplied antenna instead of my tranceiver board and antenna, but the same result.

when i put another matched antenna close to the antenna of the tranceiver the microcontroller stops to restart but in this situation i can't read transponders too.

my own suspicion is, that the tranceiver trys to get to much power over the data lines and so the maximum current of the supported current of the microcontroller is exceeded. is there a similar case known?

at the moment i do not know what to change that the test setup works.

more data:

tranceiver: line a: PN5180A; line b1: HHW731; line b2: Z.1 04; line c: NSD602C

antenna: pcb, 1 winding per layer, 2 layers, 65x40 mm, SWR at 13.56 MHz: 1.14; Z = 45 + j9 Ohm, |Z| = 45 Ohm; range (with other tranceiver with std. TAGs): nearly 10 cm.

thanks for help

jens boettcher

[nandyala_narend]

HI, jens boettcher

                                 Please i have some problem with STM32f103 while interfacing with PN5180.

Could you please initial interfacing and starting procedure with stm32f103+PN580 SPI programing?

Thanks,

Narender 

[harinath_reddy]

Hello NXP Community, We are seeing same reset issue with PN5180 and Atmel SAM4S4B micro-controller using SPI interface. We tried looking at PN5180 register 0x13 response and no luck. Still seeing the reset. Any recommendations from community on what's going on? 

Thanks,

[jensboettcher]

happy new year everyone,

i try to extract the minimum number of commands that are necessary to get this failure. perhaps someone can carry out this test setup. before the while(1) starts i send a teststring with the actual software version on rs232 to check the start and the restart of the Microcontroller as well the PN5180 is reset. in the while(1) the following commands are used (in pseudocode):

1. SSEL = 0 (means LOW)
2. LOAD_RF_CONFIG(0x0D, 0x8D)     // ISO15693
3. SSEL = 1
4. wait while BUSY is HIGH
5. SSEL = 0
6. RF_ON(0x00)
7. SSEL = 1
8. wait while BUSY is HIGH
9. SSEL = 0
10. WRITE_REGISTER(0x0F, 0x00000000)     // TIMER1_CONFIG
11. SSEL = 1
12. wait while BUSY is HIGH
13. SSEL = 0
14. WRITE_REGISTER(0x0C, 0x57250000)     //TIMER1_RELOAD
15. SSEL = 1
16. wait while BUSY is HIGH
17. SSEL = 0
18. WRITE_REG_WITH_AND_MSK(0x00, 0xF8FFFFFF)     // SYSTEM_CONFIG (Idle/Stop Com)
19. SSEL = 1
20. wait while BUSY is HIGH
21. SSEL = 0
22. WRITE_REG_WITH_OR_MSK(0x00, 0x03000000)     // SYSTEM_CONFIG (tranceive command)
23. SSEL = 1
24. wait while BUSY is HIGH
25. SSEL = 0
26. WRITE_REGISTER(0x0F, 0x01081000)     // TIMER1_CONFIG (Enable Timer1)
27. SSEL = 1
28. wait while BUSY is HIGH
29. SSEL = 0
30. SEND_DATA_RF(0x00, 0x36, 0x01, 0x00, 0x00)     // Send data to TAG
31. SSEL = 1
32. wait while BUSY is HIGH
33. wait 10 ms
34. wait while BUSY is HIGH
35. SSEL = 0
36. READ_REGISTER(0x13)     // Read RX_STATUS
37. SSEL = 1
38. wait while BUSY is HIGH
39. SSEL = 0
40. read data from Register 0x13 (4 Bytes)
41. SSEL = 1
42. wait while BUSY is HIGH
43. if the read data is 0, go to state 53 (RF_OFF)
44. else SSEL = 0
45. READ_DATA(0x00)
46. SSEL = 1
47. wait while BUSY is HIGH
48. SSEL = 0
49. Read data in length of data in Register 0x13 (fomat reg. 0x13: LSB->MSB)
50. SSEL = 1
51. UID = Read data
52. wait while BUSY is HIGH
53. SSEL = 0
54. RF_OFF(0x00)
55. SSEL = 1
56. wait while BUSY is HIGH
57. if UID is exist: send UID via rs232 and wait 1 s, than start again with case 1
58. if UID not exist: wait 60 ms, than start again with case 1

if i not use the lines 34 to 51 and jump direct from 33 to 52, no restart occures. and that is the point i don't understand. the only difference is that the data in register 0x13 and the read data (cmd 0x0A) are not used.

any ideas?

[jensboettcher]

i've got an update to the description above. after the examination of the datatransaction between case 34 to 51 i found out that every time the microcontroller resets, the RX_PROTOCOL_ERROR flag in Register 0x13 is set. so i think i found the trigger, but there's no explanation why this event can reset the microcontroller.

after changing the software, that when detect this error the next state is 53, no restart can provoke in my test setup.

[jensboettcher]

could it be that the wrong usage of commands causes this reaction?

i can't use the supported NFC Reader Library because the used microcontroller is not supported, so i write my own programm just use the datasheet and the NFC Cockpit. i found no program schedule, so i orientate on the sequence of commands that the NFC Cockpit sends to the PN5180 to read out the UID of a card/TAG. but with this method i don't know the bits, registers or timings are right in every situation.

[leonhardkormann]

Hello!

Did you observe the restart of the uC also when you only switch on the RF field?

Each modulation (esp. 100% modulation like ISO14443A 106) can generate a current spike on TVDD input pin. Did you consider a strong enough cap on the TVDD input? Is the LDO (or DCDC) strong enough to drive TVDD? What is the typical current flowing through the TVDD?

On SPI lines there is no current drawn

kind regards

leonhard  

[jensboettcher]

hello leonhard,

no, i can't observe a restart of the uC when i only switch on the RF field.

on my custom board is a 100nF ceramic capacitor directly on the TVDD pin. on the eval. board is a cascade of 100uF + 100nF in series to a 22nH choke and a second cascade of some uF (i cant' read it on the schematic of the board [AN11741]) + 100nF. until now I have assumed that the eval. board has a workable equipment. in the test setup the TVDD is directly driven from the laboratory power supply (in this case a Manson HCS-3302 switching mode supply, 1-30 VDC, up to 15 A) wich is limited to 1A. the supply voltage is 5 VDC. the typical current flowing through TVDD is <= 1mA when RF is off and 190mA when RF is on.

The uC is driven with a USB-AC Adapter (5V, 2A), so that the spikes on TVDD should not influence the power supply of the uC. for the future use it is scheduled that the whole board is driven with a USB-AC Adapter or a USB Port that support 1A or more.

i try to draw the situation in a block diagram:

thanks for help and merry christmas

jens boettcher

[Kan_Li]

Hi Jens Boettcher,

Did the voltage on your MCU board change when this issue occur? Please kindly help to clarify. Thanks for your patience!

Have a great day!

Kan

[jensboettcher]

hello kan,

no, theres no changing in the supply voltage measurable. i try to find out if a brown-out is happen. the microcontroller has two supply voltages, one for the core and one for the periphery. when the core voltage fall under a range of 1.9 ... 2.2 V a brown out is triggered. when i trigger on a falling edge on a voltage level of 2.3 V this event never happend, only when i put off the hole supply voltage. the same i try with the 3.3 V supply for the periphery with a trigger on 3.2 V, but no event too.

even with the field on, theres no ripple shown on the supply. the blue one (CH2) is the peripheral supply (3.3 V), the yellow (CH1) is the core supply (2.5 V) and the violett (CH3) is the measured field of the antenna. the gnd is measured on the gnd-area of the microcontroller and the supply voltages are measured as close as possible to the microcontroller pins. this measuring is from the test setup.

i found no suspicious condition near the microcontroller in the supply voltage.

i found out that the reset not so often occurs when the microcontroller only search for ISO15693 TAGs. but in this situation a random reset can provoke when i spin or wobble the TAG in the electromagnetic field (per hand). when i lie the TAG on a cardboard over the antenna no reset occurs and the UID of the TAG can read out without problems.

thanks for help

Jens Boettcher