UART problem after rfid library execution

[M-4A]

Conflicts with UART. After executing PICC_IsNewCardPresent() - it is not possible to read the UART (any RX Serial1, 2, 3). Thank you.

[Rotzbua]

https://github.com/miguelbalboa/rfid/blob/master/.github/ISSUE_TEMPLATE.md

[M-4A]

OS version: Win10Pro
Arduino IDE version: 1.8.9
MFRC522 Library version: 1.4.8
Arduino device:  Mega 2560
MFRC522 device:  RC522

Affected file(s) or example(s): Code: LF-RFID-Reader.zip UART: ibustrx.zip

Steps to reproduce: ? Observed Results: Described in the first post Expected Results: The serial port must be receiving data.

Thank you.

[Rotzbua]

@M-4A Hi, any update? In my opinion there should no interference between UART and SPI.

[M-4A]

Hello. In my opinion, too. So far, everything is unchanged. At the first reading of the card, the UART RX freezes.

[Rotzbua]

Since no one else has observed this problem, this report is closed. It can be reopened if someone else also experiences the problem. Best wishes.

[VenomXNL]

Arduino IDE version: Visual Micro (NOT Arduino IDE, but does use Arduino compiler 1.8+) MFRC522 Library version: 1.4.8 Arduino device: ATMega328P (Custom board but you could consider it being used as a Nano) MFRC522 device: RC522

I'm having the exact same problem, and especially when using 'longer strings' over serial (I KNOW this isn't recommend but Have been using this technique several years for products like this without any problems.) I do use proper memory reservation calls etc also have checked the free memory (during runtime) and none of these things are the actual issue.

  CheckCount++;
        if (CheckCount >= 6000) {
            CheckCount = 0;
        if (mfrc522.PICC_IsNewCardPresent())

The issue itself are indeed (as mentioned before) the calls _mfrc522.PICCIsNewCardPresent() and _mfrc522.PICCReadCardSerial().

Once these calls are being made it's near impossible to read serial lines with the following style:

  while (Serial.available()) {
        char inChar = (char)Serial.read();
        if ((inChar == '\n') || (inChar == '\r')) {
            stringComplete = true;
        }
        else {
            inputString += inChar;
        }
    }

if (stringComplete == true) {
          if (inputString == "OK") {
            ResetConnectionTimeoutCounter();
        }

        inputString = "";
        stringComplete = false;
    }

My MAIN problem is when sending 20 char lines to update the 16 characters on one line of a 16x4LCD, which is just plain impossible when running/reading it every cycle (the RFID reader).

What DOES work (a bit! though) is introducing a limit to how often it's allowed to read the RFID reader. for example like this:

       CheckCount++;
        if (CheckCount >= 6000) {
            CheckCount = 0;

        if (mfrc522.PICC_IsNewCardPresent())
         {
        }
}

(Ofcourse the CheckCount being a 'global integer'!)

That lowers the issues significantly, but STILL does drop data/packets or what ever. Due to the fact that I'm using Visual Micro (and not the 'plain Arduino IDE', I was able to monitor LOTS of data about the code running on the MCU itself, and there seem to be no other issues like memory conflicts. 'full memory' or whatever in my own code.

Literally everything works fine, except when the RFID reader is being read, then it's going to skip alot (if not all) serial data.

The LCD is controlled by the 'commonly known' "LCD to I2C adapter", next to that I'm also doing analog readings (every 3 seconds on A6 and A7), And to the other pins a keypad (4x3) is connected. Nothing 'that fancy' which should affect the serial readings in such a way as it's doing when reading the RFID tag.

I have also double checked all circuits, decoupling etc etc several times, and everything is fine there also.

Hope this information is a bit more useful in possibly recreating it and/or finding the issue :)

[Rotzbua]

To clarify: This rfid library blocks until everything (communication Arduino <> RFID <> TAG) is finished. This means the rfid function is blocking a "long" time. So other time critical operations may be impacted negatively like serial communication, light... It is possible to improve this with using the rfid interrupt but it makes everything more complex and hardware depended. I think there is an interrupt mfrc522 library on github. Maybe this solves your problems.

Furthermore the arduino has just a small uart buffer (64) and no indicator for overflows, which is also a problem. There is a serial event (interrupt) function this could also be an improvement for your project.

Not sure about your exact code, but using the arduino string class can also cause problems. For example the += always cause a cost intensive memory copy operation if the memory is not reserved by reserve.

