Tanks for sharing! Karma+
I have a custom board with ATMega328P running at 5V with NO crystal.
I am using MiniCore with the following:
Board: MiniCore ATMega328 / 8MHz Internal
Variant: 328P
BOD: Disable
LTO: Disable
Programmer: STK500 for Pololu A-Star
This was working great and I was able to burn the MiniCore bootloader no problem.
Now I get the following error when I attempt to burn the bootloader:
Arduino: 1.8.7 (Windows 10), Board: "ATmega328, Yes (UART0), 328P / 328PA, BOD disabled, LTO disabled, 8 MHz internal"
C:\Users\Robert\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino14/bin/avrdude -CC:\Users\Robert\Documents\Arduino\hardware\MiniCore-master\avr/avrdude.conf -v -patmega328p -cstk500 -PCOM4 -e -Ulock:w:0x3f:m -Uefuse:w:0b11111111:m -Uhfuse:w:0xd6:m -Ulfuse:w:0xe2:m
avrdude: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:\Users\Robert\Documents\Arduino\hardware\MiniCore-master\avr/avrdude.conf"
Using Port : COM4
Using Programmer : stk500
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : STK500V2
Description : Atmel STK500
Programmer Model: STK500
Hardware Version: 15
Firmware Version Master : 2.10
Topcard : Unknown
Vtarget : 5.1 V
SCK period : 0.5 us
Varef : 0.0 V
Oscillator : Off
avrdude: stk500v2_command(): command failed
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
Error while burning bootloader.
I have checked and rechecked all connections which are correct.
Don't know where to go from here......
I'm slowly losing my mind and don't understand anything. Unable to flash bootloader during several days.
OS: Windows 10
Arduino IDE: 1.8.13
MiniCore: fresh, just dowloaded from github
Arduino UNO
Atmega328P U, ill-fated version on which all swear: Which chip is this: "ATmega328P U"? [SOLVED] - Microcontrollers - Arduino Forum
in DIP package.
Built a circuit on breadboard with 16Mhz crystal according pic at GitHub - MCUdude/MiniCore: Arduino hardware package for ATmega8, ATmega48, ATmega88, ATmega168, ATmega328 and ATmega328PB
My setting see attached pic1.
- Connect Arduino to PC
- Press burn Burnbootloader
then I got error, see log.txt
I have tried the divverent variants:328, 328P - the result the same.
PS. LED, connected to 19pin of ATMEGA 328P U - not flashing
Please advise, what I am doing wrong...

log.txt (3.49 KB)
What are you using for a Programmer? A Programmer will connec to pins 13,12,11 and Reset to access the flash memory and the fuses and load the boot loader code and set the fuses to run the bootloader after a reset.
For a programmer I use Arduino as ISP - connected to ISP.
Before I also tried connect to 13,12,11 pins as well

