I know similar issues are brought here a lot, I've read many threads regarding issues with Serial over the last few days. I'm writing an application to run on an Arduino Due and have been printing various data on the state of the application and some of its data so I know it's functioning properly. I won't post the whole sketch as it spans 4 files and about 1200 lines of code.
The issue I'm seeing is that at seemingly random spots the Arduino will stop transmitting data over UART. I've verified this by recreating the problem in both the Arduino IDE and CoolTerm and by checking the TX LED on the board.
I've been trying to cross off various sources of trouble for this, but I'm running out of ideas.
The Application:
My application is a machine that takes a triac and tests that it meets certain load current constraints which are split into three tests. As long as it passes each of these sub-tests, the triac passes the entire test. There is a single interrupt routine which detects if the acrylic lid covering the triac has been opened, at which point the test restarts, I've debounced this in software as it wasn't on a pin with a Schmitt trigger. At the end of every full test, I delay for 500 ms and flush the Serial transmit buffer.
My Concerns:
The Arduino Due can be powered via the USB port of the PC or from a power supply inside the machine outputting to a 5V bus. Could variations between these cause an issue?
The interrupt fires pretty often, which is why I went ahead and debounced it (as much as 300 times from the lid opening once). Could the frequent interrupts be causing problems with Serial transfer of longer arrays?
The triac and a couple other components are switched into the circuit which has AC line voltage running through it in various parts of the test. Could noise from this switching and AC power be disrupting the UART communication somehow?
Unfortunately I can't really make any hardware changes.
Thanks for any more ideas of trouble this could cause.
In order to cross off some things from the list of possible root causes, I tried checking the UART peripheral directly. After a certain variable incremented beyond a value in the loop() function, I would have the program run this UART testing function below at the end of every loop:
/* Configures the UART microcontroller peripheral for Local Loopback mode where
* the peripheral internally connects it TXD output to it's RXD input. See
* Section 34.6.2 of the SAM3X datasheet on the UART Mode Register.
*
* If in Local Loopback mode the print command can send a byte and the read
* command can see that byte after the error is detected, this function flashes
* two LEDs on for 1 second. This rules out issues with the internal UART
* peripheral.
*/
void testUARTTransmit()
{
/* Sets UART Mode Register bits 15:14 to 0b10 for Local Loopback. */
REG_UART_MR |= 0x00008000;
/* Flush the RX data buffer. */
if (Serial.available())
{
Serial.read();
}
Serial.write('*');
delay(1000);
if (Serial.read() == '*')
{
/* If the loopback works, flash red LEDs. */
setLED(LED_FAILED_POS_WAVE, GPIO_ON);
setLED(LED_FAILED_NEG_WAVE, GPIO_ON);
delay(1000);
setLED(LED_FAILED_POS_WAVE, GPIO_OFF);
delay(500);
setLED(LED_FAILED_NEG_WAVE, GPIO_OFF);
}
else
{
/* If the loopback doesn't work, flash green LEDs. */
setLED(LED_PASSED_POS_WAVE, GPIO_ON);
setLED(LED_PASSED_NEG_WAVE, GPIO_ON);
delay(1000);
setLED(LED_PASSED_POS_WAVE, GPIO_OFF);
delay(500);
setLED(LED_PASSED_NEG_WAVE, GPIO_OFF);
}
/* Sets UART Mode Register bits 15:14 to 0b00 for Normal Mode. */
REG_UART_MR &= ~(0x0000C000);
}
Using this I confirmed that after the Arduino IDE Serial Monitor stops printing Serial data that the UART peripheral can be set into Local Loopback mode and that it correctly receives its data it sends to itself, removing the UART peripheral from the list of root causes. I believe this also confirms along with my own searching through the source code that the Arduino Serial object, to say nothing og the other Serial2, Serial3 objects, is based on the UARTClass object. If someone else knows that to be true can they confirm that?
I've tried changing the above function for the USART registers instead just in case, but the Arduino IDE does not recognize their name defines. I tried substituting REG_US_MR for REG_UART_MR in the above code as in the datasheet they are called US_MR and UART_MR respectively, but no dice there.
I'm looking into how to determine if the Atmega16U2 chip could be at fault next.
So you're definitely not using USB native serial? I've had problems with that (and seen other reports on the forum) when I disconnect the USB it effectively locks up the DUE. The cure is to reset after unplugging the computer, so the program begins again. If USB was never connected, then it doesn't have the problem.
I'm sure it's the Programming Port and not the Native one, both from visual inspection against diagrams and the description of the port in the Arduino IDE. It's very intermittent behavior. Sometimes it will run for several minutes without an issue, sometimes less than 30 seconds.
I've also frequently had issues where the Arduino IDE can no longer see the Due on the COM port, despite being able to see it in the Windows Device Manager and in CoolTerm. When this occurs, despite being able to see it in CoolTerm I'm not able to open that port as if perhaps the Arduino IDE is still locking it up even though it claims to not even recognize it.
EDIT: After doing some more testing, I found that I may have been looking at the wrong TX LED. While the application was running I noticed another LED tucked away near the base of the DC barrel jack that continues to light up even after I'm no longer seeing anything on the Serial port. When I clicked back on my CoolTerm window to see if I could still send to it, it showed an error on a pop-up window (error 31) and updated the GUI to show it was disconnected.
MorganS:
So you're definitely not using USB native serial? I've had problems with that (and seen other reports on the forum) when I disconnect the USB it effectively locks up the DUE. The cure is to reset after unplugging the computer, so the program begins again. If USB was never connected, then it doesn't have the problem.
The problem seems to be that the USB can't get rid if the data when you disconnect. I've helped somebody in the past who had the lockup on a 32U4 based board. To prevent the lockup, check with availableForWrite() if you can send the data.
"The software mentioned above. It's not your Arduino code that is the problem."
Thanks but I don't understand what you mentioned. These non-Arduino apps all work 99% of the time.
Only once in 100 times they appear to receive 'new lines' randomly within the repeated numerical data.
Your software (labview, ..., ...) probably does the following
It processes incoming characters that are provided by the operating system. If the operating system decides to provide some of the characters a little later because e.g it has to do another task, you will have a glitch. If your software uses this small delay as an indication of the end of data and prints the data with a newline, you get the behaviour that your observed.
Based on the above, it's basically "what you see is not what you actually received".
If any of the PC applications that you use have the option to save to file, I suspect that you will not see the behaviour in the file.
I use RealTerm and in roughly 2500 lines logged I did not observe the behaviour; everything looked OK.
: