Issues with compatibility between Uno and Uno Wifi Rev 2

I seem to be having a ton of problems with getting shields to work with an Arduino Uno Wifi Rev 2. My main problems come from a LCD screen, and a 4g shield. Whenever I run my code on a normal Uno, everything is working fine. However, as soon as I move to the Wifi Rev 2 I cannot communicate with said shields using the same code. I have reviewed the documentation quite a bit for all related parts, and I cannot seem to come to any conclusion as to why it will not work. It seems to me based on the official docs that the two Arduinos should be compatible with the same peripherals. Is there something different in the architecture that could cause communication issues through serial on various shields?

Installation & Troubleshooting
For problems with Arduino itself, NOT your project

Have you forgotten to tell us anything?

pomeloproductions:
Is there something different in the architecture that could cause communication issues through serial on various shields?

As @TheMemberFormerlyKnownAsAWOL's reply indicates, you haven't provided enough information for us to provide a specific answer.

So instead, I'll just take a wild guess at what could be the problem:

The Arduino Uno WiFi Rev. 2 has 3 hardware serial ports. Serial is connected to the USB interface, Serial1 is connected to Pin 0 (RX) and 1 (TX)
...
This allows the usage of pins 0 and 1 without issues: on the original Arduino UNO, the usage of Pins 0 and 1 disrupts the sketch upload.

So on the Uno, if your shield was communicating over pins 0 and 1, then in your sketch you would use "Serial", but on the Uno WiFi Rev2, those same connections would require you to use "Serial1" in your sketch.

pert:
As @TheMemberFormerlyKnownAsAWOL's reply indicates, you haven't provided enough information for us to provide a specific answer.

So instead, I'll just take a wild guess at what could be the problem:
https://www.arduino.cc/en/Guide/ArduinoUnoWiFiRev2#serial-portsSo on the Uno, if your shield was communicating over pins 0 and 1, then in your sketch you would use "Serial", but on the Uno WiFi Rev2, those same connections would require you to use "Serial1" in your sketch.

Sorry for the late reply. I thought I would receive an email when there was a reply, and hadn't jumped on the website to check until today.
I should have been a bit more specific on the type of serial, because it should not have anything to do with hardware serial pins. The device in question (SIM7600CE-T 4G(LTE) Arduino Shield - DFRobot) is actually set to communicate over software serial using pins 7 and 8 instead of 0 and 1 respectively. Along with that it is using pin 12 to toggle the antenna power. After reading some docs on the uno rev 2 a bit more, it seems like the issue could be with changes of pin 12? The docs seem to indicate that the functionality of said pin was changed in the Uno Wifi rev 2 to not be an SPI port, although all the power switch of the 4g shield requires is that pin 12 to toggle a digital write of high or low, so the fact that the SPI port was removed does not seem like it would affect this specific functionality. I have pretty limited understanding of SPI though, so I really don't know if that would be a variable. I am only guessing that it could be something different with pin 12 due to that being the only pin this shield requires that seems to be different between the Uno and Uno Wifi.
Is there by any chance an issue with software serial incompatibilities on certain shields? I do have the option to change some jumpers to send the serial communication through pins 0 and 1, so I will give that a shot in case there is a potential incompatibility with software serial. I never run shields through hardware serial, so I had not even thought about that being a factor until you mentioned the differences in hardware serial between the two Arduinos. Thanks for the help, and if you know of any other information specifically regarding pin 12 or software serial incompatibilities then I would greatly appreciate some help.

As another follow up, after I changed the communication serial to use the hardware serial on line 0 and 1, it seems to be working fine. I still have no idea why port 7 and 8 would not work on the board considering that it worked fine on a standard Uno. Any ideas on why there would be an incompatibility like this?

The Uno Wifi Rev. 2 and the Uno are about as different as two boards can be while both have the AVR instruction set. Practically the only thing they have in common is the position of the headers and the name. They really should not have named them both "uno".

Uno is based on atmega328p, which is the larger-flash version of the 88, which was an updated version of the atmega8, used in the first arduino board.