It may be that the fuse settings on the 328P you're trying to program are "bad" and it can't drive an external oscillator. Try to load the Adafruit Arduino as ISP sketch, and connect pin 9 on the Arduino UNO to the XTAL1 on the target. This Arduino as ISP sketch is different from the original and outputs an 8 MHz square wave that you can use to drive your target.
Many thanks hansibull, I have some progress. What done
- use bootloader as you advised from GitHub - adafruit/ArduinoISP: A fork of the ArduinoISP that has 8mhz output clock, connect pin 9 on the Arduino UNO to the XTAL1 on the target. - burned without errors. See log-1.txt
- burn bootloader from MiniCore, set 16Mhz ext - without error, see log-2.txt
- removed wire between pin 9 and XTAL1 and repeated step 2. And now I have error again - see log -3.
Is my chip so bad that can not works with 16Mhz crystal?
How I can upload the simple sketch (LED blinking) to chip by using arduino uno for checking atmega328 on breadboard? I have not USB-TTL converter as advised on the web...
log-1.txt (9.29 KB)
log-1.txt (9.29 KB)
log-3.txt (3.35 KB)
In 1) and 2) you're not burning bootloader using MiniCore, you're using something else.
In step 2 you set the fuses so that the microcontroller will run of an external 16 MHz crystal. you will have to connect this crystal and its two capacitors in order to get it to work.
If you don't have a 16 MHz crystal you can instead use the internal 8 MHz oscillator.
Hi, just upload the bootloader to a Nano (328P) via USBTinyISP and can upload sketches with the ISP however not via Serial.
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xe8
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xfd
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xfd
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0xfd
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xfd
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xfd
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0xfe
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xff
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0xfd
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xfd
Any ideas?
Okay, burned the bootloader again and don't upload a test sketch via ISP. After this I upload a sketch via Serial and seems to work fine. Does uploading a sketch via ISP remove the bootloader? Any ideas?
Problem solved.
illumation:
Hi, just upload the bootloader to a Nano (328P) via USBTinyISP and can upload sketches with the ISP however not via Serial.avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xe8
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xfd
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xfd
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0xfd
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xfd
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xfd
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0xfe
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xff
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0xfd
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xfdAny ideas?
illumation:
Does uploading a sketch via ISP remove the bootloader?
Yes.
illumation:
Does uploading a sketch via ISP remove the bootloader?
There is only one command available to erase flash via ISP - "chip erase" which clears the flash and lockbits. Chip erase is always executed by avrdude when writing to the flash unless you pass a specific option (and were one to do this, only writing to flash that wasn't already programmed would work, because write changes 1's to 0's, but only erase turns 0's to 1's) - the protocol provides no way to erase the flash without also erasing the bootloader section. As an aside, when you do export compiled binary, the IDE does provide you with a version that has the bootloader included (on official boards and I would imagine minicore as well, assuming you specified using the bootloader when you compiled...
In contrast, self-programming (ie, bootloader) erases the flash one page at a time (a page being much smaller - exact size depends on the amount of flash on the chip); it erases each page that you upload new code to, then writes that code to it, so that is not a problem.
Did the upload speed for m328p 3v 8MHz external, change from MiniCore Issue 2.0.3 to Issue 2.0.4?
Old upload speed 38400, new upload speed 57600.
I have several Pro Mini's that will not upload using the new MiniCore issue 2.0.4 , unless I burn the bootloader or select 8 MHz internal.
It's possible, I changed something myself and forgot about it.
Linux, IDE 1.8.12
Old upload speed 38400, new upload speed 57600.
That's correct. I've done this (sorry) to match the baud rate for all my other cores. It should have been done a long time ago.
MiniCore v2.0.4 changelog:
- Add more supported clocks
- 14.7456 MHz, 11.0592 MHz, 7.3728 MHz, 3.6864 MHz, and 1.8432 MHz added
- Fix A6 and A7 definitions for ATmega48/88/168/328PB (#107)
- Fix incorrect analogInputToDigitalPin macro
- Change baud rate for 8 MHz external option
- Baud rate is now 57600 instead of 38400
- This is to ensure compatibility across all my other Arduino cores
- Add 12 MHz 115200 baud bootloaders
- Fix issue where i2c slave functionality may not work (#122)
- Add slow USBtinyISP and USBasp programmers
- Blank chips run at 1 MHz. Some programmers, especially USBasp are too fast for these chips.
OK, this may throw a few of us when we have failures uploading just like the Nano situation does.
Thanks for the reply and thanks for all the work you put into these "Cores". I use them for every board and chip that I can.
Is the MiniCore still compatibile with Eclipse Arduino or Sloeber?
First of all I had to remove all Mac ._* files to be able to bulid project.
Then when I tried to upload it the error showed:
"C:Usershypat.arduinocdtpackagesarduinotoolsavrdude6.3.0-arduino9binavrdude" (in directory "C:Usershypateclipse-workspacesdjhtbuild328PB_COM7"): CreateProcess error=2
The avrdude has only 6.3.0-arduino17 directory in it.
I'm using Arduino 1.8.2 and Eclipse 2020-03 (4.15.0), but I had this problem on 1.6.22 and older version of Eclipse aswell.
I've also tested Sloeber plugin and I can't generate a new project, as can be seen here: Imgur: The magic of the Internet.
Are there additional steps to make it work?
I burned the bootloader for an atmega328p 1mhz internal crystal. but when I want to increase the pwm frequency, I fail.
For example, when I write the following code for arduino uno, the pwm frequency was 31372.55 Hz;
TCCR2B = TCCR2B & B11111000 | B00000001;
now it is 1.96khz
when I write the following code for arduino uno, the pwm frequency was 31372.55 Hz;
TCCR2B = TCCR2B & B11111000 | B00000001
now it is 1.96khz
Yes. What did you expect? The timers operate off of the CPU clock. You've decreased the clock frequency by a factor of 16; the PWM frequency also decreases by a factor of 16.
Using MiniCore will automatically adjust some of the software timing of the system (mills() and micros() and delay(); maybe the "normal" frequency of PWM), but the timers are all hardware, so nothing the bootloader or core can do will change the results of writing directly to the timer registers.
1.96kHz is the maximum frequency for 8bit phase-correct PWM with a 1MHz clock...
Hi, today I have tried your MiniCore (v2.0.5) with Arduino 1.8.12 on Windows.
I am using a small Atmega 168P based board with an 8 MHz crystal,
which has a preinstalled bootloader, that is working OK with Arduino.
After burning the MiniCore bootloader, there were some issues:
-
With the new bootloader I am not able to upload any code the the MCU via serial interface.
The chosen baud rate is set to 57600, which seems to be the cause of the issue.
Changing it to 115200 in your boards.txt solves this. -
My program generates some output via serial port. In my code the baud rate ist set to 9600,
but the output is garbled. If I change my terminal to 19200 baud, the output is OK.
If I change my code to 4800 baud, then my terminal has to be set to 9600. -
There is a difference in the low fuse values for the 168P. The original setting is 0xff(ext. crystal 8MHz).
With MiniCore (168P, 8Mhz) it is changed to 0xf7 (ext. full-swing crystal).
Changing it manually via ISP seems to have no effect either.
I think there are some similar issues posted on github.
I appreciate your work on the cores and extensions.
- With the new bootloader I am not able to upload any code the the MCU via serial interface.
The chosen baud rate is set to 57600, which seems to be the cause of the issue.
Changing it to 115200 in your boards.txt solves this.
If you have to increase the baud rate with a factor of two in order to communicate with it, it's likely that the chip is running twice as fast as it should.
- My program generates some output via serial port. In my code the baud rate is set to 9600,
but the output is garbled. If I change my terminal to 19200 baud, the output is OK.
If I change my code to 4800 baud, then my terminal has to be set to 9600.
Same answer as 1. Are you 100% sure the crystal isn't running at 16 MHz? Because symptoms like this indicate that it is.
- There is a difference in the low fuse values for the 168P. The original setting is 0xff(ext. crystal 8MHz).
With MiniCore (168P, 8Mhz) it is changed to 0xf7 (ext. full-swing crystal).
Changing it manually via ISP seems to have no effect either.
The full swing option consumes a little more power, but is able to drive "heaver" loads, and makes the chip less sensitive to interference on the XTAL lines. Full swing is the way to go for most applications that uses an external oscilator.