I have a recurring problem where, after powering up the UNO R4 WiFi, or after uploading a sketch, the program sometimes doesn't start running right away or at all. This has happened with several very different sketches, including the example LED matrix sketches and example WiFi sketches. In all cases, the green LED power light is on, but no other LEDs are on.
If the program doesn't start up right away, or within a few seconds of power up, it doesn't start at all. This doesn't happen all the time but rather about every other time I power up or upload a sketch. It's a minor nuisance, but I would like it to go away.
On a slightly different note, the documentation states that soldering together (bridging) the pads at SJ1 (labeled RA4M1 USB) on the board will cause the RA4M1 to communicate directly with the USB port, rather than through the ESP32-S3; I tried this and found that Windows 10 would not see the board at all, not even in Device Manager. I removed the bridge and all was well again. Is this supposed to work this way, or do I have another problem?
Beyond those two problems, I really like the UNO R4 WiFi; it works with my Nixie Tube clock shields which can now set the correct time automatically.
Try to reset the board by double tapping the reset button fast and checking the status of the onboard "L" LED. If the onboard LED fade in and out slowly (pulsating), upload an example sketch (Blink LED) or any of the examples at Arduino UNO R4 WiFi Cheat Sheet that is not your code to check if the behaviour is the same.
Regarding the second issue, check and follow the " ESP32-S3-MINI-1-N8" & "USB Bridge" sections correctly.
[quote="Dozie, post:2, topic:1160265, full:true"]
Try to reset the board by double tapping the reset button fast and checking the status of the onboard "L" LED. If the onboard LED fade in and out slowly (pulsating), upload an example sketch (Blink LED) or any of the examples at Arduino UNO R4 WiFi Cheat Sheet that is not your code to check if the behaviour is the same.[/quote]
I've done that several times; no other LEDs come on.
What is there to follow "correctly"? In the documentation I have (ABX00087-datasheet.pdf, dated 30/06/2023) this is the extent of the information:
"Soldering together the SJ1 pads permanently sets the USB communication directly to the RA4M1, bypassing the ESP32-S3."
If there is more documentation on this, I'd sure like to know where it is.
Regarding the sketch not starting after upload make sure the sketches don't have anything like while (!Serial) otherwise you need to open the serial monitor in order to the program to start
Things I would try if were me: Sorry I know just throwing darts hoping one hits...
Try several different USB cables. I have had issues where sometimes a cable makes good contact and other times not. Likewise different USB ports. Yes long shot but been there.
Make sure your boards are updated to the 0.30.0 firmware for WIFI.
Put in something like:
pinMode(LED_BUILTIN, OUTPUT);
for (int i=0; i < 5; i++) {
digitalWrite(LED_BUILTIN, HIGH);
delay(250);
digitalWrite(LED_BUILTIN, LOW);
delay(250);
}
At the start of setup, to see if it actually starts up or not.
With some sketches that use WIFI or BT, if the WIFI or BT fails initialization, the code just hangs. So try to detect cases like that.
If you are using some specific sketch that you run into this, it would help to post it, such that maybe some of us can try to reproduce it. For example, maybe you are using some object whose constructor does something that does not work properly. For example it might try to do things like: attachInterrupt which does not work.
Do you have anything connected or plugged into the board? If so, does it behave the same way, if you remove everything?
FYI - On WIFI boards the !Serial loops do not do anything on the WIFI board.
The Serial object is implemented by a UART object and the Boolean operator always returns true.
But: I have found times, where if the sketch does do things like Serial.print(), you need to make sure that the Serial.begin(baud); the baud rate of the Serial monitor needs to match or there could be issues.
Not much that I have seen. Note: the documentation is wrong about the IO pin associated with this. Pin 40 is wrong. There are a few threads where some of us have experimented some, with this, like:
But I don't know if anyone has soldered the pins together, to make it reasonably permanent. This would probably require the new variant, plus an updated bootloader to be flashed on to the RA4M1, which would probably be very close to the version on the MINIMA, but some of the IO pins are different. Possibly other things as well.
As a matter of fact, you may have something there. I'm using the UNO R4 WiFi with a Nixie Tube Clock shield. This shield is from Ukraine and was designed to work with UNO R3 and the MEGA 2560; and it works perfectly with both those boards.
I have, finally, noted that when a program (any program) won't start up right away, or at all, the board is attached to the shield, and I have to keep powering off and back on until the program does start.
However, if the board is alone, I can't recall any program not starting up right away; of course, I can't say for sure about the clock program as the only way to know if it is running requires the shield be attached.
It appears, there is something about that shield that is, sometimes, preventing the program from running.
And I think I have an idea what it might be: the UNO R4 runs at 48mhz; the UNO R3 and MEGA 2560 at 16mhz. The clock program first tries to acces the RTC on the shield, through the SPI port, but uses the default SPI speed based on the processor clock, rather than specifing a slower speed. If it fails to access the RTC it goes into an infinite loop (while (true);).
I have no idea why this would keep other programs from running (like the Blink program)
but, I'll bet it's related, somehow.
When I soldered the pins together, it was part of an attempt to solve the other problem, believing that the ESP32 wasn't starting the RA4M1. Of course, that didn't work and made things worse (board not recognized). In any case, I am not concerned about that "feature", only the bigger problem.
Thank you for planting a seed; when I get home tonight, I'll water it and see what grows.
The clock program accesses the RTC on the shield using the I2C bus. I'm not sure now how that affects anything, but I'm going to investigate more thoroughly.
Okay. I inserted several Serial.println() statements into my clock program to see whether or not the program was in fact running and getting hung up somewhere, or not starting at all.
The program does in fact start running but then gets hung up at this bit of code in the setup() function:
if (!MyTime.begin())
while (true);
I noticed that with the Serial statements in the code, it hangs every freakin' time without fail; but, without the Serial statements, it sometimes makes it past that test and the program runs just fine. Absolutely boggles my mind !!
And none of this explains why other programs, i.e. Blink, sometimes won't run if the clock shield is attached to the board. My best guess...if the software doesn't initialize the I2C bus,
the clock shield is somehow leaving the I2C bus in a state that prevents the RA4M1 from starting up...or possibly prevents it from communicating through the serial port.
And before you ask, I tried adding Serial statements to the blink program; there was no indication the program was running at all. If I remove the clock shield, the program runs just fine.
That issue aside, I'm more interested in getting my clock program to work reliably and consistently on the UNO R4 WiFi with the clock shield...as it does on the UNO R3 and MEGA 2560.
The clock shield uses a DS3231 RTC clock chip on the hardware I2C bus. Currently I use the RTCLib library from Adafruit; I'm going to try switching to the RTCTime library from Arduino and see if that makes a difference. I'm also going to try eliminating the test condition on MyTime.begin() and simply let the program run whether it fails or not. (Maybe I'm getting a false failure from it.)
BTW: for those who are curious, the clock shield is from GRA & AFCH, Model NCS312 v1.5
I will try to post the results of my tests in the next few days.
stecoop- Is your Nixie Tube Clock shield from GRA & AFCH? If so, did you have to do any customization of their code to compile for UNO R4 WiFi? I have success with the Uno, but not R4. I can't get past SPI.h. Thanks.
I wrote my own program for the clock so it would "behave" a little differently from GRA & AFCH's program. Note: I do NOT use GRA & AFCH's Time library...I use the standard Time libraries for Arduino and Adafruit.
I can try to send you a copy of the code, if you wish.
Also, I posted somewhere in this forum, that I determined the startup failures were being caused by the initialization of the tube driver shift registers on the clock shield - pulling down the voltage to the Arduino board just enough to leave the RA4M1 confused; doesn't happen with the UNO R3 or the Mega 2560. I think a modification to the clock shield would be required to fix it.
!!