For a project I am relying on serial communication for hours, even days at a time. Unfortunately the environment isn't completely noise free, which is causing communication to lock up after a few hours.
These mostly focus on removing noise, as well as resetting the COM port using devcon.exe, which in my case isn't really an option. I have updated the bootloader on my MEGA2560 to allow me to use the watchdog timer to reset the chip if it browns out, however these boards use a secondary atmega8u2 or atmega16u2 to handle serial communication. I expect that if there is some noise, both of these chips would brown out simultaneously.
I had a look at the code for the chip (located at "C:\Program Files (x86)\Arduino\hardware\arduino\firmwares\atmegaxxu2\arduino-usbserial\Arduino-usbserial.c"), which specifically disables the watchdog timer. My question is thus: Would modifying the code on this secondary controller to make use of the WDT, in combination with variables stored in ".noinit", improve the reliability of serial communication over long periods of time? If yes, can anyone give advice on how this may be done?
For a project I am relying on serial communication for hours, even days at a time. Unfortunately the environment isn't completely noise free, which is causing communication to lock up after a few hours.
For noise immunity, use RS485, shielded twisted pair cable, shielded enclosures.
Thanks for the replies. I realise that it is better to avoid this situation to begin with, but I'm looking at ways of recovering a lost USB connection.
Brownout and noise are two different things. You will not detect noise with a brownout detection.
You have to isolate exactly what is failing due to noise. Serial communications while being disrupted by noise will not jam up because if it.
Thanks Mike. I thought noise could trigger the brownout detector?
The communication does jam up, I am wondering if a change in the ATmega16u2 code can remedy this?
The main controller seems to remain active since enabling the watchdog timer, but this doesn't help if it is made inaccessible by a frozen communication controller.
What has an Uno R3 got to do with the problem - are you communicating between a Mega and an Uno or only between a Mega and a PC?
If the comms with the PC is "locking up" ...
is this happening at the PC end or the Arduino end?
how do you know?
how does the problem manifest itself?
will other code on the Arduino keep functioning even when the comms becomes inoperable?
what software is running at the PC end?
is it aware that a problem arises?
does it keep functioning after the problem arises?
is it possible for the Arduino to do something to resolve the problem?
OR, must the problem be resolved at the PC end?
Sorry for the confusion. I only included the UNO R3 in the title because the serial communication is the same, hence my hypothetical solution would apply to both boards. I am only using serial comms between a Mega and a PC.
To answer your questions:
I don't know which end is causing the lock up. If you know how I could determine this let me know.
When the problem occurs, the Arduino board does not respond to anything. The 'receive' LED still lights up on the board, but no further processing appears to happen.
The program appears to continue but in normal operation only follows short instructions from the PC. I will do some fading LED thing to find out.
The PC is running a LabVIEW program
The software times out when it doesn't get a reply to a sync byte
This is what I'm trying to determine. Does enabling the WDT on the ATmega16u2 allow the serial comms to be recovered?
If it is on the PC end, devcon.exe could probably recover the connection, however I tried this and it didn't seem to work.
This is what I'm trying to determine. Does enabling the WDT on the ATmega16u2 allow the serial comms to be recovered?
This wasn't what my question had in mind. Your question here is about HOW to get the Arduino to do something. My question is whether it is POSSIBLE for it to do anything that would help (even if the WDT is successfully brought into use). For example the Arduino can't make the PC close and reopen the com port.
When the problem occurs, the Arduino board does not respond to anything. The 'receive' LED still lights up on the board, but no further processing appears to happen.
The program appears to continue but in normal operation only follows short instructions from the PC. I will do some fading LED thing to find out.
Taken together these are confusing. The first seems to say the Arduino crashes. The second seems to say it doesn't. It is essential to find out - the fading LEDs would be a useful test.
Watching the Rx pin on an Oscilloscope might show if the output from the PC stops. Or maybe just connecting an LED with a resistor to the Rx pin. Note that the line will be HIGH when idle.
Have you another Arduino - ideally a Mega or Leonardo with multiple serial ports. You could use it to monitor what is coming from the PC to the first Arduino by connecting the first Arduino's Rx pin to the Rx pin of the Serial input on the second Arduino and having it echo everything it receives to the PC. (Hope that makes sense -let me know if not).
Does Labview show any error message when the comms times out?
Does the Labview program continue as normal if you press the reset button on the Arduino and do NOTHING on the PC. If so it would suggest to me the problem is on the Arduino end. Not doing this doesn't prove the opposite because I don't know how the Labview interface is written.
Could you write a PC program (perhaps using Python) that pretends to be Labview as far as the Arduino is concerned. It wouldn't have to do anything intelligent - just receive data and send suitable responses.