Atmega 32U4 SPI not working in release mode.

Go To Last Post
26 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear

 

I have a sample project based on atmega 32U4.

I use IéC and SPI link do send command to same sample component.

 

My program work fine in debug mode. I have to build it in release mode before integration into a bigger project.

 

In debug I have I2C and SPI working fine

In release mode, my program stopped at some spi transmit step.

 

#ifndef SPI_H_
#define SPI_H_

#include <avr/io.h>

#define DDR_SPI		DDRB
#define DD_MOSI		DDB2
#define DD_MISO		DDB3
#define DD_SCK		DDB1
#define DD_SS		DDB0

#define SPI_CLOCK_DIV4 0x00
#define SPI_CLOCK_DIV16 0x01
#define SPI_CLOCK_DIV64 0x02
#define SPI_CLOCK_DIV128 0x03
#define SPI_CLOCK_DIV2 0x04
#define SPI_CLOCK_DIV8 0x05
#define SPI_CLOCK_DIV32 0x06

#define SPI_MODE0 0x00
#define SPI_MODE1 0x04
#define SPI_MODE2 0x08
#define SPI_MODE3 0x0C

#define SPI_MODE_MASK 0x0C  // CPOL = bit 3, CPHA = bit 2 on SPCR
#define SPI_CLOCK_MASK 0x03  // SPR1 = bit 1, SPR0 = bit 0 on SPCR
#define SPI_2XCLOCK_MASK 0x01  // SPI2X = bit 0 on SPSR

void SpiInit(uint8_t rate, uint8_t mode);
unsigned char SpiTransmit(unsigned char data);
unsigned char SpiReceive(void);




#endif /* SPI_H_ */

 

#include "spi.h"

//SPI initialize for SD card
void SpiInit(uint8_t rate, uint8_t mode)
{
	static char cInitDone=0;
	
	if (!cInitDone){
		cInitDone =1;
		// Set MOSI, SCK, SS outputs
		DDR_SPI |= _BV(DD_MOSI) | _BV(DD_SCK);
		
		// Set inputs
		DDR_SPI &= ~_BV(DD_MISO);
		
		// Set Mode
		SPCR = (SPCR & ~SPI_MODE_MASK) | mode;
		
		// Enable SPI, Master
		SPCR |= _BV(SPE) | _BV(MSTR);
		
		// set clock rate
		SPCR = (SPCR & ~SPI_CLOCK_MASK) | (rate & SPI_CLOCK_MASK);
		SPSR = (SPSR & ~SPI_2XCLOCK_MASK) | ((rate >> 2) & SPI_2XCLOCK_MASK);
	}
}

unsigned char SpiTransmit(unsigned char data)
{
	// Start transmission
	SPDR = data;

	// Wait for transmission complete
	while(!(SPSR & (1<<SPIF)))
		data = SPDR;

	return(data);
}

unsigned char SpiReceive(void)
{
	unsigned char data;
	// Wait for reception complete

	SPDR = 0xff;
	while(!(SPSR & (1<<SPIF)));
	data = SPDR;

	// Return data register
	return data;
}

 

How can I edit it to work fine in release mode ?

 

Or how can I tell compiler to do it in debug temporaly.

 

Best regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you have spi transmit and receive functions but yet you got the transmit one wrong. You really only need one function.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK

 

I Think something is wrong but what ?

 

You suggest me to merge transmit and received ?

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your first step would be to check exactly what differences you have configured for the so-called "DEBUG" and "RELEASE" configurations.

 

Note that  "DEBUG" and "RELEASE" are just names; they have no specific meanings - you have to check how they are configured for your particular project, and you are free to adjust them however suits you best.

 

I have to build it in release mode before integration into a bigger project.

Why?

 

What is it about your so-called "DEBUG" configuration that is not suitable for integration?

 

 

SEE: https://www.avrfreaks.net/forum/multiple-firmware-build-configurations?skey=DEBUG%20RELEASE

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

benoitf92 wrote:
You suggest me to merge transmit and receive

Why did you think you need separate receive and transmit?

 

SPI is inherently full-duplex: as the Master is clocking stuff out to the slave, it will also be clocking stuff in from the Slave!

 

