rcs380.py: TypeError: format() argument after * must be a sequence, not NoneType
See original GitHub issueHello,
We’ve been using nfcpy on an Intel Edison with a USB-plugged Sony RC-S380 for quite some time now.
We are spawning the examples/tagpool.py
script from our program like this:
python examples/tagpool.py -l
Then we listen to it’s output and from then we get the value of the scanned ID card. It works very fine, but sometimes the process crashes with the following error:
nfcpy/nfc/clf/rcs380.py", line 307, in get_firmware_version
log.debug("firmware version {1:x}.{0:02x}".format(*data))
TypeError: format() argument after * must be a sequence, not NoneType
I was not able to reproduce this problem. However, it happens regularly on our production devices (and seemingly randomly), often enough so that we are worrying about it.
Does anyone have any idea where does this come from and how to fix it? Thanks.
Issue Analytics
- State:
- Created 7 years ago
- Comments:8 (3 by maintainers)
Top Results From Across the Web
Python: TypeError: argument after * must be a sequence
Sending just s to args=() is trying to unpack a number of arguments instead of sending just that single arguement. So you'd have...
Read more >TypeError: add() argument after * must be a sequence, not ...
The ManyToMany manager assumes that when you do tour.subscribers = sub. sub is a sequence (tuple, list, queryset) of Subscribers , not a...
Read more >format() argument after ** must be a mapping, not NoneType
Undercloud or Overcloud Installation Fails with "TypeError: format() argument after ** must be a mapping, not NoneType".
Read more >format() argument after ** must be a mapping, not list
Return a new list build by using .format() on the string, filled in by each of the dictionaries in the list. Here's my...
Read more >type object argument after * must be a sequence, not generator
why following python code raise error typeerror: type object argument after * must sequence, not generator while if comment first (useless) ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
The log was quite helpful as it shows that the reader itself is still responsive but returns the response for an older command. This would not happen if nfcpy terminates gracefully but may easily happen if unfriendly killed. I’d guess you’re using the kill methodology as part of your application logic. That you only see it happen sparsely is most likely due to the speed of the Edison, on my workstation PC is’s more or less immediate.
Fortunately the chip logic is stable enough to allow to fix this by removing any leftover response data during initialization. With your the shell script kill loop it’s now running since two hours.
As ugly as it may seem, we can still use the NFC reader and read data from it even when the above issue occurs, as this patch shows: https://github.com/nfcpy/nfcpy/compare/master...malikolivier:dirty-fix?expand=1
EDIT: It worked at some point of this day, but does not work anymore, you can see the errors log there. I do not know if this helps. Anyway, seems like the PC cannot read anything from the device.
https://gist.github.com/malikolivier/50f54cf26b70164a62cece1ef8ae6598