I2C/RFID bug brings down entire I2C bus

[finnbear]

I posted on the SparkFun forum about how my RFID module recently started reporting -1-1-1-1-1-1. After some debugging, it seems that when the module is first powered on, it starts reporting 000000. On the first tag, it scans correctly (reports the tag's number) and goes back to 000000 after that. On the second tag, it starts and continues to report -1-1-1-1-1-1. After this point, all other I2C devices on the bus become unresponsive (for example, proximity sensor starts reporting zeros and 7-segment display doesn't update anymore). I did test without any other I2C devices and a different power supply but had the same issue.

Other points of clarification:

• Microcontroller: Sparkfun Blynk Board
• Buzzer goes off after every scan, the first one, the one that bricks it, and all future ones too

I looked at the code and this line is a bit suspicious: https://github.com/sparkfun/SparkFun_Qwiic_RFID_Arduino_Library/blob/b476b210a4d8fdaf62584480f05d235397a21e57/src/SparkFun_Qwiic_Rfid.cpp#L224 Specifically, why is _numofReads relevant to a single read? Shouldn't the 2nd argument to requestFrom be the number of bytes required instead?

... such as _i2cPort->requestFrom(_address, TAG_AND_TIME_REQUEST);?

I went ahead and made that change locally but it didn't fix the issue...now what? :(

I'll see if anything else looks weird...ok so I see that the variable _numofReads is used in multiple different contexts, including storing the value of TAG_AND_TIME_REQUEST for a single getTag call...

[finnbear]

For reference, here is the output of a script that scans every second

Ready to scan some tags!
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 85081111056 Scan Time: 0.15 // The moment I scanned the tag
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: -1-1-1-1-1-1 Scan Time: 4294967.50 // The moment I scanned the tag again
Tag ID: -1-1-1-1-1-1 Scan Time: 4294967.50
Tag ID: -1-1-1-1-1-1 Scan Time: 4294967.50
Tag ID: -1-1-1-1-1-1 Scan Time: 4294967.50
Tag ID: -1-1-1-1-1-1 Scan Time: 4294967.50
Tag ID: -1-1-1-1-1-1 Scan Time: 4294967.50
Tag ID: -1-1-1-1-1-1 Scan Time: 4294967.50

Of course, after the -1's start appearing, no other I2C device functions properly

[finnbear]

I'm giving up for now, but I'm pretty sure there are two problems: 1) The _numofReads variable is used to refer to both number of tags to read and number of bytes to read, at least in the read all tags function 2) Some hardware/firmware/software problem that causes the -1's and I2C problems which I haven't figured out yet. Even if its a hardware/firmware issue, this library should not allow the entire I2C bus to stop working properly.

[edspark]

Hm, let's see if we can figure this out.....

The first behavior that you're describing ("it starts reporting 000000") is the intended behavior. If you have not scanned a tag but have requested a tag from the RFID reader, then it will give you zeroes to let you know there's nothing stored on it.

1. The variable could be named to something else but it doesn't change what the variable does. Right? You sort of get at that answer yourself:

"Specifically, why is _numofReads relevant to a single read? Shouldn't the 2nd argument to requestFrom be the number of bytes required instead?"

You're correct! It's the same: a read is equal to one byte, but again this is a red herring. The name of the variable doesn't change what it does.

2. How many devices do you have on your I2C bus when the issue starts, do you know how many have I2C pull up resistors and what those values are?

Also, are you requesting tags from the RFID reader without scanning a tag when the "-1"'s start appearing?

Thanks for the post, looking forward to your response.

[finnbear]

@edspark

The first behavior that you're describing ("it starts reporting 000000") is the intended behavior. If you have not scanned a tag but have requested a tag from the RFID reader, then it will give you zeroes to let you know there's nothing stored on it.

I realize that, I was just trying to give context for the -1's that followed

but again this is a red herring. The name of the variable doesn't change what it does.