The Uno Wifi Rev. 2 is based on the atmega4809, from the megaAVR 0-series released a couple of years ago. These have the all-new set of peripherals (like all other post-2016 AVR microcontrollers*), plus some snazzy new architectural improvements - all the flash is memory mapped, and a few insttructions have improved execution time. So, while the hardware is way better (and is similar to what future AVRs will have for a good long time), and once libraries get updated to work with it the result will absolutely be better, lots of libraries are broken on these parts and haven't been fixed yet. On the other hand, I'm very surprised to hear that SoftwareSerial doesn't work, as Arduino supplies that one - it is SoftwareSerial, not some other software implementation of serial? (of course, software serial of any description always sucks and you should always use hardware serial if at all possible, so your solution now is better anyway)

*this means, the x08 and x09 megaAVR 0-series parts, the tinyAVR 0-series, 1-series, and upcoming 2-series, and the latest and greatest, the AVR Dx-series, ex AVR128DA48 - currently DA and DB are out, and DD sounds like first half of next year)

DrAzzy:
The Uno Wifi Rev. 2 and the Uno are about as different as two boards can be while both have the AVR instruction set. Practically the only thing they have in common is the position of the headers and the name. They really should not have named them both "uno".

Yeah, I have been learning a lot the last few months about the differences. It's really confusing, and not just because it has the name "uno", but because it is also a revision of an already existing board. It's a real marketing blunder, and hopefully they learn something from this for the future.

DrAzzy:
(of course, software serial of any description always sucks and you should always use hardware serial if at all possible, so your solution now is better anyway)

I'm curious why you say this. I have done numerous Arduino projects over the last 8 years or so, and I have found that it is better to use software serial if at all possible in cases where you may only be able to use a shield through hardware serial. Using software serial has saved my skin a couple of times where I needed two shields, and was luckily able to run one through software while leaving the another one able to take up pints d0 and d1. I don't spend much time in the Arduino community though, so I have not heard much about why it would be a poor implementation, so I am genuinely curious to hear your opinion.

It's half duplex and requires the microcontroller's full attention when sending or receiving (and disables interrupts when during this time too). Writes are blocking (ie, when you print/write something to it, it will finish sending the code before execution continues; on hardware serial ports, print/write just stuffs characters into the buffer, and they get sent in the background while execution continues - put another way, it acts like every write is followed by flush). Plus, the SoftwareSerial library, in order to support operation on all pins, grabs every PCINT on the chip, so you have to use modified versions of the library that disable it on certain ports if you want to use PCINTs yourself (for example, to receive RF/IR comms, wake from sleep in the normal way (PCINT on change), even some common implementations of reading rotary encoders...). Violating the half-duplex requirement results in receiving gibberish (the dead-simple "echo" test fails if you send it more than one character at a time), for example); multiple SoftwareSerial ports are also one-at-a-time, and will see gibberish if that requirement is violated.

In ATTinyCore, on parts that don't have a hardware serial port, I include a builtin implementation of software serial (named Serial) that addresses the "grabbing every PCINT" problem, though none of the other issues. (admittedly, it also has some serious issues with RX that I was just made aware of when LTO is enabled - the compiler gets too aggressive optimizing things)

You pay a really high price for getting extra serial ports and/or serial ports on pins that don't have hardware serial; if I need more serial ports than a part has as proper hardware serial ports, I will strongly consider using a different chip rather than using software serial. (as an aside, I also avoid $hields like the plague... and "full size" boards that can accept them, for that matter. Only time I used one was a mega2560 when I was making a dual mode bootloader, and needed an atmega2560 on a breakout board in a hurry to test it on)

Very interesting. I did not know all of the details of the limitations on software serial. I will have to keep this all in mind when we work on the second version after our prototyping phase is done. We were originally trying to use a nano every, but we had a ton of problems trying to get it to communicate with this 4g shield. Most of the projects I have done the last couple years have been with a nano, but I have never formed strong opinions about particular boards. I may have to find an alternative for 4g that can once again be used with a nano in the next couple months.