Loading over serial issue's

I've created a custom arduino board, using the atmega16u2 serial (SMT), and the atmega328 (not p).

I've copied the wiring for both chips to the letter, I've confirmed through programmer arvisp mkII and atmel studio 6, that I can read and load to both chips, and voltages are 5v, no issue.

When you try to load over serial, the RX led blinks 2-3 times, reset goes off, then the upload stalls and it says that it was unresponsive.

I've confirmed good continuity on the rx/tx lines, there pulled high, the 328 rx goes to the serial tx, and vis verse as listed in the schematic.

I suspect its a boot loader issue, I've used:

"Arduino-usbserial-atmega16u2-Uno-Rev3.hex", from the arduino 1.01 firmware folder, the computer accepted this and assigned it a com port number.

On the atmega328 I used "ATmegaBOOT_168_atmega328.hex" from the bootloaders.

I don't know much yet about how to set the fuse options if even required?

What are the proper bootloaders and settings for setting up the chips?

You probably need to set the fuses. The default for the Atmega328 is to have the "divide by 8" clock bit set.

See this: http://www.gammon.com.au/forum/?id=11637

After more trouble shooting it still doesn't work but I'm not all but certain its the serial chip.

I've loaded code onto the 328 and tested outputs, and even did a i2c arduino to arduino test to success.

My computer accepts it as a arduino serial connection Rev3 with an assigned com port, but when you do a serial upload, the rx led on the serial chip blinks 3 times (its looking for synconization) but doesn't get it. So it times out with error sync 0x00...

It seem so unlikely but is it a simply rx/tx lines in backwards?

My next best idea is I have the wrong crystal in my fuses, but that can't be true cause then my chip wouldn't connect via serial to the computer, and I have a perfect dc offset sign wave on the crystal, via scope while powered on.

I assumed I use the uno board in the programmer as I'm using atmega16us and a atmega328 (same as uno)?

Any solutions to sync errors?

My next best idea is I have the wrong crystal in my fuses, but that can't be true cause then my chip wouldn't connect via serial to the computer, and I have a perfect dc offset sign wave on the crystal, via scope while powered on.

I'm not sure what you are saying there. Can you detect the fuse setings please?

As I already said it programs fine when done directly from the programmer. I can see and modify anything.

My theory was that I had selected the wrong crystal/with time delay and that was causing irregularities.

Anyway, I did a feed backloop test and it passed, thus the serial chip is fine, so it must be the arduino chip not responding properly. You can manually load to it a program, and all the inputs and i2c work, it just doesn't seem to talk back to the serial chip when I put a bootloader on it.

Why? I have no idea.

I've got an idea. Fuse settings. See my earlier reply.

If you program using the ICSP programmer (the AVRISP MkII) then the clock settings are not critical. It will certainly program at 1 MHz because it uses the ICSP clock pulses.

If you program via the bootloader the clock has to be right because that is using async serial which is not externally clocked.

You can manually load to it a program, and all the inputs and i2c work, it just doesn't seem to talk back to the serial chip when I put a bootloader on it.

OK, manually load up a comms program like the example 04.Communication -> ASCII Table.

Run it. See if the output comes out at the correct baud rate, or if you have to divide the baud rate by 8 in the serial monitor to not see gibberish.

harddrive123:
As I already said it programs fine when done directly from the programmer.

Can you see the fuses? How about reporting what they are?

On the atmega328 I used "ATmegaBOOT_168_atmega328.hex" from the bootloaders.

What "board type" are you calling your board? For it to be an "Uno", you need to have used optiboot. If you're using ATmegaBOOT, you should call it a "Duemilanove w/ ATmega328"

Fuses:
BODLEVEL: disabled (using non p 328, its apparently not required either way)
SPIEN : Yes
BootSZ: 256W_3f00
Bootrst: yes
SUT_CKSEL : EXTXOSC_8MHZ_XX_16KCK_14CK_65MS

Extended: 0xFF
HIGH: 0xDE
LOW: 0xFF

No Lock Bits

I've tried several boards with several bootloaders. The serial chips seems to be trying to send 3 rx sync pulses to which the bootloader is suppose to pulse tx back in unison before upload can begin, but the tx in every test is dead. I've shorted on it to make sure it physically works (it does). I've physically confirmed the electrical connection from the chips.

