I have a project running on 1.9V, 8 mhz (internal). It accepts the bootloader fine and I can use Nick Gammon's sketch to read all the info from it. However, when I try to upload a sketch via Arduino IDE or Platform.io (over UART) , it gives me a stk500_getsynch() error.
I have tried a FTDI programmer and also a Arduino Uno without a chip. Neither of them seem to work. Because the project is running on 1.9V, I have a TXS0108E inbetween the FTDI-programmer and the Atmega328P-AU. And also a 100nF Ceramic Capacitor between the Reset pin and the DTR pin of the Programmer.
I have tried multiple frequencies: 1 Mhz, 2 Mhz and 8 Mhz. They all give the same result. I have disabled the BOD, since the voltage level is so low. These are the rest of the settings for the Minicore bootloader, the baud rate is set at 9600.
Since my project will run on a battery, has to last quite a while and has to be as small as possible, I want to use the internal oscillator. I found that it is quite innacurate but when testing my idea, I used a Atmega328P-PU with the same settings, and this worked like a charm.
I have tried everything to get this to work and I have run out of ideas. I have searched what feels like the entire internet but I'm also quite new to working with these "custom" chips. Any help is greatly appreciated!
Thanks for the reply! The board runs on 1.9v. I can't and haven't been able to upload sketches so I can't upload Blink.
Tomorrow I will try to setup the atmega328p-pu again, it is about a month ago that I tried that setup.
If you can program bootloader several times, why not using ICSP header to flash your code to it instead of relying on the bootloader? The bootloader (don't know which you're using) has a baud rate that is usually too high for internal oscillators to do accurately. If you reduce the baud rate of the bootloader and also research how to calibrate the oscillator, you may have better chance.
The picture shows the board tab with and ATmega328, yet you stated you have a ATmega328P. Try and change the Board to ATmega328p and see if that fixes your problem.
The stk500_getsynch() is a very vague description of the problem, there can be any number of things wrong, so check your circuit to make sure nothing happened to it between when you burned to boot loader and when you tried uploading the sketch
Perhaps you should program the board with 3.3v power.
BTW the bootloader simply receives the program via the UART, writes to memory and sets a link so the next time the board powers up the program runs. The key is the bootloader is created assuming a clock rate so the bootloader UART setup will correctly receive data. If you use a different clock on your board the bootloader won't work.
I have set the baud-rate of the bootloader at 9600 baud, following an online datasheet that calulates the error percentage at certain clockspeeds and baud-rates (giving this 0.2%).
I don't know if I need to change the baud-rate of the Arduino IDE?
I have now uploaded a sketch via ISP, in which I try to initialize a Serial bridge at 9600. I have connected a LED and modified blink to start a Serial connection, and write High and Low when the LED changes. The LED blinks, but I don't see any serial output on the serial monitor...
I have also just noticed something interesting, when I upload the bootloader, avr-dude states the following: Overriding Baud Rate : 19200
Is this of any significance?
You totally lost me on the frequency you are currently running your board on.
Anyway, can you just do something simple like the serial port sample program that prints out the ASCII table? Then use different baud rates to see if you get any readouts correctly. Your own code complicates things. I want to see that your processor is actually running and you have properly flashed a program to it. Don't use your own code, use the serial port sample code instead. It's best to separate anything from anything else when debugging. Your code is one thing, and your board is the other thing.
So after a lot of trial and error I have found out a couple of things:
My FTDI programmer had a fautly trace to the DTR pin, meaning that it was always pulled to ground.
My level shifter had been blown up because of an over-voltage, probably from the faulty FTDI chip
My board was functioning fine and is completely programmable over UART if I do a manual reset, through the level shifter, tying the reset pin to 1.9V with a 10 kOhm resistor.
Thanks for all your help! A faulty FTDI programmer caused all my issues.