There is no way for the Master to receive stuff from the slave without providing a clock - and the only time it does that is while sending.

 

EDIT

 

Though why it should "work" (sic?) in the so-called "DEBUG"  configuration, but fail in "RELEASE" is an entirely different question!

 

Most likely a timing difference, I would guess ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Aug 25, 2017 - 09:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
	// Wait for transmission complete
	while(!(SPSR & (1<<SPIF)))
		data = SPDR;

vs

while(!(SPSR & (1<<SPIF)));
	data = SPDR;

The placement of the semicolon ; makes a big difference. Could be that your debug code was working but by the grace of God.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The placement of the semicolon ; 

 

I have tried it but no change.

 

Though why it should "work" (sic?) in the so-called "DEBUG"  configuration, but fail in "RELEASE" is an entirely different question!

 

 

This is my best question... I do not understand why.

 

I use default atmel studio configuration.

In release mode my full programm can fit into the memory in debug not

 

I have two part one with LUFA for USB communication

and one with I2C and SPI communication.

 

In release mode I encountered a problem with SPI.

SPIreceive is never called in the project. I only use SPItransmit. This two functions are here because I'm implementing communication with some ST chip. In the example they have this two functions.

 

Last Edited: Fri. Aug 25, 2017 - 10:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

benoitf92 wrote:
In release mode my full programm can fit into the memory in debug not

If the code size is different, then the timing will (almost) certainly be different.

 

RAM usage & placement may also differ.

 

You're just going to have to look at the settings in the so-called "DEBUG"  configuration, and see how they differ from "RELEASE"

 

Most likely, the optimisation level is a key difference ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have done some tests on optimizations

 

Full project

Release Optimize for size -Os

Program Memory Usage       :      14024 bytes   42,8 % Full

Data Memory Usage          :      2441 bytes   95,4 % Full

  • Block at spitransmit

 

Release None (-O0)

Program Memory Usage       :      36038 bytes   110,0 % Full (Memory Overflow)

Data Memory Usage          :      2439 bytes   95,3 % Full

 

Release Optimize (-O1)

Program Memory Usage       :      16082 bytes   49,1 % Full

Data Memory Usage          :      2439 bytes   95,3 % Full

  • Block at spitransmit

 

Only one part

 

Debug mode

Program Memory Usage       :      17270 bytes   52,7 % Full

Data Memory Usage          :      649 bytes   25,4 % Full

 

Release None (-O0)

Program Memory Usage       :      17270 bytes   52,7 % Full

Data Memory Usage          :      649 bytes   25,4 % Full

 

Release Optimize (-O1)

 

Program Memory Usage       :      4594 bytes   14,0 % Full

Data Memory Usage          :      649 bytes   25,4 % Full

 

Does it exist one way to compile only spi code in debug or without optimization ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

benoitf92 wrote:
In release mode I encountered a problem with SPI. SPIreceive is never called in the project. I only use SPItransmit. This two functions are here because I'm implementing communication with some ST chip. In the example they have this two functions.  

but your SPITransmit function is faulty.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

but your SPITransmit function is faulty.

 

How can I correct it ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
your SPITransmit function is faulty.

Almost invariably, if changing the optimisation level "breaks" (sic) some code, it is because the code is faulty.

 

In other words, the code "works" (sic) only by luck.

 

As already noted, one common cause is timing.

 

Another is improper use (especially, non-use) of the 'C'  volatile keyword...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
while(!(SPSR & (1<<SPIF)));
	data = SPDR;
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have already that:

while(!(SPSR & (1<<SPIF)));
	data = SPDR;

I have  the semi columns but any change 

 

I understand that I have a mistake in my SPI function now I have:

