Interrupt pin polarity of NFC reader library

[smiwa]

Hi,

I am now mounting some program built by NFC library (PNEV5180B-LPC1769_NFC-Reader-Library-v4.010) to reader board using PN5180. The datasheet of PN5180 says that the polarity of IRQ PIN can be configured by IRQ_PIN_CONFIG register.

Please let me know which polarity is used and where that setting is performed in the source file in the library ?

Best regards,

   S. Miwa

[smiwa]

Hello, Christian san,

I made it! With your advise and some timing adjustment of NSS, SPI between PN5180 and CPU works well now!

Thank you so much!

Best regards,

   S. Miwa

[smiwa]

Hello, Christian san,

Much thanks for valuable advise!!!

I have never thought that way you tough. I will try it soon tomorrow.

Again, thank you very much. I have really been in at a loss about this problem.

Best regards,

   S. Miwa

[smiwa]

Hi Issac san,

Thanks for your quick reply! Your advise may hit my problem. 

I found its datasheet is revised recently and I noticed "dummy read" now, but I think. It does't matter.

Please tell me more about "dummy read"?

(1) In read operation, do you mean I must send 0xFF when I receive response data from PN5180 after BUSY goes low?

(2) In write operation, it looks no dummy read necessary because PN5180 replies no data. Or do you mean, I must repeat same command/parameter send?

Thank you for your support!

Best regards,

   S. Miwa

[christianeisend]

Hi!

Let me try to give some background on this:

1.) SPI is known to perform full-duplex transfers, i.e. while sending data, also reception of data happens. PN5180, however, uses SPI in half-duplex mode. 

2.) Because PN5180 uses half-duplex mode communication only, at logical communication layer there are two types of instructions: SET instructions (for instance WriteRegister) and GET instructions (for instance ReadRegister)

In order to execute a SET instruction one needs to setup *one* SPI transfer, with Tx buffer containing the SET instruction. At the end of the transfer, data received in the Rx Buffer can be ignored, i.e. contains only dummy data)

In order to execute a GET instruction one needs to setup *two* SPI transfers. The first SPI transfer contains the GET instruction within the Tx buffer. After this first transfer the data received in the RxBuffer can be ignored. Then, the second SPI is used to retrieve the actual response to the GET instruction. For this, one needs to fill the TxBuffer with dummy data. Dummy means, it can be any data. The length of the TxBuffer (=length of the SPI transfer) is equal to the expected length of the GET response. At the end of the second transfer, the RxBuffer then contains the GET instruction response.

So what about the BUSY? BUSY is used on PN5180 as flow control line. A host controller can only start new SPI transfer after PN5180 has finished processing the previous transfer. This is indicated by BUSY signal. So you need to check for BUSY low condition *every* time before your host controller starts a new SPI transfer. The sequence for checking for BUSY low condition has been described by Isaac in his post.

Let me also give an example. Let's assume you want to read out Register 0x0 (SYSTEM_CONFIG) using READ_REGISTER. Since it is a GET instruction it requires two SPI transfers. First SPI transfer contains the instruction within TxBuffer, which is composed of command/instruction code (1Byte) and the address of the Register to be read (1Byte) (See Table 10 in [1]). The second SPI transfer is used to retrieve the response of the GET instruction and has a length of 4 bytes (in fact, the content of the read out register). See also Table 10 in [1]

1. Make sure BUSY is low

2. Assert NSS

3. Perform SPI exchange with length of 2 bytes, with the following TxBuffer content { 0x04, 0x00 }

4. Wait for BUSY high condition

5. De-Assert NSS

6. Wait for BUSY low condition

( RxBuffer of the finished SPI exchange contains two dummy bytes, you can ignore)

7. Make sure BUSY is low

8. Assert NSS

9. Perform SPI exchange with a length of 4 bytes, with the any TxBuffer content { 0xxx, 0xxx, 0xxx, 0xxx }

10. Wait for BUSY high condition

11. De-Assert NSS

12. Wait for BUSY low condition

RxBuffer now contains the 4 byte response, in fact the value of SYSTEM_CONFIG Register

Hope that helps,

Christian.

[1] http://www.nxp.com/documents/data_sheet/PN5180.pdf Rev 3.0

[smiwa]

Hello Isaac san,

Thanks a lot for your good information! My question is clearly solved. 

As I think you know the detail well,could you help me for another question? My question is about NSS signal. 

Which control is correct?

  (1)  NSS: low --> send CMD/Parameter --> NSS:high after checking Busy high --> NSS low after checking Busy low to get reply from PN5180--> read Rxbuffer --> NSS high 

  (2)  NSS: low --> send CMD/Parameter --> NSS: keep low even after  Busy high --> NSS high after read Rxbuffer

I am using our own SPI driver in accordance with PN 5180 datasheet but I have not reply yet. PN5180 busy goes high after NSS assertion and sending CMD/Params but no response data replied...

I appreciate your supports!

Best regards,

   S. Miwa

[isaacavila]

Hello,

According to section 11.4.1 Physical Host Interface from PN5180's reference manual, BUSY line is used to indicate that system is BUSY and cannot receive any data from a host. Recommnedations for the BUSY line handling by the host are:

1. Assert NSS to Low
2. Perform Data exchange
3. Wait until BUSY is high
4. Deassert NSS
5. Wait until BUSY is low

In this case, NSS will be low -> send CMD/Parameter -> Wait until busy is high (NSS will stay in low until busy is high) -> NSS will be set to high (busy line was already set to high) -> finally, wait until busy line is low.

Remember that in order to write data or read data from PN5180, "dummy reads" shall be perfomed. (You can check Figures 6, 7 and 8 on same 11.4.1 section.)

I hope this helps!

Regards,

Isaac

[isaacavila]

Hello,

This polarity settings is not configured on library (it is left as default) but we can identify which polarity is used and how this can be changed.

Polarity can be obtained from how LPC1769 is configured. If you checked the Set_Interrupt function at phHwConfig_Lpc1769.c file, you will notice that P2.12 is configured to generate an interrupt on Rising edge:

    /* Enable receiving interrupt on the pin */
    GPIO_IntCmd(2, PIN_IRQ, 0);‍‍

So, polarity is configured to be high (IRQ pin will stay in low (idle) and will generate an IRQ when it goes to high).

If you want to change this setting, you should write to EEPROM's address 0x1A where IRQ_PIN_CONFIG information is stored:

PH_CHECK_SUCCESS_FCT(statusTmp,  phhalHw_Pn5180_Instr_WriteE2Prom(pDataParams, 0x1A, 0xXX, 1));‍

Just be sure that in case that if IRQ's clear method is changed, you will need to change it in application as well, for all examples, it is configured that all interrupts are cleared by accessing to IRQ_SET_CLEAR register (so bit 1 in IRQ_PIN_CONFIG address of EEPROM is set to 0) and in case that you change this bit 1 to 1, interrupt will be cleared automatically after reading the IRQ_STATUS register.

I hope this can help you!

REgards,

Isaac