PN5190 (B0/B1) firmware update using Linux port PHBAL_REG_TYPE_USER_SPI (raspberryPi example)

[jonathanr]

Hi,

We are currently integrating PN5190(B0/B1) into our product.
We had good success with NFCRdLib and the discovery loop demo to show basic functionality. We use the userspace spi BAL mode with the irq_poll kernel module.

We were looking into performing a firmware update for these devices directly using the same integration. We did have a look at SW6592. After a couple of deep dive, it is unclear to us if we can reuse this directly with "simple" porting.

When we compare the code for let's say putting it in Download mode with phhalHw_Pn5190_Instr_SwitchModeDownload from NFCRdLib, we doo see a couple of place where they differ (waiting for IRQ etc.).

So essentially, did we miss the rest of the steps in NFCRdLib or is the expectation to fully port somehow SW6592 from "scratch" (provide phhalHw_Pn5190_Instr_SwitchModeDownload equivalent for all other HDLL commands).

Thing are a bit confusing to be honest and it is unclear how much of an effort this is really. Hopefully we missed something obvious here.

Thanks  

[jonathanr]

So after quite a bit of debugging, looks like the first "read" is done by the "example" irq handler and is thus interfering when in download mode. At least this is progress but I need to make sure things are properly wired up. For now, no need to look into this further since I think I should be able to progress on my side a bit. Will report back if in the end we got to something working or not.

[KaiLi]

Hello @jonathanr 

The standard readerlibrary is different from the library for updating firmware. There is a conflict between the two at the bottom layer, so they need to be integrated and compiled separately.

[jonathanr]

Hi,

Ok. A difference a which level?

I was somewhat able to move forward a bit but I am hitting some weird things.

I ended up porting/implementing `phDlhalHwBalExchange` using `phhalHw_Pn5190_Send` and the receive equivalent (which include the wait on irq based on `phOsal_EventPend/Clear`.
I did this since I saw that the download lib had a defined implementation for PHBAL_REG_TYPE_KERNEL_SPI, leaning me into considering that I might only have to provide an implementation for that specific function (`phDlhalHwBalExchange`) for ` PHBAL_REG_TYPE_USER_SPI`.

From there, I seems to be able to put the device in download mode using `phhalHw_Pn5190_Instr_SwitchModeDownload` from the NfcRdLib, then invoke secure download functions/command.

Looking at what we send and trying out getDieId, getVersion, SoftReset. I think the command (HDLL) do make their way correctly to the reader but looking at the response is leaving me puzzled since they absolutely do not match what we expect. The softreset is the one leading me to think the command do reach the device since after a soft reset command I cannot discuss with the device anymore.

# This is get version
Sending buffer (9 bytes): 7F 00 04 F1 00 00 00 6E EF
Received buffer (13 bytes): FF 00 00 D1 26 FF FF FF FF FF FF FF FF
# ^ The response make little sense. The direction bytes looks good but the header bytes are empty somehow...

#GetDieId func
Sending buffer (9 bytes): 7F 00 04 F4 00 00 00 D2 AA
Received buffer (25 bytes): FF 00 00 0D D0 94 9E BD 38 BD D8 4E 6C 44 31 DB AA FF FF FF FF FF FF FF FF
# The answer is bigger as one would expect from the getID command but again the header bytes make no sense and fail on validation (size).

I will be hooking up a logic analyser today to have a hard look at what exactly reach the device.

So essentially my question here is: is there a difference of implementation between the NfcRdLib and the SecureDowload lib at the `phbalReg_Exchange` (DAL) level?
because I did reuse the DAL implementation from `NfcRdLib` .

[jonathanr]

The sending of a GetDieId command:

The response:

Looks like the device do answer back in multiple packets and the current BAL exchange somehow only surface the second one somehow.

So yeah any pointer as to if the DAL from SecureDownload is different or not would help.

Also any pointer on actually support USER_SPI overall in SecureDownload properly also.