UART programming of Atmega 328p-AU

Hi
I have a bare bones 328p chip and program it with a TTL to USB module manufactured by FTDI.
When I upload a sketch to the chip with external clock (16Mhz) there is no problem, but when I try to upload to the chip with internal clock (8Mhz) I have problems the error reads:-

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x13

Occasionally it will work, but its rare, I have tried different caps and shorter leads, is there a reason for it not to program reliabily at 8Mhz.

Thanks

Andy

The internal oscillator is not very accurate. In some cases, it could be so far off as to cause the serial communication required for uploads to fail. Each baud rate has a different amount of error in one direction or the other. I suspect that often it’s a matter of the clock speed error and the baud rate error happening to combine in the same direction that pushes the true baud rate outside the usable range. So it could be that using a more suitable baud rate for the upload would solve your problem.

Please do this:

  • (In the Arduino IDE) File > Preferences
  • Uncheck the checkbox next to “Show verbose output during: compilation”
  • Check the checkbox next to "Show verbose output during: upload
  • Click “OK”
  • Sketch > Upload
  • After the upload fails, you’ll see a button on the right side of the orange bar “Copy error messages” (or the icon that looks like two pieces of paper at the top right corner of the black console window in the Arduino Web Editor). Click that button.
  • In a forum reply here, click on the reply field.
  • Click the </> button on the forum toolbar. This will add the forum’s code tags markup to your reply.
  • Press “Ctrl + V”. This will paste the upload output between the code tags.
  • Move the cursor outside of the code tags before you add any additional text to your reply.

The verbose output will tell me the upload baud rate being used and I’ll check what the baud error is on that to see if there is a better one to use.

If you use an FTDI device to program the ATmega328p, you need a bootloader in place which is compiled for the clock rate you intend to use. As far as I am aware, no bootloader is able adapt to various clock rates. In practice, this means using first an icsp programmer (or another Arduino configured as such) and selecting an 8MHz board type , then using the install bootloader option.

Did you use an ISP programmer to burn bootloader for 8MHz/internal oscillator? You need to do that to set the clock source, and upload the appropriate bootloader.

Ok. I think us we have hammered the point about the 8MHz bootloader home well enough. But do you know why it is not possible , by some trick or other, that the bootloader can sense the clockrate it is running at and adapt itself according. I have often been curious about that but never studied the detail.

6v6gt:
But do you know why it is not possible , by some trick or other, that the bootloader can sense the clockrate it is running at and adapt itself according. I have often been curious about that but never studied the detail.

It should be possible in similar way Digispark (V-USB) tunes the oscillator to enable USB communication.

For my rudimentary ATTiny2313 "bootloader" I used the other approach: it responded by 0x55 to any unknown command. The programmer may tune own baud rate to match actual speed of the ATTiny.

Did you use an ISP programmer to burn bootloader for 8MHz/internal oscillator? You need to do that to set the clock source, and upload the appropriate bootloader.

One of the optiboot "recommendations" is to use the exact same code for 8MHz as for 16MHz, and just halve the upload baud rate in boards.txt (57600 instead of 115200)

do you know why it is not possible , by some trick or other, that the bootloader can sense the clockrate it is running at and adapt itself according.

The current bootloader fits in 512 bytes of code (256 instructions.) That doesn't leave a lot of room for "tricks." (It has been done, though. See Optiboot with EEPROM Support and Auto-Baudrate · Issue #227 · Optiboot/optiboot · GitHub. It's not necessarily a good idea.)

OK. Thanks. It is interesting that someone has now done it (or two people have done it counting Smajdalf's contribution). It just seems cleaner to me to have only one compiled bootloader instead of proliferation of them, one for each possible clock rate. But I see that challenge of packing it all into 512 bytes.

It doesn't really trouble me, though. When I have a battery application which would benefit from (or needs) a reduced clock rate, I usually use an ATtiny without any bootloader. In one such case where I have used an ATmega328p with bootloader, I have configured it for 16MHz (with crystal and "Uno" optiboot) and dynamically reduce the clock rate to 4MHz.