PNEV5180B (OM25180FDK) Bricked After Upgrade (two boards)

[christianhack]

I have apparently bricked 2 PNEV5180B V2.0 boards (also known as OM25180FDK).

Brand new boards with a date code of 1624 on the packaging (all three the same although the second board had the jumper set to the ext power position).

After fighting with Windows 10 Pro x64 to get around the unsigned driver issue, I had successfully gotten both boards showing as "LPCBOARD-USB0" and "LPCBOARD-USB2" in Device Manager.

I ran NFC Cockpit 4.0.0 and it asked "Do you want to change Abend to Vcom". I didn't see any documentation about this. I had answered "Yes".

[2017.07.14 11:38:37]:INFO:ServiceFactory:Generating Services for Abend @LPCBOARD-USB0
[2017.07.14 11:38:37]:INFO:EEPROMService_PN5180:Read from EE address:0x14 2bytes. Value=00 90
[2017.07.14 11:38:37]:INFO:EEPROMService_PN5180:Read from EE address:0x12 2bytes. Value=04 03
[2017.07.14 11:38:37]:USER_ALERT:EEPROMService_PN5180:Current Firmware Version: r3.4 is old.
Latest known version is : r3.A
[2017.07.14 11:38:39]:WARN:EEPROMService_PN5180:Current Firmware Version: r3.4 is old.
Latest known version is : r3.A
[2017.07.14 11:38:40]:WARN:ServiceFactory:This version of GUI does not support ARC & LPCD implementaiton of FW Version:3.4 and below.
Please upgrade PN5180 FW to v3.10

This then went through a process where a USB storage device appear with a binary and it mentioned that it upgraded ok :

Success! Drive found, firmware binary file update finished!

Then NXP Cockpit GUI ran and gave the following warning

[2017.07.14 11:42:18]:INFO:BoardConnectionViewModel:Invoking external process to migrate to VCOM
[2017.07.14 11:42:51]:INFO:BoardConnectionViewModel:External process completed. Sleeping for 8s for VCOM FW to boot...
[2017.07.14 11:42:59]:INFO:BoardConnectionViewModel:Refreshing Connected Port List...
[2017.07.14 11:42:59]:INFO:BoardConnectionViewModel:Refreshing Connected Port List...Done.
[2017.07.14 11:42:59]:INFO:ServiceFactory:Generating Services for VCOM_PN5180 @\\.\COM5
[2017.07.14 11:43:00]:INFO:EEPROMService_PN5180:Read from EE address:0x14 2bytes. Value=00 90
[2017.07.14 11:43:00]:INFO:EEPROMService_PN5180:Read from EE address:0x12 2bytes. Value=04 03
[2017.07.14 11:43:00]:USER_ALERT:EEPROMService_PN5180:Current Firmware Version: r3.4 is old.
Latest known version is : r3.A
[2017.07.14 11:43:02]:WARN:EEPROMService_PN5180:Current Firmware Version: r3.4 is old.
Latest known version is : r3.A
[2017.07.14 11:43:03]:WARN:ServiceFactory:This version of GUI does not support ARC & LPCD implementaiton of FW Version:3.4 and below.
Please upgrade PN5180 FW to v3.10
[2017.07.14 11:43:03]:INFO:ServiceFactory:uC FW Version: NNC_uC_VCOM_01.05.00_20170502 (Compiled on May 2 2017 19:38:44)

Above logs are from my third unit whilst reporting this, which I won't upgrade in case it bricks as well.

I pressed the Secure Upgrade button and selected "PN5180Firmware_3.A.sfwu" which was in "C:\nxp\NxpNfcCockpit_v4.0.0.0\firmware\PN5180_SFWU".

When I upgraded the second unit I got this:

[2017.07.14 11:03:59]:INFO:ServiceFactory:uC FW Version: NNC_uC_VCOM_01.05.00_20170502 (Compiled on May  2 2017 19:38:44)

[2017.07.14 11:04:34]:INFO:ServiceFactory:Generating Services for VCOM_PN5180 @\\.\COM5

[2017.07.14 11:04:34]:INFO:EEPROMService_PN5180:Read from EE address:0x14 2bytes. Value=00 90

[2017.07.14 11:04:34]:INFO:EEPROMService_PN5180:Read from EE address:0x12 2bytes. Value=04 03

[2017.07.14 11:04:34]:USER_ALERT:EEPROMService_PN5180:Current Firmware Version: r3.4 is old.

Latest known version is : r3.A

[2017.07.14 11:04:37]:WARN:EEPROMService_PN5180:Current Firmware Version: r3.4 is old.

Latest known version is : r3.A

[2017.07.14 11:04:38]:WARN:ServiceFactory:This version of GUI does not support ARC & LPCD implementaiton of FW Version:3.4 and below.

Please upgrade PN5180 FW to v3.10

[2017.07.14 11:04:38]:INFO:ServiceFactory:uC FW Version: NNC_uC_VCOM_01.05.00_20170502 (Compiled on May  2 2017 19:38:44)

[2017.07.14 11:04:41]:INFO:StatusBarViewModel:Checking for online version status

[2017.07.14 11:04:44]:INFO:StatusBarViewModel:You have the latest version.

[2017.07.14 11:06:02]:INFO:SecureFWUpgradePN5180:Entering download mode

[2017.07.14 11:06:04]:INFO:SecureFWUpgradePN5180:Entered download mode

[2017.07.14 11:06:14]:FATAL_ERROR:UcVcomBalDelegate:Timeout Error while reading from COM5

[2017.07.14 11:06:14]:ERROR:UcVcomBalDelegate:Error while querying PIN_BUSY. GENERIC,USE_CONDITION

