We've been programming a custom Board with an ATmega2561 via a serial (RS232) connection for years, mostly without problem. We're using a custom bootloader that is closely based on recommondations in the datasheet and application notes.

  • Interrupt routine writes data into 64 Byte Rx-Buffer
  • If a line-break is received, check if data is valid intel hex
  • Decode intel hex and write data to 256 Byte flash page buffer
  • If page buffer is not full, go back and check for line break
  • When page buffer is full, delete datablock in flash, write page to flash, validate data in flash, return to checking for line break in Rx buffer

All the boards with the Problem had an ATmega2561 with a datecode of 20035EU (Week 3 of 2020, 5EU is probably some internal lot-nr)

So why did programming fail on 80% of the boards with MCUs from that Lot?

  • Replacing the MCU with one from another Lot solved the problem
  • Reducing the data rate from 57600bit/s to 9600bit/s "solved" the problem
  • Further testing showed, that all speeds up to 50000bit/s worked
  • The external ceramic resonator worked flawlessly
  • When programmed, all testing showed no further anomalies
  • When beeing run on the internal "calibrated 8MHz" oscillator, baudrates were about 12% below of what we would have expected, indicating that the internal oscillator runs at about 7MHz instead of 8MHz
  • \$\begingroup\$ Have you read the errata for that specific silicon revision? \$\endgroup\$
    – Justme
    Jan 28, 2022 at 14:17
  • \$\begingroup\$ @Justme yes. It's revision F and for that only a bug with ADC differential input and high gain is listed. I found a solution and moslty wrote it here because I've spent a long time searching for a solution and did not find anything. \$\endgroup\$
    – kruemi
    Jan 28, 2022 at 14:19

2 Answers 2

  • According to the Datasheet, the timing for flash- (and EEPROM-) Programming is controled by the internal calibrated RC-oscillator
  • 64 Bytes of input buffer are filled within 11.1ms
  • there is no flow control on the serial line during self programming
  • If a buffer overflow accurs, the programming will fail
  • According to the datasheet ereasing and writing a page in flash takes between 3.7ms and 4.5ms each. So at maximum 9ms, leaving 2ms for decoding, preparing and validating. That's 32000 cycles at 16MHz which is plenty.

So the way this fails is because the internal "calibrated" RC-Oscilltor was running way too slow. So erasing and programming the flash memory takes more like 5.1ms instead of 4.5ms each. This led to an Rx-Buffer overflow which corruped the received data. The Bootloader detected the corruption via checksums and stopped programming (but not sending any feedback of the nature of the problem).


  • sending the chips back to Microchip (but they don't confirm any problem) but at the current chip shortage this might not be an option
  • Increasing the Rx-Buffer-Size to 128 Bytes

Chaning the bootloader to accomondate for an out of spec product (and not knowing what else could be wrong) might not seem very satisfying. But at the current chip shortage you might just have to make it work because all other options are worse.

  • \$\begingroup\$ You're reading far too much into the word "calibrated", according to the datasheet the tolerance is +/-10% at 25C and will vary every more with temperature changes. RC oscillators are very inaccurate. \$\endgroup\$
    – Ben Voigt
    Jan 28, 2022 at 15:32
  • \$\begingroup\$ So even wiith 10% tolerance, 12.5% is out of spec. And a write time of more than 5ms is also way out of the range given (3.7ms to 4.5ms). True, the 64byte buffer was unnecessary small (no real reason to keep it that small). I have no clue what led to that desicion when the Bootloader was developed. \$\endgroup\$
    – kruemi
    Jan 28, 2022 at 21:03
  • 1
    \$\begingroup\$ Probably the best option, though, is simply to have your custom bootloader enable the external crystal. Clock error gone, flash programmed within the expected time interval. \$\endgroup\$
    – Ben Voigt
    Jan 28, 2022 at 23:00
  • 1
    \$\begingroup\$ So you may have to recalibrate the internal RC oscillator to match the external crystal (the datasheet doesn't appear to say that the factory calibration is forced during Flash access) before starting Flash accesses. \$\endgroup\$
    – Ben Voigt
    Jan 31, 2022 at 17:05
  • 2
    \$\begingroup\$ On your ATtiny chip, that seems to require a 32kHz crystal on the TOSC pair, not the main crystal oscillator. \$\endgroup\$
    – Ben Voigt
    Feb 1, 2022 at 15:54

Perhaps the chips were not calibrated at the factory. But you should be able to do it yourself using the OSCCAL register.

From page 32 of the 362 page datasheet:

9.10.1 OSCCAL – Oscillator Calibration Register

• Bits 7:0 – CAL7:0: Oscillator Calibration Value

The Oscillator Calibration Register is used to trim the Calibrated Internal RC Oscillator to remove process variations from the oscillator frequency. A pre-programmed calibration value is automatically written to this register during chip reset, giving the Factory calibrated frequency as specified in Table 28-2 on page 300. The application software can write this register to change the oscillator frequency. The oscillator can be calibrated to frequencies as specified in Table 28-2 on page 300. Calibration outside that range is not guaranteed.

Note that this oscillator is used to time EEPROM and Flash write accesses, and these write times will be affected accordingly. If the EEPROM or Flash are written, do not calibrate to more than 8.8MHz. Otherwise, the EEPROM or Flash write may fail.

The CAL7 bit determines the range of operation for the oscillator. Setting this bit to 0 gives the lowest frequency range, setting this bit to 1 gives the highest frequency range. The two frequency ranges are overlapping, in other words a setting of OSCCAL = 0x7F gives a higher frequency than OSCCAL = 0x80.

The CAL6..0 bits are used to tune the frequency within the selected range. A setting of 0x00 gives the lowest frequency in that range, and a setting of 0x7F gives the highest frequency in the range.

Here is Table 28-2 on page 300:

enter image description here

  • \$\begingroup\$ That's true. But I'd have to change my bootloader to load the new value into the register on each startup. IF it is just a wrong value from the factory and not a problem that even with a correction value they can't get it into range again. Sadly, I could not spend more time on the issue to find the root cause. \$\endgroup\$
    – kruemi
    May 6, 2022 at 10:04
  • \$\begingroup\$ And it seems impossible to get any information. We made a claim with our assembler who filed a claim at the distributor but informed us that the chances to hear back from Microchip are really slim. I don't even know if the distibutor filed a claim with microchip or if they got a response and just did not forward it to us... \$\endgroup\$
    – kruemi
    May 6, 2022 at 10:09
  • 1
    \$\begingroup\$ @kruemi -- You could change your firmware, and load a config value into the OSCCAL register from EEPROM. In any case, as you pointed out, you'd have to change the bootloader, but you (or somebody else with the same problem) have a way out now. \$\endgroup\$ May 6, 2022 at 11:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.