wakeup/init issue of pn532_uart

[Peter Meerwald]

Hello,

my pn532_uart device would work only after the second device open/init after plugging in (it is the Adafruit breakout board connected with FTDI cable);
so the first nfc-list would fail, the second succeed...

turns out some sleep/delay was missing in the wakeup routine, pn532_uart_wakeup()

the comments
/* High Speed Unit (HSU) wake up consist to send 0x55 and wait a "long" delay for PN532 being wakeup. */
indicates that there should be some delay/sleep, so add it

without the msleep() my PN532 consistently fails to be detected/claimed after being plugged in, it is detected the second time trying to open the device, though

with the delay, it is always detected

please see the patches (#1 - #4 cleanup, #5 fix) here
https://groups.google.com/forum/#!topic/libnfc-issues/UyYMkG5nQJo

thanks, regards, p.

[Marcello Morena]

Hello,
I run in this bug too, without knowing you had the same issue. Since I saw that my device where recognized only one time out of two, and only with "allow_intrusive_scan" set to true, I started to investigate this bug. This is what I found out.
Libnfc puts PN532 in PowerDown mode when it ends its operations and sends "0x55 0x55 0x00 0x00 0x00" to wake PN532 up when it needs to operate again. Unluckly this is not enough to wake it up on some devices: infact the PN532 Manual says to send a "large preamble" to PN532 or to send a 0x55 byte and "wait a long delay" in order to wake it up. It seems that sending 5 bytes as a preamble is not long enough, so PN532 fails to be recognized on the first try because it doesn't wake up. But on the first try, with "allow_intrusive_scan" set to true, a lot of data is sent to PN532, so it's awake when one try to use it on second try. When the operations executed on second try end, libnfc put PN532 in PowerDown mode, so on the subsequent try it doesn't wake up. And so on. I think this explains the alternation.
That said, I modified the source to send "0x55 0x55 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00" (16 bytes of data), and this seems to be enough to wake it up immediately. So, I think this solution is cleaner, faster and more reliable compared to adding a sleep(). This is why I'm submitting this patch.
Regards
Marcello Morena

[Romuald Conty]

Hello,

Sorry for lantency.. ;-)

After a careful read, you are right: this can fix UART issue without disturbing
actual working setups.

Thank a lot for your contribution.

If you can, please prefer issue tracker as its a more powerful tool to handle
issues/patches, but contribution is welcome anyway :)

Thanks again!

--
Romuald

[Peter Meerwald]

Sorry for lantency.. ;-)

> > please see the patches (#1 - #4 cleanup, #5 fix) here
> > https://groups.google.com/forum/#!topic/libnfc-issues/UyYMkG5nQJo

can you please consider the cleanup patches (minus #5)

thanks, regards, p.
 

[Romuald Conty]

Hello,

Le mardi 3 septembre 2013 07:23:12 Peter Meerwald a écrit :
> can you please consider the cleanup patches (minus #5)

Thanks for remainding me to apply your patches, but I applied all but -5 : why
are you putting a -dirty- sleep here ? Do you have any explanation about it ?
Adding more zeros to wake-up is not sufficient ?

Thank you anyway for your patches :)

--
Romuald

[Peter Meerwald]

 

Thanks for remainding me to apply your patches, but I applied all but -5 : why
are you putting a -dirty- sleep here ? Do you have any explanation about it ?
Adding more zeros to wake-up is not sufficient ?

Marcello's fix is certainly better, I was not aware of the possibility to use padding to delay the device

I'm happy this got solved and applied, thank for taking care!

regards, p.

[Marcello Morena]

Hi!

2013/9/3 Romuald Conty <rom...@libnfc.org>

Sorry for lantency.. ;-)

Don't mind! And sorry for my late reply.

 

After a careful read, you are right: this can fix UART issue without disturbing
actual working setups.

Thank a lot for your contribution.

You're welcome. I'm happy that my patch is merged and that this bug is now fixed: it caused me a lot of headaches :-)

 

If you can, please prefer issue tracker as its a more powerful tool to handle
issues/patches, but contribution is welcome anyway :)

Ok, I'll certainly do that way next time.

Regards

--

M.M.

[Jof Arnold]

I know this is many years later but I just want to thank you for writing this! It helped solve my problem with a PN532 chip I was trying to get working with my Arduino (Adafruit Bluefruit M0). It would work when running via the IDE but not via battery.

I hope you get my message. I'm very grateful for your post!

[Marcello Morena]

I'm really really happy I could help you, even many years later. I can still remember my despair when I was dealing with this PN532's behaviour, so I can imagine what you've been through :D

Thanks for your message and have a nice day!

--
You received this message because you are subscribed to the Google Groups "nfc-tools developers group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nfc-tools-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

M.M.