Topic: PN532 uart hang up on windows using nfc-emulate-tag example


I'm trying to emulate a nfc tag focosing on the nfc-emulate-tag example that comes with libnfc.
My problem is that this example works fine under linux but hangs up on windows when i press str+c during an active emulation (for example no device scans the tag, but i want to stop the emulation after some time). I'm using a PN532 device connected via usb->serial converter.

I was able to find out what actually hangs:
str+c will trigger the function "intr_hdlr" of the nfc-emulate-tag example, calling "nfc_abort_command", "nfc_close" and "nfc_exit". The "nfc_close"-command leads to a windows API call in the pn532 uart driver: "PurgeComm" -> this is the function that hangs up ( in "uart.c" -> "void uart_flush_input(const serial_port sp)").

As already mentioned this problem only occurs on windows.
Is this a bug?
Can someone help me fix the problem or give a proper workaround?

Re: PN532 uart hang up on windows using nfc-emulate-tag example

I found out that the "nfc_target_init" function blocks because it calls the windows API function "ReadFile" (in "uart.c", "int uart_receive(serial_port sp, uint8_t *pbtRx, const size_t szRx, void *abort_p, int timeout)") whith zero timeout. It seems that "PurgeComm" waits until that read operation finished, which never happens because of the zero timeout. I'm not familar with windows API programming but in my opinion this is a bit strange because PurgeComm uses the flag "PURGE_RXABORT" which should abort any pending read operation.

I was able to implement a quick fix, calling the "ReadFile" - function in a loop repeatly with a small timeout instead of calling it with zero timeout. In this case the "PurgeComm" function will return after a short time and the programm exits.

I have no idea if this can cause any side effects, I also found a very interesting comment in the "uart.c" file:
  // TODO Enhance the reception method
  // - According to MSDN, it could be better to implement nfc_abort_command() mecanism using Cancello()
According to my problem, I think this would not be better but this is neccessary.

Is there a developer here who is able to fix the problem in a "nice" way?