I recently bought an ATmega8A-PU for my project. Chip is made in Taiwan, so I'm pretty sure it's not fake.
Long story short, I can't get it to work.
I have tried MiniCore and Optiboot with every configuration (internal oscillator and external crystal), burning the bootloader and uploading a simple blink sketch succeed using USBasp, but the LED doesn't blink even tho I specified the correct pin. It turns on and very dimly lit.
So I checked the pin with my multimeter, it has 2V. As a matter of fact, all I/O pins have the same voltage. Makes no difference whether I'm running the ATmega8A at 3.3V or 5V.
However, the chip is not faulty because I can turn it into USBasp by using avrdude, flashing the official firmware hex file I got from USBasp Github. Rewired it according to the schematic and Windows detects it as USBasp. I can even use it to upload sketches on an Arduino Nano clone.
I'm at lost. Has anyone here encountered a similar problem?
I used both method. Upload the blink sketch using USB UART serial as well as upload using programmer (USBasp), all succeeded.
The chip is just refusing to work.
I also need to amend my previous statement. All I/O pins now have a default 1.6V when I'm running the chip at 3.3V and 2.5V when running at 5V.
The digital output pin (PC0, pin 23) that I chose to write toggle between low and high state in my loop doesn't switch. It is stuck at 1.6V
Only when I programmed the chip into a USBasp and set the proper fuses (Low:0xEF, high:0xC9) using avrdude, it works normally like any ATmega8. I also noticed that all of the unused I/O pins are pulled high to VCC.
Just a quick update while I'm waiting for my Arduino nano.
I gave this chip another try. My IDE version is 1.18.16
Sucessfully burned the MiniCore bootloader with these settings: ATmega8, external 12MHz, no BOD, no LTO. I checked with avrdude and the fuse bytes are correct.
Also uploaded successfully a simple sketch where I setup a serial mode at 9600 baud rate, and in the loop, a serial print of "Hello world" every 1s
So at this point, the bootloader is indeed running and communicating with the IDE, right?
With that in mind, I opened the serial monitor, but I don't see any "Hello world". Reset the chip. No joy.
Flashing the compiled sketch with bootloader hex file and setting the low fuse byte manually with avrdude does the trick. I can switch between internal 8MHz oscillator (0xB4 or 0xE4)) and external crystal (0xBF or 0xEF) just fine and I can see the "Hello world" now on serial monitor output.
However, my LED still doesn't blink at all. I have the cathode connected to the chip physical pin 23 (PC0). Anode is connected to 5V with a 1K resistor.
This thread revolves around hardware issues. It's always wise (necessary) to post schematic diagrams and good photos of your setup so people may be able to spot potential problems.
I added another LED to pin 14 (PB0) but wired the conventional way.
I amended my sketch to reflect the suggestion to use PIN_PC0 (as well as PIN_PB0), uploaded successfully, but both LEDs stay off while the loop continously printing out "Hello world" every 1s to the serial monitor.
I don't know what's wrong. The LEDs are connected properly because I solder my components point to point on a prototype PCB, not using flimsy jumper cables. This is hardly a challenge when compared to multi layer PCBs with thousand of components that I work with on a daily basis.
Could you post a photo of both sides of the board, please?
The schematic looks fine.
Where does the +5V come from? What are the voltages on PC0 and PB0 with the sketch running?
To confirm, you do receive this text OK on the serial monitor?
Thank you all, especially @westfw for pointing out the error with my sketch. I got used to using that pin naming convention when working with Digispark85.
The values like PC0 are actually "bit names" from the avr-libc include files.
PC0 is 0 (bit 0.) PB0 and PD0 are also just 0 (bit 0 in their respective ports.)
Now, I think it's pretty silly to have multiple names for (otherwise indistinct) bit0 in separate ports, but Atmel didn't ask me, and the .h files are allegedly generated automatically from design data, and somewhere it says "all the bits will be named." (which is fine for the more complicated peripherals, although I have the same complaint for different names for the same bits in, say UARTS. "RXC0" - Hmph.
Atmel has somewhat fixed this (changed it, anyway) in the newer AVRs by using the structure-based peripheral definitions. But still ... "gotta have that backward compatibility!" Sigh.
On a tiny85, there's only one port, so it doesn't matter.
PIN_Pxx is an MCUDude and DrAzzy thing, presumably spurred by supporting chips without "standard board layouts." You'll find those definitions in an official Arduino core.
