Show Posts
Pages: [1] 2
1  Products / Arduino Due / Freeze on native USB disconnect (IDE version 1.5.5beta) on: March 16, 2014, 01:53:33 pm
My sketch on a DUE periodically sends a message to the host via native USB and reads the answer message.
The sketch has proper error handling, means it detects all kind of transmission errors and uses timeouts.
Nonetheless, the sketch freezes (easily recognizable since otherwise some LEDs are blinking all the time) if the USB port is disconnected, either physically or by taking the device away from the virtual machine in which the host program is running. This problem does not happen if the host program just quits (i.e. stops answering).
I could not find out where in the sketch the freeze happens. What I can say, it is not during the time when the sketch sends the message and waits for the answer until 15ms timeout (i.e. not within SerialUSB.readBytes or SerialUSB.write - and yes, SerialUSB.available correctly states 0 Bytes available, keeping my sketch off from calling SerialUSB.readBytes). However, the sketch, unable to detect the non-availability of the USB connection, continues to send messages to the host, while getting no answer. The freeze happens after 8 messages without answer have been sent, each 16 Byte. The message send period is ca. 30ms in that condition.
My conclusion of these observations is, that the freeze is within an interrupt, triggered by an event that is part of USB handling, or that there is a non-trivial correlation to other functions that I use, such as sending/receiving data on the serial ports - this is what my sketch does when it is not busy with USB traffic.
Can anyone give me some hints how to avoid the problem? If the sketch could detect that the USB connection has ended, it could stop sending messages - provided that would help. Testing the statement "(SerialUSB)" showed that it is always true, so this does not work.
2  Products / Arduino Due / Re: analogRead problem with IDE 1.5.5 libraries on: January 17, 2014, 12:28:55 pm
The inaccuracy for my test setup, noticed with the latest patch, is probably due to the high impedance.
I generate the test voltages with 100k trimmers, followed by 10k resistors in series to the analog inputs.
I guess I understand now this effect. With older libraries, the SAM introduced a startup time that was long enough to charge the input capacity of the AD converter. With the latest patch, this startup time is omitted. So there should be a note in the Arduino documentation that specifies the max. input impedance without recognizable effects on accuracy.

One question still remains even after your explanation:
Quote
Looking at the logic diagram on the datasheet it seems that there is a multiplexer before the ADC, so theoretically only one pin at a time can be connected to the ADC.
If only one pin can be connected to the ADC at a time, why is it then necessary at all to disconnect the old channel, since it should be disconnected at the time when the new one is connected?  Disconnection would then only be necessary if you want to have the ADC going to sleep as in the libraries until IDE 1.5.4. This part of the code could then be removed from the analogRead function. However, should it be necessary to disconnect the old channel in order to get correct results, then it would not be the case that only one input is connected.
3  Products / Arduino Due / Re: analogRead problem with IDE 1.5.5 libraries on: January 12, 2014, 03:19:14 am
I can confirm that the delay is not necessary if the channel is not switched. Hence the delay can be made conditional.

