Bugfix for garbage data coming from serial port after reset. (Arduino Due) #1267
Conversation
|
atmega16u2 is not known with latest macports package http://www.macports.org/install.php#pkg version 0.5.4 even if using latest Xcode 4.6 running with Mac OS Lion. Maybe it is works on PC or Linux but right now, if really the DUE has the atmega16u2, can't erase it neither flash new firmware on the USB chip from a Macintosh. Please communicate another erase and flash DFU programmer running on Macintosh. |
|
I tested the firmware with Albert's test program. I run linux 3.0.0. The test program seems indeed to work (per the description in the aforementioned thread) with the 2013-02-05 and not with the 2012-11-05 firmware. If I slide any other then the two leftmost bars, the crc error led briefly lights up. But I guess that is normal, because I see the same behavior if I modify the sketch to use the native usb port. Albert, can you confirm this is normal? Can you also post the java code for the gui? Speaking of which, on the native port (ide 1.5.2), after some time the crc err lights up. I will test with Stimmer's version that reportedly works correctly with this test. @cmaglie: the fix seems to just reset the Due a little bit longer. Can you explain why this fixes this problem or the problem of garbage sent after reset? |
|
Hello PeterVH, Thanks to have made these tests. I'm still waiting for ISP mega-due shield spec from arduino team so I could actually upload the new firmware. I've created very lately a github account, made a fork from Alvaro initial SerPro and hopefully, will publish soon the IDE along with java sources, just need to verify some legal issues on java part since it is using USB libraries. Wether you've my java sources or not, I can comment your results. If you do not slide any GUI's sliders (two sliders on left of timer's check box or multiple sliders on right of timer's checkbox), the crc-LED should never light neither the Link-LED should never light. Only when you slide them, briefly the crc-LED or LinkUp-LED will briefly light per your your hand movement. About stimmer test 1, namely to hold reset then stop, it does work on my side with old firmware but i do not consider fully working because the LinkUp-LED and CRC-LED do stay faintly light up even though i admit the java GUI correctly received some internal parameters from arduino (Full H-brdige PWM frequency, duty cycle, boost-buck parameters,...). This specific lighting is really faint, you need to look in front of LED's but again, they should NOT light up at all if no GUI sliders action. As for using native USB after a while light-up crc-LED, this is not normal. Please remember that if you do NOT use any sliders, the crc-LED is a real 16-bit CRC inspecting any frame errors included in the HDLC protocol supporting the serial-deserail SerPro protocol. If it lights up then USB still has a problem for sure ! |
|
@PeterVH So the issue was not on the length of the reset, but on the fact that the reset sequence started from 30 and not 25. I don't know if my explanation is clear, the issue was really tricky to solve... @selfonlypath C |
|
Hello Everybody, do anaone know if the same problem with garage data or old data on serial bus could happen on arduino mega too? I still get old data in my serial bus from arduino after a few readlines the new datra arrives. Flush of inputbffer and outputbuffer on host side did not solve the problem.... best Kai |
|
Hello, this is the tutorial for uploading the firmware on the 16U2 using an Arduino Uno/Mega as AVR-ISP programmer: http://arduino.cc/en/Hacking/Upgrading16U2Due kind |
|
@hektoven Personally, I tend to suggest using my ElectroShaman SerPro GUI in RX/TX mode with any arduino because it covers so many cases of USB protocol since based on HDLC and so. As of today, it works fine with all the arduino mega's revision wether 1280 or 2560 so I would rule out any USB garbage issue. I do notice much less efficiency with mega 1280 and sometimes freezing which do not occur with mega 2560's. @Fede85 Albert |
|
Thanks for the docu. Typo in "The Arduino Due will took power from the Arduino Uno ...": |
|
I'm starting to apply the firmware update between my mega and my due but noticed that http://arduino.cc/en/Hacking/Upgrading16U2Due requires pin 10 as SS to connect Due's ICSP. |
|
Another thing about locating avrdude then launch it from Terminal shell, I'm using a Macintosh where I only see arduino.app |
|
OK I've found the trick to call from Terminal Shell avrdude from a Mac About mega SS-SPI signal, I really think the tutorial should mention pin 53 where for UNO, it is indeed pin 10 Will let you know the result of flashing the firmware |
|
aie aie aie... Something must have gone wrong, my Due's USB is not recognized or seen anymore by Arduino IDE :( Here is what I did from a Terminal Shell where before launching that command, I did load arduinoISP sketch into my mega 1280 then connected the 6 wires per the tutorial... new-host-3:desktop selfonlypath$ /Developer/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C/Developer/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -c arduino -P /dev/tty.usbserial-A6008igj -b 19200 -p m16u2 -Uflash:w:16u2.hex:i avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.02s avrdude: Device signature = 0x1e9489 Writing | ################################################## | 100% 5.27s avrdude: 4314 bytes of flash written Reading | ################################################## | 100% 3.21s avrdude: verifying ... avrdude: safemode: Fuses OK avrdude done. Thank you. new-host-3:desktop selfonlypath$ |
|
It looks like it worked ok though. |
|
Well glad to have confirmation the new firmware has been flashed correctly but hey guys, you need to help me because for whatever reason, my arduino DUE cannot download anything from the IDE ! About powering modes, i'm a bit new to these ISP stuff so just did per the arduino tutorial, namely connect both 5V and GND from my mega to the due, the mega receiving power from my Mac via USB. Please note that I've not saved the previous firmware, in fact I would have not known how to do it so now I'm really stuck :( |
|
|
Frankly i don't remember what I did withe wires after the avrdude flashing was done. Maybe i can try again to flash the new firmware and you teach me precisely what wires disconnection, powering down has to be done, IDE disconnected... Maybe more details of the global procedure described in the tutorial. P.S. Good to here I can recover the previous firmware but I guess in all cases, one has to teach me exactly all the steps to properly de-power, disconnect wires... Thank you in advance |
|
Remove all 6 isp wires from the due (and remove everything else connected to the due). |
|
When should I remove the USB generating power to mega then routing 5V and GND to due ? |
|
The firmware upload succeeded. I think the due will work if you connect it to your pc with nothing else attached to it. I want to be sure about that before doing further trouble shooting. |
|
Please find my new attempt with details on each step, maybe i'm doing something wrong Building the 6 wires between Due and mega... new-host-3:desktop selfonlypath$ /Developer/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C/Developer/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -c arduino -P /dev/tty.usbserial-A6008igj -b 19200 -p m16u2 -Uflash:w:new-16u2.hex:i avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.02s avrdude: Device signature = 0x1e9489 Writing | ################################################## | 100% 5.28s avrdude: 4314 bytes of flash written Reading | ################################################## | 100% 3.22s avrdude: verifying ... avrdude: safemode: Fuses OK avrdude done. Thank you. new-host-3:desktop selfonlypath$ Disconnect USB from MacBook Air so mega does not receive power implying DUE does not receive power from mega |
|
OK here is the situation, i've recovered the OLD firmware per PeterVH instructions then applied same step by step above instructions and USB works from IDE again... See below firmware log so I think the new firmware has a BUG or something preventing USB to work new-host-3:desktop selfonlypath$ /Developer/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C/Developer/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -c arduino -P /dev/tty.usbserial-A6008igj -b 19200 -p m16u2 -Uflash:w:old-16u2.hex:i avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.02s avrdude: Device signature = 0x1e9489 Writing | ################################################## | 100% 5.30s avrdude: 4352 bytes of flash written Reading | ################################################## | 100% 3.23s avrdude: verifying ... avrdude: safemode: Fuses OK avrdude done. Thank you. new-host-3:desktop selfonlypath$ |
|
OK finally great news, i've found why it did not work with new firmware and did work with old firmware. It seems an issue with Apple's Textedit so I've noticed different encoding on old firmware as published by arduino team and how I constructed the new firmware, namely it made a RTF instead of Occidental (Mac OS Roman). So I took old-firmware.hex then copy pasted inside the new firmware, of course downloading firmware from Terminal shell did work, it does not care the encoding. Now i've downloaded my ElectroShaman simplified IDE and simplified java GUI, the USB-SerPro link establishes correctly except a few details: RX and CRCerror LED's are BOTH faintly lighting This seems to not affect the proper LED's response to GUI's sliders change but I suspect still an USB garbage issue because obviously, I've no problem of 5V or 3.3V or drivers feeding 1K resistor in serie with LED under sink mode. Many thanks for your help and let me know if ElectroShaman can help confirm or infirm some remaining USB issues even though thanks to the new firmware, things work much better in my private lab using DUE. So I let you guys decide if the ElectroShaman and SerPro using HDLC and serializer-Deserializer higher protocol are reliable. I would conclude some USB data garbage still manifest once in a while because CRCerror computes a 16-bit error detection so some frames are corrupted then re-send and finally get through. Albert |
|
Funny, if I add a a blank line anywhere in the hex file e.g at 10% or at 70% of the file, I get the same flash size reported by avrdude as in your first posts: "4314 bytes of flash verified". |
In the latter case, I can't believe these are real crc errors (it happens every time). I'll have a look in the sketch.
|
|
@PeterVH Let me clarify, there was clearly a firmware issue with so much USB data garbage that SerPro would never establish RX-TX link between ElectroShaman GUI and arduino. That part is now solved thanks to the new firmware provided by Cristian. When you slide leftmost sliders or any other sliders on right, my IDE is setup in a way to reflect these actions with either LinkUp led or CRCerr led. This works fine now where of course, it is normal or functional to have faint lighting of Rx led and Tx led. These Rx and Tx just visualize some date communication, namely sliders value being transferred. Now I can assure you that if you do NOT move any sliders then, the RX and TX led should stay OFF, that is the case if you port SerPro with arduino UNO, arduino MEGA and partially true on arduino DUE. With DUE, the RX and CRC led are faintly ON so this is result of small garbage USB data !!! If you happen to have an arduino MEGA, please try my sketch and see by yourself ! Maybe there is another explanation because I've just used my tektronix tek2445 (4 channels at 150 MHz) to actually probe all the led's activity while sliding, not sliding GUI. It is true their voltage reflects what the SerPro protocol sees, namely even if CRCerr and RX led are faintly lighting ON, their respective arduino pin's acting as a sink indicates NO activity. Not sure about arduino pin's driver max mA or technology compared to arduino mega, maybe there is specific driver affecting pins 28 and 32 but not affecting pins 24 and 36 ! It would be interesting to understand why these 2 led's among the 4 are not correctly working or displaying the SerPro communication status, USB data garbage or just pin's output driver electronic effect ! |
|
P.S. Just checked the DUE's pin document of Graynomad, obviously all pins 24-28-32-36 outputs can manage same sinking current (my led's are wired to +5V via 1K pullup resistor). I can't prove it, need to find special T&M method but we cannot prove or disprove some residual USB data garbage since the RX and CRC led's should not even faintly light ON when we do not move any GUI slider ! |
|
P.S.2. Strange because when using my SEFRAM 4410 frequency generator in counter mode, if sliders are moving then I see glitching frequency when probing each LEDs which is correct but if no slider movement, no frequency so it tends to confirm what my tek 2445 scope already showed, namely arduino DUE not sinking any current to CRCerr and RX led's... Really wierd why they faintly light ON whereas they do not if loading same sketch in MEGA !!! |
|
|
BRILLIANT analysis so my scope or freq counter were correct, NO more USB data garbage with this new firmware... Case closed I guess, many thanks ;) |
… Due) Fixed #1267 Merge branch 'fix-usbserial-firmware-due' into ide-1.5.x
|
@cmaglie : yes the explanation is clear, thanks. I did not spot the 25/30 difference myself. |
|
As a reminder since i've been using arduino MEGA, the SS-SPI pin is 53 and not 10 as found in arduino UNO |
|
@PeterVH : hello please find a new release of the sketch and javas as requested 6 months ago where now the java GUI offers much more sliders, checkboxes as well as LOG console directly communicating with arduino MEGA or DUE being the client http://www.tantratron.tk/Arduino-Java-SerPro/GUI_MEGA_DUE_v2.05.zip |
|
This issue does not appear to be resolved. After updating the ATMega16U2 firmware I'm still seeing garbage on the input line whenever an initial serial connection is made from an external application. Try this sketch on a Due: void setup() {
Serial.begin(57600);
Serial.println("begin");
}
void loop() {
if (Serial.available() > 0) {
// Due will print a garbage character before "begin" upon
// serial connection from serial monitor or external application
// such as screen (OS X). Once the external application is open
// resetting the Due will not print garbage. It only happens upon
// the initial serial connection from an external app.
// This issue appears to be specific to Due.
Serial.print(Serial.read());
}
}You'll see a garbage character each time you open the Serial Monitor application or each time you create a new connection from Screen (OS X) or any external application making a serial connection with the Due. I'm not seeing this issue on an Uno, Mega or Leonardo. It seems to be Due specific. The problem here is that the first transmission from an external application will be corrupt unless the serial input is flushed. In Firmata I had to add the following line to the end of the Firmata.begin method: void FirmataClass::begin(long speed)
{
Serial.begin(speed);
FirmataSerial = &Serial;
blinkVersion();
printVersion();
printFirmwareVersion();
// clear any garbage in the input stream (this fixes an issue with Due)
while (FirmataSerial->read() != -1);
}The line cannot be flushed immediately after Serial.begin is called. Here blinkVersion creates a sufficient delay. If blinkVersion is not called, then a delay of at least 800ms must occur after Serial.begin before the serial input can be flushed. |
|
I'm seeing this issue on 2 separate Mega's 2560 R3. More specifically, using If I remove the delay, after each upload it would show "Test output XX" from a previous connection: and more importantly, these numbers are generally different from those of the previous upload. If I set the baud rate in setup() to be different from what I use for the upload (e.g. 57600 vs 115200), "first output" still appears but in a completely garbled form: suggesting that this trash output is a relic from the serial connection used for the upload. Could it be somehow discarded before the real desirable output? Of course, I could always discard anything that comes out of the board before sending the first command to it, but I was also hoping to log some initialization messages and use Serial 1..3 for communicating with third-party devices that may not react well to such output (provided it's not just 16U2). I also updated the firmware using Flip utility and https://raw.githubusercontent.com/arduino/Arduino/master/hardware/arduino/avr/firmwares/atmegaxxu2/arduino-usbserial/Arduino-usbserial-atmega16u2-Mega2560-Rev3.hex |
|
It looks like other ports are having the same issue: Output from Serial0 (connected via USB to PC) after upload: Output from Serial1 (connected via MAX235 and a third-party USB adapter to PC): Does that imply that 16U2 is not responsible for such behavior? If I understand correctly, it only serves to translate TX0/RX0 to USB and programming Arduino. It looks like Arduino goes through 2 'soft resets'(?), and the contents of the Serial buffers is not cleared between them. Could that be an issue within HardwareSerial? |
… Due) Fixed arduino#1267 Merge branch 'fix-usbserial-firmware-due' into ide-1.5.x
After reset garbage may show up from Serial port due to a firmware bug on the atmega16u2.
Here the relevant forum topic:
http://arduino.cc/forum/index.php/topic,134847
Here the updated .hex for the 16u2:
https://github.com/arduino/Arduino/blob/976f7588b7f68bd3c5fce52c15ccfe738589085a/hardware/arduino/sam/firmwares/atmega16u2/Arduino-DUE-usbserial-prod-firmware-2013-02-05.hex
Please check if the updated firmware fix the issues and report back here.
Thanks.
C