Uploader problem, resetting directly to sketch

Alright, I dont consider myself a noob, but this might end up being a noob-ish question. Heres the info: -breadboarded atmega 328-no external crystal -just burned the bootloader for the 8Mhz (previously had the 16mhz) -bootloader is atmega 328 8mhz pro from arduino 16 package -run from and programmed from sparkfun 3.3v ftdi breakout -have tried both using the autoreset with cap, and push button reset many times -uploaded once normally after burning (modified time delay on blink) -now, upon either reset method, the arduino goes directly to sketch (fast blinking on 13) with no perceivable time for the sketch to start uploading -causes generic error: avrdude: stk500_getsync(): not in sync: resp=0x00 avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51 -i know what proper reset behavior is (short delay before going to sketch) Why would pressing the reset button/using autoreset not give the bootloader time to take commands from the serial connection? I have had this happen a few times on other chips, ghost in the chip?

ps: ftdi activity is as follows txLed_txLedtxLed_______________txLed_________fail

You may need to rel reload the boot loader and check that the lock bits are set so it doesn't get wiped out by loading the sketch.

I believe 0x0F is correct.

Any luck with this? I'm running similar hardware using the lilypad 168 bootloader. It works fine with the auto-reset but is very slow to start the application - as much as 10 seconds.

Not too much luck, the 16mhz bootloader runs great even at 3.3v but i dont really need to overclock the chip for what im using it for. I have a problem with what the boards.txt files say the fuse and lock settings should be. Granted this is my first real venture at programming over icsp, but using the fuse calc here: http://www.engbedded.com/fusecalc/ i cant see how 0xFF on low fuse could be right for a chip running at 8mhz. Assuming all the same settings as the 168's at 8mhz, im getting a fuse of 0xE2 on low. And yes, i do agree that the lock bit is being overwritten, just not sure how to correct it. I set it each time after I burn the bootloader. Also as an aside, im using an older version of avrdude that came with the ftdi bitbang programming package but im using an arduino nano in avrisp mode, not the bitbang. Nothing seems to be wrong with the setup, since I can rewrite the old 16mhz bootloader just fine. Maybe time to dig thru the datasheet

For what it's worth, I'm running a 168 on internal oscillator at 8mhz. My fuses are set to E2 DF F8. The lock bits get reset to FF every time you program the chip and (using avr studio) I set them to 0xCF (which is the same as 0F).

I'm using the lilypad bootloader. It works fine the first time but thereafter it won't load except with the auto-reset cap and there's always an 8-10 sec delay before the sketch starts.

I think the clue is:-

-breadboarded atmega 328-no external crystal

The internal oscillator is not accurate enough to get the baud rates right in order for it to perform an upload.

think the clue is:- Quote: -breadboarded atmega 328-no external crystal

The internal oscillator is not accurate enough to get the baud rates right in order for it to perform an upload.

Mike: Do you actually know that from experience or evidence? I'm a bit sceptical because: a) the lilypad works fine and; b) I can run 115,200 baud on my no-crystal setup with no hiccups to speak of.

b) I can run 115,200 baud on my no-crystal setup with no hiccups to speak of.

The datasheet claims the internal oscillator has an accuracy of 10% at 3V and 25C. So, it comes down to this question: Is a 10% clock difference enough to stop serial communications from working? Assuming I did the math correctly, the answer is yes, it will stop serial communcations from working. The result will be framing errors.

I have a 168 that's about 2.1% off and a 328 that's about 4.9% off (4.5V, 20C). My 168 should work fine but my 328 probably won't work.

a) the lilypad works fine and;

There is a register that allows the internal osciallator to be calibrated. According to the datasheet, this gives an accuracy of 1%. But I have no idea if the Lilypad's oscillator is calibrated. I'm just saying that may be how they did away with the crystal.

Im flattered to have gotten responses from the "god" members, haha. As an update, I do have the chip working now thru the same setup. Im not sure what went wrong (or right?) but the lock is now staying after many multiple uploads. Its working on 0016 and 0017 under both the 328 pro mini 8mhz and the 328 lilypad upload setting.

As for the accuracy under serial comm's I can attest to personally seeing the 8mhz speed do perfectly and fail miserably. For my original pro mini 168 8mhz board, there are a decent number of errors at speeds higher than 38400 (which is recommended against anyway). This board does contain an external resonator. But having just tested the bare 328 chip with internal resonator 8mhz, im seeing no errors all the way up to 115200 (just a hello world sketch tho). Maybe I got lucky and had a chip that just happens to work really well @3.3v.

Im just gonna treat it the same way as running the chip @ 3.3v 16mhz-it might work great, it might fail miserably, dont push your luck if you dont need to.

P.S. Can someone comment on the low fuse setting discrepancy I am seeing? How can an internal 8mhz clock, an external 8mhz clock, and an external 16mhz clock's low fuses all be the same? They arent for the 168 but all low fuses for the 328 are the same.