However, after thinking over night about the matter, another aspect came into my mind. What is the exact effect to the analog section of the SAM when more than one channel is enabled, even if for short time only? Does this mean that the related analog input pins are then electrically connected with low impedance? If that was the case, this way of managing the channels would not be recommendable at all, since this could then destroy the related switches in the SAM if the source impedance at those pins is sufficiently low. A usual low source impedance would be e.g. some filter capacitors at the analog input pins, which could discharge quickly over connected analog input pins.
4  Products / Arduino Due / Re: analogRead problem with IDE 1.5.5 libraries on: January 11, 2014, 01:01:38 pm
I today tried the latest patch from the Nightly Build and it basically works in my application. However, accuracy is significantly reduced when compared to the analogRead from the 1.5.4 IDE.
I found a solution for that. The wiring_analog.c code has to be supplemented in analogRead:
Code:
delayMicroseconds(2); // this line new
// Start the ADC
adc_start( ADC );
I tried several delay times and 2microseconds seem to be sufficient to have comparable accuracy than before, and that time should not hurt too much on overall conversion time.
I suggest to take that patch over for the Nightly Builds and then into IDE 1.5.6.
5  Products / Arduino Due / Re: Lost Bytes when reading Serial1 when receiving also data via native USB port on: January 04, 2014, 07:40:14 am
Stimmer, I tried your alternative USB serial code. While solving the problem on the Arduino side for the receive errors on other serial in ports, it causes another problem on the host side.
Using Linux on a virtual machine on a Mac OX 10.8 computer as development environment, there is now following issue.
My Linux program cyclically sends (with ca. 6ms period) a message to the Arduino board via USB, with typical message lengths of 24Bytes.
For that purpose I open a serial device and use statements like
size = write(fd, ByteBuffer, msgsize);
This has always worked so far, but now with the alternative USB serial code on the Arduino, I observed an unusual slow down of message rates. Adding some debugging code, I found out that the first 10-20 write calls take some microseconds (as I would always expect), and the following take mostly 0.1s - 0.2s and sometimes 1.2s.
It seems that the transfers are not closed correctly on the Arduino side, leaving the host waiting for confirmation and running into timeouts.
6  Products / Arduino Due / Re: Lost Bytes when reading Serial1 when receiving also data via native USB port on: January 03, 2014, 12:45:48 pm
Ivanseidel, thank you for your comments, however I was already aware of that general issues with serial communication.
In my project, I use 32Bit CRC, so I detect transmission errors with very high probability.  Most errors are not reported as CRC check errors since the incorrect size of the received message is detected before that. With a baud rate of 115200, I detect erroneous reception about once per second, and this is due to the described Arduino bug only. This error rate is far above the physical transmission error rate and in no way acceptable.
7  Products / Arduino Due / Re: Lost Bytes when reading Serial1 when receiving also data via native USB port on: January 03, 2014, 07:53:20 am
I refined my serial error demo program to send 500byte messages instead of only 50byte since I wanted to find out how long after reading characters from the native USB impacts the reliability of received serial bytes on serial ports. For that reason I also modified the output in the error case. Now the indices of the dropped bytes are provided. In addition, I wanted to be sure that also other serial inputs are affected, so I changed the receive serial port to serial 2 (the electrical connection on the DUE must be then between Tx1 and Rx2). See the code below for 115200baud.
In order to find out the dependency of the symptoms on the baud rate, I also checked with 57600baud and 28800baud (see logs below).
Results from testing for the serial input are:
- with some probability, there is a drop of one byte after the SerialUSB.readBytes statement
- with lower probability, there is a drop of two (mostly non-consecutive) bytes after the SerialUSB.readBytes statement
- the highest observed index of a dropped byte was 62 for 115200baud, 38 for 57600baud, and 17 for 28800baud; this translates to transmission times of 5.4ms, 6.6ms and 5.9ms, respectively.

Conclusion: for a time of up to ca. 6.6ms after a SerialUSB.readBytes statement (tested from 115200baud down to 28800baud),  the reception of serial bytes is corrupted by randomly dropped bytes - mostly one byte, sometimes two.

Now it is time for an expert to find the root cause and provide a fix.
 

Log with 115200baud(part)

Tx Bytes: 950000  Fails: 81  USB received: 583340
9
4
Tx Bytes: 1000000  Fails: 83  USB received: 616668
2,60
26
61
59
Tx Bytes: 1050000  Fails: 88  USB received: 649916
62
20
4
35
29


Log with 57600 baud

SerialErrorDemo
Tx Bytes: 50000  Fails: 0  USB received: 26292
38
Tx Bytes: 100000  Fails: 1  USB received: 77392
Tx Bytes: 150000  Fails: 1  USB received: 128492
4,10
Tx Bytes: 200000  Fails: 3  USB received: 179592
5
33
8
14
Tx Bytes: 250000  Fails: 7  USB received: 230692
26
Tx Bytes: 300000  Fails: 8  USB received: 281792
1,8
16
5
0,6
1,3
0
13
3
Tx Bytes: 350000  Fails: 19  USB received: 332892
0,4
4
3
26
Tx Bytes: 400000  Fails: 24  USB received: 383992


Log with 28800 baud

SerialErrorDemo
1
Tx Bytes: 50000  Fails: 1  USB received: 31551
Tx Bytes: 100000  Fails: 1  USB received: 82651
1
10
17
3
2,4
3
Tx Bytes: 150000  Fails: 8  USB received: 133751


Code:
#include <Arduino.h>

long serialcounter = 0;
long failcounter = 0;
long usbcounter = 0;
int cyclecounter = 0;
unsigned char testbytes[500];

void setup() {
    Serial.begin(115200);
    Serial1.begin(115200);
    Serial2.begin(115200);
    Serial.println("SerialErrorDemo");
    for (int i = 0; i < sizeof(testbytes); i++) {
        testbytes[i] = i;
    }
}

