PN5180 bricked issue without warning

[andrewstasiak]

Hello,

This question is regarding the PN5180 chip. I recently purchased a batch of these for implementation into our new device and have had difficulties in acquiring documentation specific to the SPI protocol. The difficulty was centered around ambiguity with the NSS and BUSY pin in the main datasheet. After some trial and error I succeeded in writing a seemingly functional library that could read and write to registers and eeprom, and also perform general commands.  It worked quite well for a short time until I began serious testing with the RF field, at which point I found that certain values written to the TX config register (0x21) could cause the chip to lock and required reboot (Even though RF field was off). After a few cycles of this type of 'rebooting' the chip began to refuse to send any data even after reset/power down. It would otherwise behave as expected in asserting IRQ on power up, and enabling the pull-down on MISO line, and even asserting the Busy pin in between data transmissions as is normally expected - but all the data returned was 0x00. The MISO pin was put on a scope and analyzer and would never be asserted.

Has anybody else experienced this? If so does anyone have a work-around for resetting them?

I will be first to admit that It is possible that the library was incorrect, and values were written to incorrect locations however it is my understanding that even if this is the case it should not be possible to have a chip unresponsive after a power cycle, otherwise the device can be bricked permanently.

Now as you can probably imagine, I do not dare continue to test any of the other chips in fear that they will also be bricked. Furthermore we cannot release these devices to our client if they have the potential for lock up and so we must be certain that this will not happen in the field, but as of yet there has been no response from NXP technical, and information online is limited. At this point I am not sure what to do. If anyone can help I would be eternally grateful.

Cheers

andy

[janulo]

Hi,

did you find the reason of BUSY signal staying high?

I have the same issue, sometimes BUSY signal stays high infinitely, only power-cycle fixes this. No brick yet.

I am reading classic, plus and desfire cards without problem, only sometimes this BUSY problem occurs.

I am using NXP Reader Library on STM32L4 MPU and with FreeRTOS.

Jan

[christianeisend]

Hi,

BUSY staying high sounds like a "violation" of flow control. BUSY is used on PN5180 as flow-control line, i.e. in order to ensure that host controller doesn't send a new frame before previously received frame which has been processed. Not waiting for BUSY going low again before sending another frame eventually leads to a kind of buffer overflow within PN5180. This is a hard constraint on PN5180 and the IC can't autonomously recover. One you follow the recommendation for sending SPI frames to PN5180 this BUSY lock-up should never happen.

Please refer to this thread, where correct sequence for SPI transfers on PN5180 is described:

https://community.nxp.com/thread/437631#comment-848483 

HTH,

Christian.

[sreedharmanda]

Hi,

Thank you for the valuable information given in this thread.

I am using PN5180 reader IC interfaced with customized other host controller board.

I am able to access registers and EEPROM via SPI interface by following the correct sequence given in this thread.

Using NXP reader library with LPCD disable (build option).

Successfully executed the library flow upto phacDiscLoop_Sw_Int_FieldOn() --> phhalHw_FieldOn()

(Note: Loaded default protocol settings available in PN5180 EEPROM using phhalHw_ApplyProtocolSettings() which is executed as part of reader library flow)  

The problem is BUSY line is always HIGH after RF_ON command issued as part of phhalHw_FieldOn() code flow.

Please suggest your valuable suggestions on this issue.

Thanks in advance.

Best Regards

Sreedhar

[leonhardkormann]

Hi all,

Did you ensure to respect the BUSY timing. As long as BUSY line is high any communication on SPI is not allowed and can cause that SPI data is getting misinterpreted.

BUSY line is getting high after the first byte on SPI is received, and is getting back after a certain time when NSS is getting deasserted

[elliotrevell-na]

Hi Leonhard

My SPI write went like this:

chip select

send buffer

wait for BUSY line to be high

chip deselect 

wait for BUSY line to be low (I had a timeout on this wait of 25ms)

The board I was working with now just has the BUSY line always high it seems.

[leonhardkormann]

Hi,

This is OK, do you have a SPI trace? From your description it seems everything is OK

Does it happen at the first write access? Is the board still functional?

kind regards

leonhard