[VenomXNL]

Hello,

I'm aware of the serial issues of the 'arduino', the way I'm using the serial port is indeed already quite "a bit" more complex than described in my initial comment/example (but just kept the comment as simple as possible :) ), The problem however isn't that the RFID blocks everything, but just causes some strange issue with the RX of the UART system itself.

Everything else (including LCD updates which are only MCU sided and not using Serial Input) are just running fine, as well as analog readings, digitalwrites etc. Unless we want to process the serial data for display on the LCD (and thus receiving longer lines (or more bytes) then it starts to become a problem. HOWEVER, sometimes it even just drops a byte or two on simple three letter commands. (Obviously) It is a BIT slower per cycle when the RFID portion of the code is being triggered (which is as expected because it had to do extra communication), however the serial port itself truly seems to have bigger issues in regards of being used when the RFID reader is being checked for a new card meanwhile. Sending still works as it should though. It's truly the incoming data which causes problems. And I'm indeed aware of the possibilities of using interrupts for either the RFID reader or the serial port, however this should not (per say) be necessary in this situation.

In regards to the 64byte buffer, this is only when when using the standard Arduino software which is what I'm not doing ;) (Our buffer has been set to 256 bytes actually for reasons which are in regards to a different (not related to this) part of the project (#define SERIAL_BUFFER_SIZE 256), So it's not an buffer overflow either unfortunately (I'm even using the RTS etc for full serial standards).

I know that the += isn't the "best" solution for using strings and the serial communication (at all). However I'm using this code (in a controlled software environment) with MANY other projects which all run just fine using this method (which have several other reasons in regards to processing and passing said data faster). But... even when using a char array for example, it still does produce the exact same issue as it's having now. When checking the memory (free mem that is) on the MCU, it at all time has at least 800 bytes of free ram, and there are also no other signs of 'out of memory exceptions/issues'.

For now I have solved it by "delaying" the RFID library an "insane amount" like explained above (only letting it trigger once every 5000 cycles of the MCU), And because this thread stated that "Since no one else has observed this problem, " I did wanted to notify you on this issue and that it in fact is an issue of this library (or an conflict with this library and the LCD I2C library). Other library's don't have (or had) this problem at all in past with all the projects we have done.

For what it's worth though: The problem seems to be most likely to occur when it's revolving around reading serial data and passing it to the LCD (via I2C) while the RFID module is actively checking for new cards. In the past we've also had issues with this same library which caused the 522's to stop working suddenly when the device would be running for a prolonged period (like for days or weeks on end), this issue seems to be resolved since the latest version though. Due to this (and such problems nicely being resolved :)) I did wanted to notify you with with a bit more details about this problem, also due to the fact that these are quite specific situations when it occurs.

When for example just making a simple RFID reader with some leds, a beeper and a relay for example, this doesn't (seem to) produce any problems. However when it's involving more complex projects which involves Analog readings of additional sensors, an LCD and (extensive) serial communication, it does seem to happen more often.

Even if I would 'scrape all other code' and just leave in the serial, LCD and RFID part it does reproduce the same issue again. And that is with A LOT more memory free for example.

So to clarify: I have tried many different ways, and the problem unfortunately is reproducible in more than one ways, BUT again: Only during/under VERY specific conditions.

The most "easiest" way to replicate it (and YES i'm aware that it isn't using the optimal "programming rules" by not using interrupts or event triggers) is by making a hooking up an LCD (4x16 or 4x20), connecting the RFID module and then over serial sending PER LINE an update string for line1, 2, 3 and 4 of the LCD and then followed by an 'refresh command'. When using it in this way and then frequently updating the screen it will most definitely reproduce the serial receiving problem again.

IF requested and you don't understand what I mean, I see if i can find some time to make such a 'demo problem sketch' in the upcoming next days or so (Although due to being very busy for work, it might take a while until I get to it).

I have now found workarounds to work around the issue with the library, but can assure that the problem isn't caused by the general code of the project itself. For me it's already working as we expect it to work, However I'm just hoping to pin-point a problem (either conflicting from/by other library's, certain calls which don't seem to be compatible or just in the library itself) which occurs just rarely. Especially since I as developer myself also know how incredibly frustrating it can be if there is a problem but its very hard to recreate it or just happens during very rare conditions :)

And thus I hope this more elaborate information has been at least a bit useful in confirming It's not just one case as @M-4A has reported, but that it only (seems to) happen(s) under certain (quite) specific conditions :)