Issues getting ATtiny2313/4313 hardware serial to work properly

I'm using an Arduino UNO R3 as a programmer for the ATtiny4313 and an Arduino Nano v3.0 to communicate with the ATtiny4313 over hardware serial using RX and TX pins on both Nano and ATtiny4313.

Connections ATtiny4313 Datasheet: http://www.atmel.com/images/doc8246.pdf

|500x307

My Problems Information sent from the ATtiny4313 is garbled at all baud rates

|500x164

Information sent to the ATtiny4313 doesn't work at all. On the ATtiny4313 Serial.available() is always true and Serial.read() is always empty.

Enviroment The ATtiny4313 is running at 8mhz (Internal Clock)

I'm using the Arduino 1.6.3 IDE with the https://code.google.com/p/arduino-tiny/ addon for Arduino 1.5. I've tried several other Arduino IDE versions to no avail.

TX Sketch ATtiny4313

void setup(){
    Serial.begin(9600);
}
void loop(){
    Serial.println("Test"); // Ends up garbled on the other end for some reason
    delay(1000);
}

RX Sketch ATtiny4313

void setup(){
    Serial.begin(9600);
}
void loop(){
    if(Serial.available()){ // Always true for some reason
        char c = Serial.read(); // Always empty for some reason
        Serial.print(c);
    }
}

TX Sketch Arduino Nano

void setup(){
    Serial.begin(9600);
}
void loop(){
    Serial.println("Test"); // Works as intended but empty on ATtiny4313
    delay(1000);
}

RX Sketch Arduino Nano

void setup(){
    Serial.begin(9600);
}
void loop(){
    if(Serial.available()){ // Works as intended
        char c = Serial.read(); // Works as intended but garbled due to ATtiny4313 issue
        Serial.print(c);
    }
}

My primary goal is to get the ATtiny4313 to interface with an ESP8266 using the RX and TX pins, for this the baud rate needs to be 9600 and reliable. The RX issue with the ATtiny4313 acts as if the RX pin is disabled or something... I've looked everywhere for an answer with no success and I've tried everything I can think of to get this working properly but I've run out of ideas. Any help would be greatly appreciated.

Looks like the internal oscillator is so far off of the target speed that UART comms fails. Search these forums for more information in calibrating or "tuning" the oscillator to get more accurate speed.