[2017.07.14 11:06:15]:FATAL_ERROR:UcVcomBalDelegate:Timeout Error while reading from COM5

[2017.07.14 11:06:15]:ERROR:BoardConnectionViewModel:Secure FW Upgrade Failed. Status=BAL,INCOMPLETE_BYTE

[2017.07.14 11:06:15]:INFO:SecureFWUpgradePN5180:Resetting chip to enter normal mode

[2017.07.14 11:06:16]:FATAL_ERROR:UcVcomBalDelegate:Timeout Error while reading from COM5

[2017.07.14 11:06:18]:FATAL_ERROR:UcVcomBalDelegate:Timeout Error while reading from COM5

[2017.07.14 11:06:19]:FATAL_ERROR:UcVcomBalDelegate:Timeout Error while reading from COM5

[2017.07.14 11:06:19]:INFO:SecureFWUpgradePN5180:Chip reset.

[2017.07.14 11:06:20]:FATAL_ERROR:UcVcomBalDelegate:Timeout Error while reading from COM5

[2017.07.14 11:06:21]:FATAL_ERROR:UcVcomBalDelegate:Timeout Error while reading from COM5

[2017.07.14 11:06:21]:INFO:BoardConnectionViewModel:Secure Firmware Upgrade Operation Finished

So there was some kind of error. The first board didn't have as timeout errors but basically mentioned the Secure Boot Upgrade failed.

After upgrading, both devices no longer provide any kind of USB enumeration and the PC no longer recognises anything. Plug in the third non-upgraded one and it's detected fine as the first two did originally.

If I short SW200 and power up it makes no difference. LD100 (red) and the blue PN_RST LED are on. Pressing ARM RESET results in PN_RST going off and LD200 lighting dimly but still no USB enumeration. Should SW200 bring it back into some kind of recovery mode regardless?

Holding ARM reset and the USB supply current drops to about 1.7mA. Once released it's almost exactly 100mA (using a fairly accurate YZX Studio USB current monitor.

What have I done wrong? The second one did have the time out errors. The first simply said "Generic Error 40" or similar. I didn't take note since I assume I could just retry and it wouldn't have been bricked.

Can I get an older version of NFC Cockpit somewhere so I can at least use my non bricked board in the interim? And how can I recover my other two boards? Should I (or do I need to) get an LPC Link 2 to reprogram them via JTAG?

Thanks

Christian

[cleberdrums]

Hi, I have the same problem your, how you fixed this? I buyed the PN5180A0HN/C1E and the secure firmware update entered but the busy pin dont going a high or low some times and cannot upgrade the firmware and dont work. have some idea i can make for fix this or the chip is scrap?

Thanks

[christianhack]

Sorry, I didn't see a notification to this thread.

Your reply is not clear. Basically saying "it doesn't work" is not enough. I think I have detailed everything that needs to happen. Compile and load the demo application for programming into the LPC1769 and run it. It doesn't wait for IRQs that don't come and so is able to reprogram the PN5180.

[christianhack]

Figured this out finally. Basically if the PN5180 has corrupted firmware, the LPC1769 does not properly initialise and thus the USB interface doesn't work, SW200 doesn't do anything and the standard firmware is basically useless. More detail:

After using the demonstration contained in SW4055 and the demo application “PN5180_LPC1769_SecureFwUpdateLibrary_v01.00.00.zip” I was able to reprogram the PN5180 device via the LPC1769. Output of it displayed on one failed device showed:

Select Option     5

CheckIntegrity func

Function code: 0

Patch code:    0

Patch table:   1

User data:     1

And the other showed:

Select Option     5

CheckIntegrity func

Function code: 1

Patch code:    1

Patch table:   1

User data:     0

The devices still reported the version as 3.10 indicating they had been at least partially successfully upgraded. However it seems if not completely upgraded there is no way of recovering the dev board as the PN5180 won’t boot.

So during the boot process the IRQ line from the PN5180 doesn’t toggle signifying its boot has completed. This appears to have a flow on effect and the LPC1769 does not properly drive CS and has no way of recovering (I think it hangs waiting for IRQ which never comes). SW200 is seemingly ignored or not checked until after this occurs so provides no method of recovery. The DWL line isn’t enough either. This problem can easily be reproduced by holding the PN5180 in reset whilst powering up/resetting the LPC1769. The LPC1769 doesn’t recover and appears mostly dead with no USB device or anything.

Fortunately the demo upgrade application does not appear to get stuck and is able to reprogram completely the PN5180 with an older version (v3.4 – v3.6). Once the PN5180 was properly programmed, the dev board came to life and then successfully (and completely upgraded).

However without the added purchase of the LPC Link 2, it would not have been recoverable at all. Also given my initial upgrade failed (in the logs) I would have hoped it would have been understood that that it would have resulted in an unusable dev board.

I think it’s some what poor that a failed upgrade (for whatever reason) of the PN5180 results in a basically completely broken dev board. That could seemingly be handled very easily by the LPC1769 firmware (and was when reprogrammed with a special version using a special extra cost tool).

[jimmychan]

This may help you.

https://community.nxp.com/docs/DOC-334997 

[christianhack]

Hi Jimmy,

Thanks for that. I was able to successfully reprogram both devices using the LPC Link 2. They both programmed in about the same time as your example with the exact same number of bytes, command line etc. 

However the units still do not appear as any kind of USB device. Tried with USB power and a 9V supply. I've tried multiple separate computers (all Win10 x64 Pro) and obviously two boards doing the same thing.

My third non upgraded board is still recognised no problem immediately when plugged in.