ATtiny85 garbage serial coms even with external clock

Other Hardware 3rd Party Boards
1

Ok im pretty new to all of this but ive been working on this all night and after trying a million things I am pretty much stumped.

My problem is that I cannot get the serial communication to work. With a simple sketch that blinks an LED and writes a message to the serial output every loop I just get a repeating serial read of garbage characters (always the same characters for a given message though).

I have this programmer -> https://www.sparkfun.com/products/11801

Im using the ATtiny85

Im using this USB-to-Serial RS232 5v converter (I use this adapter all the time on other hardware with no issues)-> USB to Serial Adapter - Works seamlessly with TunerStudio

Ive tried this code base -> Google Code Archive - Long-term storage for Google Code Project Hosting. as well as this one -> GitHub - damellis/attiny: ATtiny microcontroller support for the Arduino IDE

Ive tried every baud rate

Ive tried 1mhz, 8mhz internal clocks (yes I burned the bootloader each time)

Ive tried TinyTuner with no avail, I can't get any readable serial data so I can't see what its doing nor can I get the OSCCAL value.

Ive tried an external 16mhz clock and burned the bootloader for this as well and still the same garble.

Ive tried attiny85-TX on pins 2,3,4

Ive tried on my MAC and on my windows computer

Ive tried viewing the data with the arduino viewer, hyperterm, and coolterm

Ive tried reversing the RX, TX wires

Ive tried arduino IDE 1.06, 1.5.8, and 1.6

Here is one version of the sketch I was using, ive set it up for different pin configurations and other variances. I also get the garbage serial data with Tiny Tuner so I know its not a sketch problem.

#include <SoftwareSerial.h>

/*
  Blink
  Turns on an LED on for one second, then off for one second, repeatedly.

  Most Arduinos have an on-board LED you can control. On the Uno and
  Leonardo, it is attached to digital pin 13. If you're unsure what
  pin the on-board LED is connected to on your Arduino model, check
  the documentation at http://arduino.cc

  This example code is in the public domain.

  modified 8 May 2014
  by Scott Fitzgerald
 */
