AnsweredAssumed Answered

PN5180 bricked issue without warning

Question asked by andrew stasiak on May 28, 2016
Latest reply on Apr 2, 2018 by Sreedhar Manda


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

Outcomes