[Solved] Can't program after switching to internal oscillator

Hello,

I'm very new to arduino (as you'll probably soon realize) and am having a difficult time with oscillator selection and programming via the serial port.

My setup is this: I made my own board with an ATmega328p and an FTDI chip on-board, routed to a USB port. I use the Atmel AVR / Studio 6 to initially load a bootloader program onto the board (via the ICSP) and then desire to just update via USB / UART for subsequent programming from the Arduino development environment.

This all works fine when running with the external oscillator, but then stops working when I switch to using the internal oscillator. I clearly don't understand very well how clocks, timing, ,etc., but from trying to dig into this, I understand that the UART inside the 328 is probably being affected by the oscillator change.

When I have the 16MHz resonator on the board and set the fuse to EXTXOSC_8MHZ_XX_16KCK_14CK_65MS, everything works fine. My delay() commands work as expected, e.g. delay(1000) gives me exactly 1 second of delay. (Here's the first example of my lack of understanding here... it would seem like a 16MHz resonator should make the processor run 2x too fast, but it does not.) When I plug in my USB cable, the device shows up as a COM port running 9600 baud. Again, this all works fine.

However, when I change the oscillator fuse to INTRCOSC_8MHZ_6CK_14CK_65MS, the same timing program runs at 50% (actually 49.6%) of expected speed, meaning that delay(1000) now takes just over 2 seconds to complete. And I can no longer program the device with USB/UART.

Since the processor is running at 50% speed, I tried setting the baud rate (via Windows Device Manager) to 4800, thinking that might solve the problem, but it did not. I would not think that the 0.85% error in the oscillator frequency (ignoring the 1/2 speed operation) would be enough to mess up the serial port, assuming the change to 4800 baud was the right thing to do.

Help, please...

Thanks, Bryan

This issue is known and I’ll provide solution and explanation.

When you change arduino clock, you have to modify a parameter in the Arduino IDE because else, he IDE is doing calculations for a 16mhz board when actually it is a 8mhz one.

Go to boards.txt inside hardware, arduino installation folder (close IDE first.).
Open it and look for for these parameters (arduino uno right)?

uno.name=Arduino Uno
uno.upload.protocol=arduino
uno.upload.maximum_size=32256
uno.upload.speed=115200
uno.bootloader.low_fuses=0xff
uno.bootloader.high_fuses=0xde
uno.bootloader.extended_fuses=0x05
uno.bootloader.path=optiboot
uno.bootloader.file=optiboot_atmega328.hex
uno.bootloader.unlock_bits=0x3F
uno.bootloader.lock_bits=0x0F
uno.build.mcu=atmega328p
uno.build.f_cpu=16000000L
uno.build.core=arduino

Change 16000000L for 8000000L.
Save.

Open IDE and try again. You’ll have to change back it to 16L if you program with ext 16mhz oscilator. You can create another board inside boards.txt to not change this.

Thank you, mart256!! I really appreciate the help. Now I just need to figure out what I have to do in order to edit the file (Windows 8 keeps telling me I can't change the read-only status, even though I have administrator privileges...)

I will get that resolved and then let you know if this fixed the issue! Bryan

Okay, I figured out the Windows 8 file permissions issue, made the change to boards.txt, as described, and then did the following:

  1. Fire up the IDE
  2. Program my “timing test” code to my Uno board
    → This should now put the 8MHz value for f_cpu into memory
  3. Use the AVR to make a copy of the Uno’s memory; save this as a file
  4. Use the AVR to program a copy of that same file into my custom board

Good news: The timing issue is now fixed – my timing program now counts off real time correctly! Progress…

But, I still can’t program the board directly from the IDE using USB/UART. I would have thought that the fix to the processor’s clock settings would fix the programming problem (which I’m assuming is a baud rate issue), but maybe it’s something else.

Again, all I’ve changed from a solution that worked to one that didn’t was to go from the external clock to internal.

Is there any other clock setting that would affect the UART that I’m missing??

My solution was only for the timing I didnt state that before sorry. What I do is to compile the .hex with the 8mhz build. Then I upload via ISP programmer. Never tried uploading via uart, so I cant provide more help than saying that the issue may be in the bootloader itself.

Regards.

Okay, understood. Thank you very much for helping with the one issue -- it's good to understand how/where to set up the clock speed now.

I need to learn more about bootloaders now and try to figure out why this continues to not work as it did before...

Bryan

I'm continuing to struggle with this... I can set the fuse bit back to "external osc" and things work (though it now runs 2x too fast, as expected, when running off the 16MHz resonator).

But as soon as I set it back to "internal osc" and I get this message: avrdude: stk500_getsync(): not in sync: resp=0x00

I've tried burning in different bootloaders (optiboot, etc.), and nothing seems to change.

I've tried configuring the COM port to different speeds (9600, 19200, etc.), and nothing works.

Any other ideas of things I should try?

Bryan

The trouble as I suggested (just guessing), is in the code of the bootloader itself, that's involves a good diging and understanding about compiling bootloaders (which I lack of).

Here is an optiboot source I found, https://code.google.com/p/optiboot/downloads/detail?name=optiboot-v5.0a.zip&can=2&q=

There's an optiboot for 8 MHz, this may help to upload via FTDI.

Good luck.

Thanks again, mart256!! I tried the atmega328_pro_8MHz bootloader, but no improvements, unfortunately...

Questions to any bootloader experts who may be reading this:

  • How do I determine what baud rate any given bootloader is set for?
  • In looking at the source file for optiboot, it appears that it checks the processor frequency and if 8MHz or greater, it sets the baud rate to 115200... is this correct?
  • When I program in a new bootloader, I'm simply taking the associated *.hex file and burning it into the device using the programming tool in Atmel Studio 6, via the AVR programmer / ICSP interface -- is this correct?
  • When I try various baud rates on the FTDI chip, I'm just changing the baud rate under Device Manager in Windows -- is this correct?

I've tried to compile my own bootloader, forcing the baud rate to a known value (e.g. 9600), but no luck there, yet.

The symptom I'm seeing for every failed USB / UART programming attempt is three quick flashes on the "TX" led that I have on the board, combined with silence on the "RX" led. This leads me to believe there's a baud rate mismatch between my PC and the bootloader inside the 328. But since I've tried so many different baud rates, I'm now questioning that...

And a question for the experts on Atmel processors: - In the datasheet for the processor, I notice there's a separate clock for the UART (clk-I/O) vs. the processor frequency (clk-CPU). How is clk-I/O set in the Arduino environment?

Sorry for all the questions, but I am truly trying to learn more about this entire system, so your help is appreciated!!

I smell you are close to the solution.

Did you try with optibootatmega328.hex ? (The one without the pro) Burning .hex is not enough, remember to burn fuses to 8mhz too.

To change upload bad rate there is a preferences.txt (i remember you can access to it via Arduino IDE file/preferences). There is a command line (serial debug rate) on the .txt which defaults is 9600 baud if Im correct. That is for serial monitor only.

Another important thing, if nothing else works you may try with 8mhz crystal as ext osc.

mart256: Another important thing, if nothing else works you may try with 8mhz crystal as ext osc.

Yes, that does indeed work, but since this design is targeted at a production board, I'd like to be able to save the cost of the crystal / resonator, if possible...

And I've already produced the 2nd rev of the board and, assuming the internal oscillator was a viable option, omitted the resonator entirely... so now I'm doubly motivated to figure this one out... :~

Did you try callibrating the internal osc?

mart256:
Did you try callibrating the internal osc?

Good question… I looked at that, but it wasn’t intuitive to me how to go about that. Here’s a screenshot of what I see in the Atmel Studio 6 (which is what I’m assuming I should use to tune it):

It makes sense that I’m reading the factory-programming tuning, but I’m not sure what to do from here. I’d expect to see “old value” and “new value” fields, but not “address”, nor the “Flash” or “EEPROM” options…

I’m still trying to understand what baud rate my bootloader is looking for.

In my boards.txt file, it calls out uno.bootloader.file=optiboot_atmega328.hex, so I’m assuming that’s what I’m using.

In optiboot.c, it has the following:

/* set the UART baud rate defaults */
#ifndef BAUD_RATE
#if F_CPU >= 8000000L
#define BAUD_RATE 115200L // Highest rate Avrdude win32 will support
#elsif F_CPU >= 1000000L
#define BAUD_RATE 9600L // 19200 also supported, but with significant error
#elsif F_CPU >= 128000L
#define BAUD_RATE 4800L // Good for 128kHz internal RC
#else
#define BAUD_RATE 1200L // Good even at 32768Hz
#endif
#endif

Since I’m operating at 8MHz, I’m assuming that the bootloader I get is looking for 115200 baud. Yet I’ve read in numerous places that bootloaders typically operate at either 9600 or 19200. Can anyone clear this up for me?

I’ve also been attempting to build my own bootloader, based on the optiboot environment, but when I try to execute a “make” in a DOC environment, I get the following errors, though I’m not sure why:

The first error is on the line: #if F_CPU >= 8000000L
The 2nd error is on the second of these lines:
#if (F_CPU + BAUD_RATE * 4L) / (BAUD_RATE * 8L) - 1 < 3
#error Unachievable baud rate (too fast) BAUD_RATE

I would really love to be able to compile a version of optiboot, but it doesn’t seem to be working for me in a DOS environment. Can someone give me the bonehead version of how to compile it within the Arduino environment? I’ve searched for this and found that it seems to be possible, but I’m not sure how…

Thanks!

Solution was indeed to compile a new bootloader that slowed things down. The complication was that I had been using a bootloader (I don't even remember where I found it) that ran at 9600, but whenever I did a new compile (like to effect a change in boards.txt), I was loading a new bootloader into the device, thus changing the baud rate back to 115200. And that, of course, did not even come close to working with the internal RC oscillator.

Anyway, thank you, mart256, for solving one problem and then steering me in the right direction for the final solution.

Bryan

Deep digging always bring solutions, nice you solved it. Now I have a question for you, how did you fix the issue that was changing your 9600 bootloader back to 115200?

mart256: Deep digging always bring solutions, nice you solved it. Now I have a question for you, how did you fix the issue that was changing your 9600 bootloader back to 115200?

Thanks!

To solve, I built a bootloader that is configured for a 9600 baud rate. That's done in this (new section) of the Optiboot's "Makefile":

# Standard atmega328, only at 9600 baud for closer clock accuracy AND using 8Mhz internal RC oscillator
#
atmega328_96_8: TARGET = atmega328
atmega328_96_8: MCU_TARGET = atmega328p
atmega328_96_8: CFLAGS += '-DLED_START_FLASHES=3' '-DBAUD_RATE=9600'
atmega328_96_8: AVR_FREQ = 8000000L
atmega328_96_8: LDSECTIONS  = -Wl,--section-start=.text=0x7e00 -Wl,--section-start=.version=0x7ffe
atmega328_96_8: $(PROGRAM)_atmega328_96_8.hex
atmega328_96_8: $(PROGRAM)_atmega328_96_8.lst

Then you just type "omake atmega328_96_8" in a DOS window in the optiboot directory. That generates a *.hex file that I simply burned into the board using my Atmel AVR.

After the bootloader is there, then I can add my code using a USB cable and a little FTDI-based adapter, directly from the IDE.

Full credit for this goes to "tylernt" for posting this solution in another section of this forum....

Note that with the one board I've tried so far, I wasn't able to run faster than 9600 baud with the internal RC oscillator. Others have reported having it work as fast as 38400. I suspect it will vary board-to-board and whether you've tuned the internal osc or not (which I have not yet figured out how to do).

Bryan