1.6.200 Arduino AVR core definition serial issue

[tigoe]

The 1.6.20 and 1.6.200 AVR core board definitions cause the serial library to generate some unwanted characters.

Problem: random mystery byte at the end of a .println().
Steps to duplicate:

• Upgrade to 1.6.20 or 1.6.200 Arduino AVR boards
• run Basics -> AnalogReadSerial sketch
• notice extra byte at the end of serial output.

Duplicatable on an Arduino Uno and Seeeduino 328 core derivative.

[facchinm]

Hi Tom, I'm currently unable to replicate it in any way. Could you bisect the problem and check if it also appears in any previous version of the AVR core? There hasn't been any functional change in the Stream/Serial code for quite a long time; arduino/ArduinoCore-avr@ba9d416 could trigger a side effect on 3rd party libraries but not on the core itself

[tigoe]

I tried with the 1.6.19 core and I couldn't replicate the problem. It hadn't appeared before 1.6.20. when I'm on a computer later this afternoon I'll see if I can get you a more detailed report. It's pretty consistent on every 328 model I've tried, but I didn't try the 32u4 models. What changed from 1.6.19 to .20 to .200? And why the unusual .200 numbering? Maybe I can find a hint looking at the changes. On Nov 10, 2017 5:45 AM, "Martino Facchin" <notifications@github.com> wrote: Hi Tom, I'm currently unable to replicate it in any way. Could you bisect the problem and check if it also appears in any previous version of the AVR core? There hasn't been any functional change in the Stream/Serial code for quite a long time; arduino/ArduinoCore-avr@ba9d416 <arduino/ArduinoCore-avr@ba9d416> could trigger a side effect on 3rd party libraries but not on the core itself — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6899 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXOnyNDNnNxGROkopmDxY-vSQ8CDrbqks5s1ClLgaJpZM4QVWm4> .

[facchinm]

The .200 is the experimental core with the new toolchain, it is included in staging json and it's not officially released yet 😉
Between 1.6.19 and 1.6.20 there are only a bunch of commits about documentation or external tools (https://github.com/arduino/ArduinoCore-avr/commits/master) so it looks like the source of the problem is different.

[tigoe]

OK, did a more thorough test, and here's what I have:

Context:

• MacOS, 10.12.6 , Arduino 1.8.5

• Arduino Uno rev 3, Arduino Leonardo

• Set AVR core to 1.6.19.

• Upload AnalogReadSerial

• All works well on both boards.

• Set core to 1.6.20

• Upload AnalogReadSerial

• Leonardo works fine, Uno outputs \d\d\d?\r\n

• ? (0x3F) persists regardless of the values of \d

• Tested with two different Unos, same results

• Reliably repeatable with 1.6.20 or 1.6.200

• reliably repeatable after restart of IDE, also reads the same in several serial terminal programs

I also downloaded 1.8.4 and the hourly build and tried the same steps above with both of them. Got the same results with 1.8.4, and with the hourly build.

I'm working with the 1.6.19 core for now, no big deal, but it's definitely a repeatable issue for me.

I didn't see anything in the latest builds that looked like a clear cause of this, unfortunately. That's all I've got. Let me know if you want to try anything else.

[facchinm]

Hi Tom,
I hexdumped the raw stream from both 1.6.20 core and 1.6.19 on a Uno, the output is the same, something like

00001260  0d 0a 31 37 30 0d 0a 31  37 31 0d 0a 31 36 35 0d  |..170..171..165.|

I rally can't think about anything except an OS related problem but the fact that it only happens on core 1.6.20+ is really awkward...
My commandline for compiling AnalogReadSerial with .20 is

/ssd/Arduino-master/build/linux/work/arduino-builder -compile -logger=machine -hardware /ssd/Arduino-master/build/linux/work/hardware -hardware /home/martino/.arduino15/packages -hardware /home/martino/eslov-sk/hardware -tools /ssd/Arduino-master/build/linux/work/tools-builder -tools /ssd/Arduino-master/build/linux/work/hardware/tools/avr -tools /home/martino/.arduino15/packages -built-in-libraries /ssd/Arduino-master/build/linux/work/libraries -libraries /home/martino/eslov-sk/libraries -fqbn=arduino:avr:uno -vid-pid=0X2341_0X0043 -ide-version=10900 -build-path /tmp/arduino_build_118156 -warnings=all -build-cache /tmp/arduino_cache_522111 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.avr-gcc.path=/ssd/Arduino-master/build/linux/work/hardware/tools/avr -prefs=runtime.tools.avrdude.path=/ssd/Arduino-master/build/linux/work/hardware/tools/avr -verbose /ssd/Arduino-master/build/linux/work/examples/01.Basics/AnalogReadSerial/AnalogReadSerial.ino

and the md5 of the resulting binary is 4b7cd3b89fbef8038f352812e72d62aa
I'm attaching so you can try to flash it directly with avrdude and check if the problem still happens.
AnalogReadSerial.ino.hex.zip

[MCUdude]

I'm experiencing the same problem as tigjoe did. However, everything works perfect with 1.6.20, but not with 1.6.200. Serial.println prints jibberish when trying to print a number, such as in the AnalogReadSerial example. I've tried with different hardware (ATmega328P, ATmega328PB, ATmega128).

I've attached the source code, hex and elf file for each toolchain, compiled for Arduino UNO/ATmega328P. I'm running Mac OS 10.12.6 and Arduino IDE v1.8.5.
println_1-6-20.zip
println_1-6-200.zip

[awatterott]

I could not reproduce the issues. Maybe it is related to the crystal or reset. The ATmega328PB has no full-swing option and the reset levels are different.

[MCUdude]

I was able to reproduce this with the official core with an Arduino UNO (328P). I'm using the Mac OS version of the tool chain. Maybe this has something to do with the issue?

[awatterott]

Looks like it is OS related, I used Win7 64bit for the building/testing and Tom also used Mac OS.

[facchinm]

Indeed, it looks like it's OS related. I'll spend some time investigating if there is any significant difference in the produced hex between OSX and other OSes