[elliotrevell-na]

No the board is not still functional.

As I said the board I was developing with just has the BUSY line always high so I am not able to send anything to it anymore.

I was able to write and read registers by spi using this method and occasionally my 25ms timeout would expire and the board would need a power cycle to get the busy line to go low again.

Then the board just had the busy line high continuously.

[elliotrevell-na]

WriteRegisterAndMask(IRQ_ENABLE, ~IRQ_SET_CLEAR_IDLE_IRQ_CLR_MASK))

WriteRegister(IRQ_SET_CLEAR, PHHAL_HW_PN5180_IRQ_SET_CLEAR_ALL_MASK))

ReadRegister(IRQ_STATUS, &reg))

These macros are taken from the NXP nfclibrary

[elliotrevell-na]

The hardware is our custom board which is based on the reference designs in NXP documentation and an ARM cortex.

We are looking at migrating to the PN5180 in a product which we have been using MFRC522 in for a long time.

The software that I was developing was pretty minimal and it was based on the documentation about the SPI protocol (in PN5180 v2.2 document) and the NFCReaderLibrary source (v4.010.00.001602_R1).

I had the following seemingly working:

     Reading and writing of PN5180 registers

     Reading eeprom but I didn't write eeprom

     Loading rf config

     Turning on and off RF field

     Sending WUPA and getting ATQA from cards

I was running my SPI at 2M.

The steps of my testing were:

     Attach scope to SPI lines and a test line that was reflecting the state of BUSY line in my SPI layer

     Read registers

     Write and read back registers

     Turn on and off the RF field

     Send WUPA repeatedly, checked with proxmark

     Send WUPA repeatedly with card in field, checked with proxmark

This is as far as I got before it totally stopped working.

To investigate this problem I tried reducing interaction with the chip to just my init of it and not doing any of the RF stuff

     WriteRegisterAndMask(IRQ_ENABLE, ~IRQ_SET_CLEAR_IDLE_IRQ_CLR_MASK))

     WriteRegister(IRQ_SET_CLEAR, PHHAL_HW_PN5180_IRQ_SET_CLEAR_ALL_MASK))

     ReadRegister(IRQ_STATUS, &reg))

By watching the SPI lines I saw this sequence seemed to be able to fail on each of the steps.

The BUSY line seemed to not go low when I thought it should.

Do you need any more information?

Cheers

[jimmychan]

from your steps, would you tell me what was written to the registers?

Read Registers

Write and read back Registers

[jimmychan]

thanks for your reply, I will forward this to our expert team.

[elliotrevell-na]

Hi

It seems like I have just had this problem too or something very similar :smileysad:

I was successfully reading eeprom and reading/writing registers on this chip based on the information in the datasheet (rev 2.2).

I was starting to get some 14443a functionality going from reading through the NXP library and was experiencing the chip stopping responding to SPI sometimes, requiring a power cycle to get it going again.

Then it stopped coming back to a working state after power cycles and now I can't get it to do anything useful.

It seems like the busy line just stays high indefinitely.

Like Andy, I have a few other boards that I can develop with but I am pretty worried that I am just going to end up bricking them all like this so I will probably put development with this chip on hold for now.

There are some differences between what I observed and what Andy did:

- I did not notice any particular link to writing values to tx config register and it locking up.

  My init function was doing the same disable idle irq, clear all interrupts steps that I made out from the library.

  I then read the IRQ status register. I saw this lock up happen on all 3 of these steps (the busy line seemed to stay high).

- I never saw any pull-down on the MISO line (I did not change any eeprom values)

  I thought that the MISO line was not pulled down by default so did you set this in eeprom Andy?

- The busy line does not seem to be working and seemed to just stay high each time that the chip stopped responding.

  Once the chip stopped coming back with power cycles, the busy line seemed to be only high.

I had been scoping the SPI and busy line during development and what I saw seemed to match up with my understanding from the datasheet.

Any help would be greatly appreciated.

Cheers

Elliot

[jimmychan]

our expert need more detail information to investigate your problem. Would you tell me what software and hardware are you using? and the steps of your test?

[jimmychan]

I will ask our expert for this issue.