#define TAG_AND_TIME_REQUEST 10
#define MAX_TAG_STORAGE      20 // Here, it is set to 20
[some lines of code]
void Qwiic_Rfid::clearTags(){

_readAllTagsTimes(MAX_TAG_STORAGE); // Here it is passed in, still equal to 20

} [some lines of code] void Qwiic_Rfid::_readAllTagsTimes(uint8_t _numofReads) // _numofReads parameter is now 20 { [some lines of code] for(uint8_t i = 0; i < _numofReads; i++) // Here, it is used to read 20 tags, which is fine { [some lines of code] _i2cPort->requestFrom(_address, _numofReads); // Here, it is used to read 10 bytes (except it is actually set to 20) [some lines of code] }

Am I missing something or is `MAX_TAG_STORAGE`, equal to 20, getting passed in as the `_numofReads` parameter and thus being used in the `requestFrom` instead of a number of bytes (10)?

Side note: Reading the firmware, the requested number of bytes are assumed to always be 10. This may be why my -1's issue is being caused by another underlying problem than this suspected typo.

> How many devices do you have on your I2C bus when the issue starts, do you know how many have I2C pull up resistors and what those values are?

I had 2 others (7-segment and IR proximity) the first time but I disconnected them and was able to reproduce the -1 issue.

> Also, are you requesting tags from the RFID reader without scanning a tag when the "-1"'s start appearing?

I used comments (beginning with `//`) to indicate the exact times I put tags near the scanner and heard a beep. Notice that there are 000000's before **and after** the first (successful) scan. So to answer your question, **no**, the -1's start on the very next scan (less than a second) from the time I physically scanned a card.

Hope this clarifies things!

[finnbear]

One more bit of into: Once the -1's start, they don't ever stop until the RFID module loses and regains power. Restarting the sketch/microcontroller doesn't fix the problem. This might be evidence for a firmware/hardware issue.

[edspark]

Hello finnbear!

Ah yes, I see the bug you're describing. As you said, I had intended to clear the whole storage which is 20 sets of 10 bytes, but I am reading 20 sets of 20 bytes. Very nice catch, I'll fix the issues and close this up when it's done.

[edspark]

Alright fix is in place:https://github.com/sparkfun/SparkFun_Qwiic_RFID_Arduino_Library/commit/5a80dafd8b8365b5fe0dfb6bed0b374e4af5d0d2 ....and hopefully this fixes the odd behavior you're seeing. Please check that it works in your setup and if not, please feel free to re-open this issue.

[finnbear]

@edspark Good fix but, unfortunately, it doesn't solve my problem. The reason for that is my code uses the tag = myRfid.getTag(); function, not the clear or multiple read function. Please re-open this issue :)

The behavior was slightly different as it printed -1's one time before the first scan's proper value, but I don't think this difference is correlated to the update.

Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
[would have gone on forever]
Tag ID: 000000 Scan Time: 0.00
Tag ID: -1-1-1-1-1-1 Scan Time: 4294967.50 // First scan a fraction of a second before this line
Tag ID: 85081111056 Scan Time: 0.80
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
Tag ID: 000000 Scan Time: 0.00
[would have gone on forever]
Tag ID: 000000 Scan Time: 0.00
Tag ID: -1-1-1-1-1-1 Scan Time: 4294967.50 // 2nd scan a fraction of a second before this line
Tag ID: -1-1-1-1-1-1 Scan Time: 4294967.50
Tag ID: -1-1-1-1-1-1 Scan Time: 4294967.50
Tag ID: -1-1-1-1-1-1 Scan Time: 4294967.50
Tag ID: -1-1-1-1-1-1 Scan Time: 4294967.50
[goes on forever]

In a few days, I will get some shiny new Artemis boards and I will test the RFID module with them to see if my Blynk Board is the issue. Until then, I'm not 100% sure whether this is a hardware/firmware/library/software issue.