This is often a problem on some atmel chips (I've yet to encounter a tiny841 or 1634 that had UART problems on internal oscillator, but others talk about the 328, '84, and '85 failing more often than not)

Have you loaded the Blink example to the 4313 and does it blink at the desired rate?

justone: Have you loaded the Blink example to the 4313 and does it blink at the desired rate?

Yes, as far as I can tell it blinks every second with delay = 1000ms

In your fritzing circuit you don't have the Nano ground going to the common ground of the breadboard.

That is the ground of the Nano must be tied to the ground of the 4313.

justone: In your fritzing circuit you don't have the Nano ground going to the common ground of the breadboard.

That is the ground of the Nano must be tied to the ground of the 4313.

That was one of the first things I tried it didn't make a difference unfortunately.

As others has already said, you should try to tune your internal oscillator. I have tried your sketch on a tuned ATtiny2313, and it just works as expected.

I have made some notes about the tuning proces:

Tuning tips

Note: you cannot use my OSCCAL value, it will be different for all chips.

void setup(){
    OSCCAL = 0x52;
    Serial.begin(9600);
}
void loop(){
    if(Serial.available()){ // Always true for some reason
        char c = Serial.read(); // Always empty for some reason
        Serial.print(c);
    }

Erni: As others has already said, you should try to tune your internal oscillator. I have tried your sketch on a tuned ATtiny2313, and it just works as expected.

I have made some notes about the tuning proces:

Tuning tips

Spent hours trying to get this to work it... It outputs the following in the serial monitor.

|500x267

Sending x doesn't do anything. (No, I'm not using quotes around the x lol).

I can't use SoftwareSerial because the ATtiny4313 doesn't have any analog pins that I'm aware of.

The TinyTuner doesn't support the ATtiny4313 I had to add definitions for it which are probably wrong (Copied and renamed the definitions for the ATtiny2313)

The good news is TX on the ATtiny4313 now works properly after manually changing OSCCAL from 0x4D to 0x4B but RX on the ATtiny4313 still doesn't seem to work...

Any thoughts?

I’d try 0x4C, 0x4A and 0x49 and see if that fixes receiving. :stuck_out_tongue:

You could try TinyTuner2, that's what I did.

It has a very positive side effect, namely that you then would have Tinyknockbang as a debugging tool.

Erni: You could try TinyTuner2, that's what I did.

It has a very positive side effect, namely that you then would have Tinyknockbang as a debugging tool.

Ok so TinyTuner2 gave me results telling me to set OSCCAL = 0x4A; while this fixes the TX issue RX still fails to work.

Now Serial.available() starts off false and once data is sent to the RX pin it goes into a loop. Serial.read() always returns 0 (or empty if converted to a char). It's acting like its holding the data for it to be processed but never sends it to Serial.read()...

Tiny Core was very thoroughly tested. Except, unfortunately, HardwareSerial for the x313 family of processors. You very likely have crossed paths with a bug. The most likely culprit is the size of the receive buffer. At one point it was larger than the entire SRAM of the t2313 processor. (It may still be.)

One problem with the Arduino-way of managing the serial port for ATtiny processors is the need for a largish receive buffer. I had hoped to develop a model / example that could eliminate the need for the buffer. As you have discovered, my interest drifted away from the x313 family before I finished.

Why the t4313 processor? Other than cost, the m328 is a far better choice.

[quote author=Coding Badly date=1432331355 link=msg=2243839] Why the t4313 processor? Other than cost, the m328 is a far better choice. [/quote]

I agree with that in most cases but I chose the 4313 for a several reasons.

  • I had extra 20 pin dip sockets laying around
  • The 4313's were free =P
  • Since it had hardware serial I assumed it would be easier to just plug in and go to communicate through the TX and RX pins lol
  • 20 pins fits inside my project better than 32 pins would have
  • The 4 PWM pins on the 4313 were perfect for my project since I need 3 for the RGB LED I'm going to be using and 1 for the MOSFET I'll be controlling.

I'll mess around with the tiny core and see if I can't adjust the buffer to get it working. I got it working using another method but it has some kinks that have to be worked out first which is why I haven't posted a success post yet.

Hopefully you regain interest in the x313 family I'd hate for someone else to go through this lol.

cmarie: I agree with that in most cases but I chose the 4313 for a several reasons.

Thank you for the details.

I'll mess around with the tiny core and see if I can't adjust the buffer to get it working.

For the buffer size, this is the place of interest... https://code.google.com/p/arduino-tiny/source/browse/cores/tiny/HardwareSerial.cpp#37

I suggest trying something significantly smaller like 4 or 8.

Hopefully you regain interest in the x313 family I'd hate for someone else to go through this lol.

I do apologize for the trouble you are having to endure.

The ATtiny4313 is running at 8mhz (Internal Clock)

After selecting that board, did you run Tools / Burn Bootloader to change the fuses?

[quote author=Coding Badly date=1432341925 link=msg=2243986] For the buffer size, this is the place of interest... https://code.google.com/p/arduino-tiny/source/browse/cores/tiny/HardwareSerial.cpp#37

I suggest trying something significantly smaller like 4 or 8. [/quote]

I've set RX_BUFFER_SIZE to the suggested values with no success. The t4313 has 256 Bytes Internal SRAM so the default values 32 or 128 seem within those specs right?

[quote author=Coding Badly date=1432341925 link=msg=2243986] After selecting that board, did you run Tools / Burn Bootloader to change the fuses? [/quote]

Correct, I set the fuses using burn bootloader and F_CPU outputs 8000000

I used the default fuses

attiny4313at8.bootloader.low_fuses=0xE4
attiny4313at8.bootloader.high_fuses=0x9F
attiny4313at8.bootloader.extended_fuses=0xFF

cmarie: I've set RX_BUFFER_SIZE to the suggested values with no success.

Bummer.

The t4313 has 256 Bytes Internal SRAM so the default values 32 or 128 seem within those specs right?

I agree. The original value was very likely fine.

Correct, I set the fuses using burn bootloader and F_CPU outputs 8000000 I used the default fuses

Yeah, those look fine.

On your wiring diagram, there is no ground connection between the Nano and the t4313. Is that correct? (There should be three wires between the Nano and the t4313.)

[quote author=Coding Badly date=1432355034 link=msg=2244113] On your wiring diagram, there is no ground connection between the Nano and the t4313. Is that correct? (There should be three wires between the Nano and the t4313.)

[/quote]

Yeah, I should mention I've moved away from the Nano so I'm only using the UNO now. While I didn't have any issues with common ground between the two before (they were both connected to the same power source) I just felt my results would be more reliable using just 1 device.

The steps I take are:

  • Upload the Arduino ISP sketch to the UNO
  • Upload a simple serial echo sketch I made to the ATtiny4313
  • Then upload a blank sketch (BareMinimum) to the UNO for direct serial communication between the PC and the ATtiny4313. This has a reversal effect on the serial pins TX becomes RX and RX becomes TX on the UNO. I've used this method to communicate between Arduino's and the ESP8266 in the past without any issues.

Side thought... Since the TX works and Serial.available() becomes constantly active once a byte is received I'm left to believe the software aspect of it is seeing data coming in but handling it improperly. I don't believe it's a buffer size issue but maybe some kind of buffer population issue. But I don't know this stuff is beyond me lol.

Hopefully this helps somehow

I do not know if this is still relevant, but forum member hiduino found several years ago an error in the header file for attiny 2313

And he provided a solution:

http://forum.arduino.cc