void loop() {

    char serial_buffer[1000];
    char usb_buffer[16000];
    int n;

    Serial1.write(testbytes, sizeof(testbytes));
    serialcounter += sizeof(testbytes);
    cyclecounter++;
    if (cyclecounter == 100) {
        cyclecounter = 0;
        Serial.print("Tx Bytes: ");
        Serial.print(serialcounter, DEC);
        Serial.print("  Fails: ");
        Serial.print(failcounter, DEC);
        Serial.print("  USB received: ");
        Serial.println(usbcounter, DEC);
    }
    delayMicroseconds(60000);

    n = Serial2.available();
    if (n > sizeof(serial_buffer)) n = sizeof(serial_buffer);
    Serial2.readBytes(serial_buffer, n);
    if (n != sizeof(testbytes)) {
        int j = 0;
        for (int i = 0; i < n; i++) {
            if (serial_buffer[i] != testbytes[i + j]) {
                if (j++) Serial.print(",");
                Serial.print(i, DEC);
                failcounter++;
            }
        }
        if (j) Serial.println();
    }

    n = SerialUSB.available();
    if (n > sizeof(usb_buffer)) n = sizeof(usb_buffer);
    SerialUSB.readBytes(usb_buffer, n);
    usbcounter += n;
}
8  Products / Arduino Due / Re: Lost Bytes when reading Serial1 when receiving also data via native USB port on: December 30, 2013, 02:40:36 pm
Regarding "foolish", this is only a demo program, solely written to demonstrate the problem with the interfering USB data, after it cost me one day of work to isolate the bug.
The delay is not the point here, it just guarantees that sufficient time has passed and it can be expected that all transmitted bytes can be read. I know that the delay could be less, and I chose another kind of checking for the transfer to be complete before reading the echo in my project.
What remains for here is the fact that there is a problem with the Arduino libraries that has to be fixed by an expert for the related interface driver code.
9  Products / Arduino Due / Lost Bytes when reading Serial1 when receiving also data via native USB port on: December 29, 2013, 07:44:00 am
I discovered a problem in the Arduino Due libraries (I am still at 1.5.4 due to the analogRead problems in 1.5.5). Using an Arduino Due board with following setup:
- Tx1 connected with Rx1
- native USB connected to a computer running a terminal (I will name it "USB Terminal" below)
- programming USB port connected to a computer running a terminal (I will name it "Monitoring Terminal" below)
- Demo Program using to the code below loaded.
Do the following. Open both Terminals with 115200baud. Reset the Arduino board. You will see some text on the Monitoring terminal, cyclically printing the current status. Without data to the native USB port, you will see no fails. Then with the USB Terminal send a string (I used ca. 150 characters) repeatedly to the Arduino Due native USB port. The Demo program shows also the amount of received USB data. Eventually you will see Fails counting up. In my setup, I had 5 Fails after sending 16kByte of data to the native USB port.
 The nature of the error is that one of the transmitted bytes is not received on Serial1. The Demo program prints the received bytes to the terminal if an error occurs.
Using an oscilloscope and further debug code hints that the reception is the problem, not the transmission. In some way, the data reception on the native USB port influences the correct reception of bytes on Serial1.

Code:
#include <Arduino.h>

long serialcounter = 0;
long failcounter = 0;
long usbcounter = 0;
int cyclecounter = 0;

void setup() {
    Serial.begin(115200);
    Serial1.begin(115200);
    Serial.println("SerialErrorDemo");
}

void loop() {
    unsigned char testbytes[] = {
        1,2,3,4,5,6,7,8
    };
    char serial_buffer[1000];
    char usb_buffer[16000];
    int n;

    Serial1.write(testbytes, sizeof(testbytes));
    serialcounter += sizeof(testbytes);
    cyclecounter++;
    if (cyclecounter == 1000) {
        cyclecounter = 0;
        Serial.print("Tx Bytes: ");
        Serial.print(serialcounter, DEC);
        Serial.print("  Fails: ");
        Serial.print(failcounter, DEC);
                Serial.print("  USB received: ");
        Serial.println(usbcounter, DEC);
    }
    delayMicroseconds(6000);

    n = Serial1.available();
    if (n > sizeof(serial_buffer)) n = sizeof(serial_buffer);
    Serial1.readBytes(serial_buffer, n);
    if (n != sizeof(testbytes)) {
        for (int i = 0; i < n; i++) {
            Serial.print(serial_buffer[i], DEC);
            Serial.print(",");
        }
        Serial.println();
        failcounter++;
    }

    n = SerialUSB.available();
    if (n > sizeof(usb_buffer)) n = sizeof(usb_buffer);
    SerialUSB.readBytes(usb_buffer, n);
    usbcounter += n;
}
10  Products / Arduino Due / Re: analogRead problem with IDE 1.5.5 libraries on: December 09, 2013, 02:52:16 am
I am not sure if the source impedance is the only problem. I also partially see very similar converted values (e.g. 2898) for different analog inputs that are read in a fast sequence, while the input voltages differ as listed in the table in my source code.
If the source impedance was the only problem, we would just talk about decreased accuracy.
Is it possible that there needs to be an additional delay if the analog read input changes?
11  Products / Arduino Due / analogRead problem with IDE 1.5.5 libraries on: December 07, 2013, 08:14:55 am
I have a DUE test board where I use most of the analog inputs. For that test setup, I have written an automated test that reads the analog inputs and compares it with expected values.
When compiling with IDE 1.5.4, all runs fine. Compiling the same sketch with 1.5.5, I get mostly wrong analogRead results. I suspect a problem with the ADC initialization change that was introduced with 1.5.5. While appreciating a higher speed for A/D conversion, for sure no such problem must result  from that change.

