Marc's Public Blog - Arduino Hacking


All | Aquariums | Arduino | Btrfs | Cars | Cats | Clubbing | Computers | Dining | Diving | Electronics | Exercising | Festivals | Flying | Halloween | Hiking | Linux | Linuxha | Monuments | Museums | Outings | Public | Rc | Sciencemuseums | Solar | Tfsf | Trips



Table of Content for arduino:

More pages: August 2023 June 2023 May 2023 March 2022 January 2022 December 2020 March 2020 January 2020 May 2019 April 2019 March 2019 January 2019 July 2018 May 2018 April 2018 January 2018 June 2017 April 2017 January 2017 February 2016 January 2015 September 2013 January 2012 December 2011 May 2011 January 2011



2011/12/12 GCC-AVR-4.5.3-2 Breaks Arduino NewSoftSerial
π 2011-12-12 01:01 in Arduino
Dear Google, please index this.

TL;DR: gcc-avr 4.5.3 breaks Arduino NewSoftSerial on 328p. I had to downgrade back to 4.3.5.

Full story:
I had my arduino mobsendat board (328P based) working fine and after uploading some changes, it startsending a few of my characters over my Xbee, mixed with garbage. Most characters actually seemed lost.

  • https://github.com/lukeweston/RocketInstrumentation/blob/master/RocketInstrumentation-board.png
  • https://github.com/lukeweston/RocketInstrumentation/blob/master/RocketInstrumentation-schematic.png
  • In other words, I got less traffic than I should, a few were original characters, and some were garbage on a board and Xbee that were sending traffic at 38,400bps just fine for the last year.

    I used my xprotolab to decode the sending pin on the xbee directly to rule out RF issues, and I see the garbage there too. If you want to know what I mean, look at the last picture on http://www.gabotronics.com/product-info/xprotolab-pictures.htm

    So I was bit confused. The Xbee worked fine separately from the board and the serial bits getting to the xbee pins were damaged before they were sent on a simple program like this:

    #include <NewSoftSerial.h>
    

    const int XBEE_SLEEP = 8; // pin 14

    NewSoftSerial mySerial = NewSoftSerial(2, 3);

    void setup(void) { Serial.begin(38400); mySerial.begin(38400); // Switch pin to digital mode with pullup. pinMode(XBEE_SLEEP, OUTPUT); digitalWrite(XBEE_SLEEP, LOW); while (1) { Serial.println("AB12"); mySerial.println("AB12"); delay(1000); } }

    void loop(void) { }

    Arduino IDE is 0.22ubuntu0.1 on ubuntu oneiric. I thought that maybe an update to the arduino IDE broke it when I went from ubuntu marverick/natty to oneiric, but that wasn't it.

    Then I thought that maybe I damaged my hardware (maybe the clock/crystal is messed up, but then I suppose serial over USB wouldn't work either, and it does work), or if upgrading ubuntu recently broke NewSoftSerial in some subtle way, but I verified I had NewSoftSerial 10, and upgrading to 11 beta did not help.

    This is where it got wild: if I listened to the serial traffic going to the xbee from NewSoftSerial (I had version 10), and if I used the RX UART decoding pin of my Xprotolab, it could see the traffic ok. If I used the TX pin on the Xprotolab, then the same traffic mostly looked like garbage (actually most characters were lost). Putting 2 stop bits did not help.

    I talked to Gabriel Anzziani who made the Xprotolab and he said 'The RX and TX decoding are done differently in the Xprotolab. The RX is done by the XMEGA hardware, and the TX is done in firmware.'

    So clearly, there was a timing issue in what NewSoftSerial was doing at 38400 even though it had worked with the same NewSoftSerial library for about a year and NewSoftSerial 11 did not help.

    So, out of desperation, I took the nfs backup from my laptop before I upgraded from ubuntu maverick to ubuntu oneiric. While it was a bit hard to get the arduino IDE to work over an NFS chroot, I eventually got it to run, compile and upload my same Hello world serial program. And it worked!

    From there, it took a binary search to pin this down to the gcc-avr upgrade.

    gandalfthegrey:/var/local/src/arduino# dpkg -i gcc-avr-4.3.5-1.deb
    dpkg: warning: downgrading gcc-avr from 1:4.5.3-2 to 1:4.3.5-1.
    Yes, that really was the fix :(

    My guess is that the new gcc-avr changes some compilation timings/optimizations in a way that NewSoftSerial breaks :(


    More pages: August 2023 June 2023 May 2023 March 2022 January 2022 December 2020 March 2020 January 2020 May 2019 April 2019 March 2019 January 2019 July 2018 May 2018 April 2018 January 2018 June 2017 April 2017 January 2017 February 2016 January 2015 September 2013 January 2012 December 2011 May 2011 January 2011

    Contact Email