const int rx=-1;
const int tx=2;
SoftwareSerial mySerial(rx, tx);
// the setup function runs once when you press reset or power the board
void setup() {
  //pinMode(rx, INPUT);
  pinMode(tx, OUTPUT);
  mySerial.begin(9600);                    // connect to the serial port
  mySerial.println("1");
  // initialize digital pin 13 as an output.
  pinMode(0, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
  mySerial.println("123");
  digitalWrite(0, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);              // wait for a second
  digitalWrite(0, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);              // wait for a second
}
2 
const int rx=-1;

You have a processor with a pin numbered minus one? What sort of crazy beast is that thing?

3

That was just on my last attempt when I switched to an external clock. I was using pin 3, 4 for rx/tx but had to use those for the clock so I switched tx over to pin2 and disabled rx by setting it to negative 1.

4

...and disabled rx by setting it to negative 1.

That does not disable receive. It essentially corrupts the state of your sketch.

Have you tried using TinyDebugSerial?

5

The -1 didn't seem to have any adverse effects (issue was the same as always) but ill refrain from using that again. I had read somewhere that it was acceptable.

I tried to read up on the TinyDebugSerial, as far as I could understand it is built into this core -> Google Code Archive - Long-term storage for Google Code Project Hosting. and you just use the "Serial()" syntax.

I tried that just now and its still not working

I used this sketch at 8mhz with the arduino-tiny core loaded to the attiny85

void setup() {
  //pinMode(rx, INPUT);
  //pinMode(tx, OUTPUT);
  Serial.begin(9600);                    // connect to the serial port
  Serial.println("1");
  // initialize digital pin 13 as an output.
  pinMode(0, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
  Serial.println("123");
  digitalWrite(0, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);              // wait for a second
  digitalWrite(0, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);              // wait for a second
}

and all I get is "g≥≥9=" (sometimes "g≥≥π=") repeating every time the loop runs, same as always. The led blinks normally at 1second intervals.

I can also bridge the rx/tx on the rs232 converter and when I send a character with the serial monitor it echos back normally.

6

I just did another test using print() instead of println. Sending a "1" gives me a "g", sending a "2" gives me a "3" and sending a "3" gives me an "f". Not sure if that indicates anything, but it seems to be consistent at least.

7

1 is 0x31, g is 0x67
2 is 0x32, 3 is 0x33
3 is 0x33, f is 0x66

0b00110001 -> 0b01100111 (how'd this happen???)
0b00110010 -> 0b01100011 (Okay, this is plausible)
0b00110011 -> 0b01100110 (straight up left bit shift)

8

I used this sketch at 8mhz...

How do you know it is running at 8 MHz?

Im using this USB-to-Serial RS232 5v converter (I use this adapter all the time on other hardware with no issues)

Found on a Megasqirt site...

MS2 and Microsquirt use RS232 serial communications for tuning with a standard DB9 female connector.

You have the wrong serial converter. The one you have will very likely damage the AVR processor. If it is not already damaged.

9

I understand that the internal oscillator could be off but I assume its running at the "selected" 8mhz because I burned the bootloader to that and the LED blinks at a 1sec interval whereas if I compile for a different clock without burning the bootloader for that clock then the LED will blink much faster or slower. I also tried using an external 16mhz clock though and burned the bootloader for that, I verified it was using the external clock by disconnecting the oscillator and the blink program stopped running.

Well that would explain it lol, I was under the impression that rs232 was 5v high 0v low but a little reading explains otherwise. I thought I had read of other people using a similar one but I think I was getting it confused with the FTDI unit which I think I have laying around somewhere actually.

I think the AVR is fine, it seems to work well otherwise still. I bought 5 of them so no biggie if I fried it, just part of learning I guess.

Ill try to find my FTDI cable and report back

Thanks

10

Ok I couldn't find my FTDI cable but I had an HC-06 bluetooth to serial module laying around so I got it working with that. All is well now and serial comms work great! After using Tiny Tuner I am getting a value of 0x4E for my timing calibration which seems pretty far off, im assuming 0x80 is a perfect internal cal?

Interesting side note. I was trying to find a different way to calibrate the OSCCAL without needing serial feedback so I wrote a program that measured a frequency on an input pin. I set it to blink the led corresponding to the multiple of 10 of the frequency (50hz = 5blinks). Then I set an external controller up to send a pwm frequency to the attiny85. I kept changing the OSCCAL until 49hz would give me 4blinks and 50hz would give me 5blinks. At the time I thought it didn't work because my serial comms still weren't working but the interesting thing is that I came up with 0x4E as the optimal cal, which lines up exactly with what the Tiny Tuner gives me now that the serial is working :slight_smile:

11

CSXRT4:
Ok I couldn't find my FTDI cable but I had an HC-06 bluetooth to serial module laying around so I got it working with that. All is well now and serial comms work great!

Excellent.

After using Tiny Tuner I am getting a value of 0x4E for my timing calibration which seems pretty far off, im assuming 0x80 is a perfect internal cal?

The calibration is split into two ranges: 0 through 127 then 128 through 255. The two ranges overlap quite a bit. For any value in the lower range there is very likely a value in the upper range that gives a similar tune. The ideal calibration depends on manufacturing characteristics, individual processor variations, internal temperature #, and supply voltage.

But the ideal calibration follows the charts from the datasheet fairly closely. Search for "Calibrated 8 MHz RC Oscillator Frequency vs. OSCCAL Value" in the datasheet.

Interesting side note. I was trying to find a different way to calibrate the OSCCAL without needing serial feedback...

Tiny Tuner 2 uses a signal from an Arduino compatible board configured to function as a programmer. In addition to not needing a serial port it gives slightly more accurate results.

...so I wrote a program that measured a frequency on an input pin. ...

Excellent plan. A similar technique can be used to find the ideal OSCCAL value over a range of temperature / supply voltages.

...the interesting thing is that I came up with 0x4E as the optimal cal, which lines up exactly with what the Tiny Tuner gives me now that the serial is working :slight_smile:

Nice.

# Programming the processor slightly raises the internal temperature. If you continue to tune, as the processor cools to near room temperature, you will notice the OSCCAL value often changes a bit.

12

Good digging.