void SpiInit(uint8_t rate, uint8_t mode)
{
	static char cInitDone=0;
	
	if (!cInitDone){
		cInitDone =1;
		// Set MOSI, SCK, SS outputs
		DDR_SPI |= _BV(DD_MOSI) | _BV(DD_SCK);
		
		// Set inputs
		DDR_SPI &= ~_BV(DD_MISO);
		
		// Set Mode
		SPCR = (SPCR & ~SPI_MODE_MASK) | mode;
		
		// Enable SPI, Master
		SPCR |= _BV(SPE) | _BV(MSTR);
		
		// set clock rate
		SPCR = (SPCR & ~SPI_CLOCK_MASK) | (rate & SPI_CLOCK_MASK);
		SPSR = (SPSR & ~SPI_2XCLOCK_MASK) | ((rate >> 2) & SPI_2XCLOCK_MASK);
	}
}

unsigned char SpiTransmit(unsigned char data)
{

	// Start transmission
	SPDR = data;

	// Wait for transmission complete
	while(!(SPSR & (1<<SPIF)));
	data = SPDR;

	return(data);
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have retry all in debug and it is working fine,.

 

Doies it exist a way to compile only the spi init and communication function in debug without any optimization and all teh rest with optimization ?

 

I think about #pragma GCC optimize

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you not read #12?

 

If the code doesn't work, it is because there's a fault in your code.

 

You need to fix the fault - not just mask the symptoms.

 

No automatic alt text available.

 

Have you looked at what is actually happening on the SPI wires - with an oscilloscope or logic analyser or similar ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note that there is nothing to stop you using the debugger on code built with the so-called "RELEASE" configuration.

 

You would want to enable Debug Info - that won't affect the size of the actual executable at all.

 

The optimisation might make the code flow a little harder to follow - but it is still doable.

 

As the whole point of SPI is that it is a physical interface between chips, you need to be looking at the signals on the wires - look what happens with the "working" build, and compare to what happens with the non-working build.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

benoitf92 wrote:

Debug mode

Program Memory Usage       :      17270 bytes   52,7 % Full

Data Memory Usage          :      649 bytes   25,4 % Full

 

Release None (-O0)

Program Memory Usage       :      17270 bytes   52,7 % Full

Data Memory Usage          :      649 bytes   25,4 % Full

So you are using -O0 for your "Debug" configuration.

 

You really don't want to do that:

 

 

 

In another thread (repeating what is very frequently stated), JohanEkdahl wrote:

MarkThomas wrote:

For debugging, do we choose optimization -O0 [...]?

 

No, -O0 is more or less meaningless since the generated code is very far from what any of the other optimization settings will produce. Highly inefficient code. Call it de-generated code if you like.

 

:

:

 

stay away from -O0. It has been said that it is nothing but a (non-)optimization level that only the compiler developers has any use of. The code generated is horrible.

 

https://www.avrfreaks.net/comment...

 

 

And, in another thread, N.Winterbottom wrote:
We have -Og now; introduced in upstream gcc 4.8

 

Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience.

 

https://www.avrfreaks.net/comment...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

Have you looked at what is actually happening on the SPI wires - with an oscilloscope or logic analyser or similar ... ?

 

awneil wrote:

As the whole point of SPI is that it is a physical interface between chips, you need to be looking at the signals on the wires - look what happens with the "working" build, and compare to what happens with the non-working build.

 

I will look to the SPI signal today. It's a little bit hard, this signals are not simple to access in my board...

 

But I will do that to understand whats happenned

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear,

I have looked to my signals with my scope today.

 

Question 1: I have good code with optimization –O0 (none) but with any optimization like –O1 –O2 with can have any clock on SPI clock line. I cannot understand why but we have check that with oscilloscope. How can I solve that?

 

Question 2: To put all my code in the micro controller I need some optimization, I have put for global setting –O0 but I have add by hand custom setting –O3 on all C files for my USB stack. With this I can put all the code in the flash, but the USB stack is not working.

We have discover that we use only 1800, 1900 bytes in ram but some bytes are overwritten, or some overflow exists. The compiler does not through any errors. How can I solve that properly? The component has 2560 bytes for ram.

We have transfer some data in flash via const uint32_t PROGMEM command but is it good?

How could I tell the compiler to better optimize code and ram memory?

 

Question 3: With –O3 optimization some part of my code are bigger than with –O0 optimization is it normal ?

Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All the views and responses, and no-one has commented on:

 

benoitf92 wrote:
Full project Release Optimize for size -Os Program Memory Usage : 14024 bytes 42,8 % Full Data Memory Usage : 2441 bytes 95,4 % Full Block at spitransmit Release None (-O0) Program Memory Usage : 36038 bytes 110,0 % Full (Memory Overflow) Data Memory Usage : 2439 bytes 95,3 % Full Release Optimize (-O1) Program Memory Usage : 16082 bytes 49,1 % Full Data Memory Usage : 2439 bytes 95,3 % Full Block at spitransmit

As mentioned, >>you<< need to examine the different compiler options.  The "DEBUG" numbers show a fraction of that Data Memory usage.  If I had to make a wild guess, constant strings aren't being stored in flash in the RELEASE configuration.

 

Anyway, with Data Memory that full you will very probably run into stack overflow problems.  The numbers looked strange to me -- then I looked at the datasheet.  LOL -- that model series indeed has 1.5KB/2.5KB of SRAM.  The numbers give you about 120 bytes for stack usage.  OK in a "flat" app, but could quickly be exhausted in a "full" app, especially if e.g. functions called from ISRs.

 

Find out where your missing 1+KB of SRAM is going.  The map will help.

 

[There are some apps to try to estimate stack usage in a GCC app.]

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

benoitf92 wrote:

 

Question 3: With –O3 optimization some part of my code are bigger than with –O0 optimization is it normal ?

 

 

First of all, get out of your head the thought of using -O0 for any real work.  Just don't.

 

Re -O3, what does the documentation say?

-O3

Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize and -fipa-cp-clone options.

Well, yeah, if you do those optimizations to improve speed they may well do so at the expense of code space.

 

For general work, -Os is a very good starting spot.  Don't even THINK about -O0 unless you are debugging the compiler with a trivial test app.

 

Depending on your test methods, many will suggest using -Og.

 

https://stackoverflow.com/questi...

 

To be pedantic, there are 8 different valid -O options you can give to gcc, though there are some that mean the same thing.

The original version of this answer stated there were 7 options. GCC has since added -Og to bring the total to 8

From the man page:

  • -O(Same as -O1)
  • -O0(do no optimization, the default if no optimization level is specified)
  • -O1(optimize minimally)
  • -O2(optimize more)
  • -O3(optimize even more)
  • -Ofast(optimize very aggressively to the point of breaking standard compliance)
  • -Og(Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience.)
  • -Os(Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size. -Os disables the following optimization flags: -falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays -ftree-vect-loop-version)

There may also be platform specific optimizations, as @pauldoo notes, OS X has -Oz

I'm not a Gcc guru so I don't know if all of the above apply to AVR.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Tue. Aug 29, 2017 - 09:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

benoitf92 wrote:
–O1 –O2 with can have any clock on SPI clock line. 

Sorry, that makes no sense - please rephrase!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

/SS handling?

// Set MOSI, SCK, SS outputs
		DDR_SPI |= _BV(DD_MOSI) | _BV(DD_SCK);

Do you see what is wrong with that picture?

 

Reverting to slave mode explains your "blocking" situation.  (the comments on Data Memory and optimization level still stand)

 

See the datasheet:

If SS is configured as an input, it must be held high to ensure Master SPI operation. If the SS pin is driven
low by peripheral circuitry when the SPI is configured as a Master with the SS pin defined as an input, the SPI
system interprets this as another master selecting the SPI as a slave and starting to send data to it. To avoid
bus contention, the SPI system takes the following actions:
1. The MSTR bit in SPCR is cleared and the SPI system becomes a Slave. As a result of the SPI becoming a Slave, the MOSI and SCK pins become inputs.
2. The SPIF Flag in SPSR is set, and if the SPI interrupt is enabled, and the I-bit in SREG is set, the interrupt
routine will be executed.
 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What SPI slave are you trying to communicate with?  It would be very unusual to do SPI operations without a chip-select.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
with Data Memory that full you will very probably run into stack overflow problems

As I understand it, those numbers are for the "full" project; but the problem also appears in just the "one part" - where the RAM usage is only  649 bytes   (25,4 % Full) - so stack should not be a problem there?

 

But the OP could clarify that ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...