Please find below a few lines of code that I use.
I do not know if that could be important, but I apply the test voltages via 10kOhm series resistors (which should not be a problem since the analog inputs have a very high impedance). And another detail: I use an external 2.5V reference.

For now, I will revert to IDE 1.5.4, hopefully a solution will be found for 1.5.6.
Can anyone meanwhile confirm the bug, and is there a patch possible in the libraries of IDE 1.5.5?

#define A_U_IN 11

static const unsigned char AinPins[] = {
    0,1,2,3,4,5,6,7
};

unsigned short Ain[sizeof(AinPins)];
unsigned short Apower;
boolean AinOk[sizeof(AinPins)];
boolean ApowerOk;

// Note: external reference voltage is 2.5V
static const unsigned short AinTest[] = {
    1870, 1900, //=DAC0, set to value 1800, at A0
    2130, 2170, //=DAC1, set to value 2200, at A1
    795, 843,   //=0.50V at Ain2
    1203, 1255, //=0.75V at Ain3
    1610, 1667, //=1.00V at Ain4
    2018, 2078, //=1.25V at Ain5
    2425, 2490, //=1.50V at Ain6
    2833, 2902  //=1.75V at Ain7
};

// Following code is in a loop:

// Read the analog inputs and compare with pre-defined values
        for (i = 0; i < MIN(sizeof(AinPins), smiley-cool; i++) {
            Ain = analogRead(AinPins);
            AinOk = (Ain >= AinTest[i << 1] && Ain <= AinTest[(i << 1) + 1]);
        }
        Apower = analogRead(A_U_IN);
        ApowerOk = (Apower >= 2701 && Apower <= 3243);

// ... other I/O and text output via USB
12  Products / Arduino Due / Power input via 5V Pin on: March 23, 2013, 10:08:49 am
I need to power the DUE with its 5V Pin in normal operation. What are the side effects of this?
Is there any component used in an unspecified range?
I guess one should also avoid connecting the DUE to USB while having the 5V supplied at the 5V pin.
Is there a suggested modification to the board?
13  Products / Arduino Due / External AREF with DUE on: March 22, 2013, 06:11:52 am
I would like to use an external 3.0V reference for A/D conversions.
Looking into the schematics, the related pin on the SAM3X8EA is connected to a (filtered) 3.3V supply. The AREF pin in the standard version of the board (mine is R3) is therefore simply a 3.3V output.
On the other hand, the board seems to have a provision to make a simple change to allow to use the AREF as an input to the SAM3X8EA. There is a small white rectangle drawn on the upper side of the board, with the text "3.3/Ext" above and "AREF" on the right of it, nearby to the ICSP connector.
Can anybody tell me what change has to be made?
14  Using Arduino / Project Guidance / Re: Watchdog in Arduino Library - or at least support by bootloader on: March 03, 2013, 12:16:15 pm
Thanks Nick to have solved the problem for the Mega2560 (now only the correctly working bootloader should be delivered with new Mega 2560 and new versions of the IDE).

Meanwhile, I have ordered the new Arduino Due. Has anyone yet successfully used watchdog with this one? Means, does the standard Due bootloader support watchdog, and what are the equivalent lines of code for the SAM3XE8 in the Arduino IDE?
15  Using Arduino / Project Guidance / Re: Watchdog in Arduino Library - or at least support by bootloader on: March 03, 2013, 12:07:06 pm
Regarding "
Tested on the Mega2560 board once I replaced the bootloader with this working one:

https://raw.github.com/arduino/Arduino-stk500v2-bootloader/master/goodHexFiles/stk500boot_v2_mega2560.hex
"

I found another bootloader (which seems to be the one installed with the Arduino IDE) under
https://github.com/arduino/Arduino/tree/master/hardware/arduino/
bootloaders/stk500v2/stk500boot_v2_mega2560.hex   

It has the same file name as "this working one", but its size is 103kB versus 21kB for the other.
Obviously, these are different bootloaders, and should have a different version, means e.g. stk500boot_v3_mega2560.hex for the working one. Besides of this, what are the differences between the two, other than watchdog support?
Pages: [1] 2