I loaded a simple Serial.println("hi"); delay(250); onto the chip on 9600, the tx line does work and serial is receiving it but its not coming out on the com window properly. Its printing this exact symbol ò . Changing the baud rate down shrinks the font, higher baud rate makes it print in larger font of the same symbol.

Because the feed back loop test worked it would seem that the arduino atmega328 is whats wrong, this isn't bootloader, this is code directly loaded to memory from a hex file through the programmer.

What crystal do you have connected?

16Mhz cystal on serial chip

16Mhz crystal on atmega328

harddrive123:
I loaded a simple Serial.println("hi"); delay(250); onto the chip on 9600, the tx line does work and serial is receiving it but its not coming out on the com window properly. Its printing this exact symbol ò . Changing the baud rate down shrinks the font, higher baud rate makes it print in larger font of the same symbol.

How did you write this simple sketch? In the Arduino IDE? If so what was the target board when you compiled it?

harddrive123:
I loaded a simple Serial.println("hi"); delay(250); onto the chip on 9600, the tx line does work and serial is receiving it but its not coming out on the com window properly. Its printing this exact symbol ò . Changing the baud rate down shrinks the font, higher baud rate makes it print in larger font of the same symbol.

I don't understand this bit. Doesn't the serial monitor have a fixed font? How can it get larger and smaller?

That's what happened, my best guess is the binary equivalency of a messed up "hi" is equal to that symbol, changing the baud rate by chance or something just matched to different the different sizes or there is a font protocol in serial (seems like it could). I don't care.

After more testing here is what I've found.

The feed back loop passes, no 328 in socket, rx on tx, type anything and it comes back perfect on serial monitor. 16u2

I programmed my 328(non p) with boot loader popped it on a arduino board loaded like a charm.

On my board it doesn't respond to the sync up pulses, yet I confirmed continuity from the serial to resistor from resistor to arduino on both rx/tx.

Only electrical oddity is that the tx line from serial to current limiting resistor is 5v, other side is 5v to 328, the rx line is 5v from serial to resistor also but only 4.5v to the 328.

Is this a electrical issue or what, seems like a bag of mixed results.

If I had the board here I would hook up the logic analyzer and see what was happening.

As it is, the best I can do is ask to see your circuit.

Here is the schematic, 2 arduino's only connected via i2c should the need arise to have them talk. The switch does its name and lets me change up who I program or who can talk to serial. There was a typo where when I copied the chips wiring the crystals where put in parallel and routed that way but was fixed by me cutting the traces connecting them before it was ever powered on.

Not sure if I'm on to anything but the AREF pin, the schematic has it connected to a 0.1uF cap to ground.
I didn't think I needed this as I assume its internally grounded for comparing so I left the pin open, as a cap there wouldn't act as a compare but a ripple reduction. Assuming I'm happy with the default 5v analog reference it shouldn't matter.

I skipped on a few other parts that technically aren't needed or redundant on other parts, like a 0.1uF is on my regulator so I don't need it again for arduino 5v-gnd, diode protection for spikes is a waste of space in this design, do you drive many high current inductive loads on your arduino :roll_eyes:. The diodes on the reset are a joke, its a 10K resistor on 5v, yes there may be some current spiking from the button switching states but that's technically limited to a few multiples of its base current of 0.5mA, I'd expect the button to fail before that level of current hurts this chip.

I have had issues with a few analog pins but not all of them in my testing. 1 is rock solid and detects changes, one is always low, other self oscillates from high/low, the digital outs didn't show any issues.

Knowing everything its probably something stupid easy to fix

So you have two CPUs. Do they both have this problem?

Yes, they both don't load.

But aside from power and the i2c lines they have no direct connection. I didn't include it but I use level shifters on the I2c line so I can also safely talk to 3.3v devices, but that wouldn't affect my rx/tx issues, completely different ports.

That has been the back and forth part, the chips serial program on arduino boards, but on my board the serial chip talks to the computer just fine in loop testing and being assigned a com(11).

Serial.print doesn't packet properly but data still passes though. But when you try to talk back its got nothing... I've tested every mm of the lines on board I can't fine a short and continuity is there.

I might just part swapping onto another board to see if that fixes it or try a different design with a different chip combination.

If you want to spend a little money, I find this invaluable:

$149

Then you know what is going on.