I am at the stage of uploading the Arduino bootloader via SPI comms to the ATMEGA328 so I can then upload the code via Arduino IDE (UART), however, I am always getting "Device Signature = 0x000000" from avrdude when I try to burn the bootloader. I am using an Arduino UNO as an ISP programmer, I have tried powering my project board from the UNO and from a dedicated power supply to no avail.
One thing to note is that the project board does not have any pads or headers broken out to the SPI lines, so I have had to solder some 30AWG, kynar insulated wire directly to the pins of the IC (photo's below).
I have also connected the scope while doing the upload and what I can see is that the MISO line (response from project board to the programmer) doesn't go up to 5v, it peaks at 3.84v when high according to the scope. See screenshots below.
Yellow = Clock; Pink = MISO; Blue = MOSI; Green = Reset
Checked the usual (connections, power, etc, but it is all there)
Oh!! One last thing, the 16MHz crystal oscillator is **NOT **oscillating!! When I put my scope probe onto XTAL2 or even XTAL1, the voltage rises to approx 1V, but it is DC, there is not clock signal.
I am assuming this is because the microcontroller is still using the internal clock it is set to use from the factory? For completeness sake, I even uploaded the modified ArduinoISP code which creates a 16MHz clock on pin 3 of the Arduino UNO. I have used this in the past to sort problems when the fuses were set incorrectly, but it did nothing for me here.
The reason it's giving signature 0x000000 is that the crystal is not oscillating, and it is presumably configured to use that as it's clock source.
Check that neither side is shorted to ground (if it is, check the caps - you can get a short underneath the crystal loading caps if you bung the soldering - very rare if professionally manufactured, but if someone did it at home, it's pretty easy to do; it's the most common problem I have assembling anything other than QFN's). If that's okay, try replacing the crystal - they do occasionally fail.
the lower voltage on the SPI lines - could there be something loading that pin?
Also, the layout around the crystal is bad - they could have rotated it 90 degrees and shortened the length of the traces significantly - it's not like they don't have the space.
finally, good job on soldering that ECO wire, that's excellent work!
Sorry, I didn’t clarify, I am populating the PCB myself, I purchased blank board from JLCPCB, ordered the parts and went to work, this is a brand spanking new IC and I have never managed to communicate to it, so it’s likely operating from an internal clock is my thoughts seeing as it’s brand spanking new from ATMEL, but I mentioned the lack of external clock for completeness.
I am confident of all the soldering, I have taken my time with it all and it has ALL been done under an AMSCOPE microscope.
The only thing the SPI lines go to is a 74 series IC which controls the LEDs, however the voltage on the MISO line is pulled down even when I remove that 74 series IC, so not sure what is causing that or if it’s even just a red herring and is behaving like that due to clock / timing being out....
Also, I agree the crystal layout is not the best, but I don’t think it’s bad enough to create issues, not to mention, as above, I would expect it to be using it’s internal clock at the moment with it being a new IC.
Thanks on the comments regarding my soldering, appreciated!
Yes, VCC is getting 5V fine (well 4.96V to be precise) and the IC is orientated correctly. Just took a blank board and double checked the silk screen marking with the dot on the IC.
Also checked the PCB layout & pinout in EasyEDA to confirm the orientation. All fine on that front.
Notice how the MISO line (Pink) comes up on its way to 5V as the reset line (Green) drops, then as the reset recovers the MISO signal begins to fall! Then shortly after the reset line recovers it dips momentarily, and during that period the MISO line jumps up to 5V then drops back down once reset recovers.
To me it looks like something related to the reset line is pulling MISO down to just sitting at 3V and if I remember correctly a high value for SPI is VDD x 0.6 which would be 5 x 0.6 = 3V...so the programmer might be seeing all 0's as a response due to the MISO line never getting high enough.
The only thing the MISO line connects to is a 74 series IC which controls some LED's. However I did remove this to test and the signal remained identical, so something is pulling down the MISO line in relation to reset, but not sure what.....
Or am I going of in the totally wrong direction here? Thoughts?
If your sorrounding circuit doesn't interfere something and crystal works fine, that you probably have locked MCU. Perhaps cause by wrong fuses set, or intentionally locked by safety measures.
Without high voltage programmer or devices as AVR doctor, there is no way to revive it if the problem is caused by fuse lock.
noob314:
If your sorrounding circuit doesn't interfere sometingh and crystal works fine, that you probably have locked MCU. Perhaps cause by wrong fuses set, or intentionally locked by safety measures.
Without high power programmer or devices as AVR doctor, there is no way to revive it if the problem is caused by fuse lock.
The ATMEGA328 is brand new out of the box and I have never been able to communicate with it, so how can it be locked via incorrect fuse settings? Unless it is faulty from ATMEL...
If all apparent reasons (shorts, broken lines, ESD, overheating during soldering, etc) are eliminated, few more reasons are only left - or it is lock, a reject or a fake.
Atmel is few years ago sold to Microchip. Can you confirm you buy it from them, not some Chinese source?
Anyway, may be interesting for you to read this about fake 328p:
People I know and buy from China, confirms that they have more fake ICs than actually worked...
Since prices in local electronic shops are extremely high, I have asked them about experience and I believe that they do not lying, as they are not prone to do that at all.
Ok...I have another board here with a different IC. I have just burnt a bootloader onto that using the exact same method.
Reset line drops low and STAYS LOW during the entire process. The fact my MISO line drops down when reset goes high is expected. So the issue is reset is going high when it should be kept low.
The question is why?!
Confident that if I can sort this then it should work.
I am not convinced it is fake, especially as I have used LCSC in the past for IC's and all sorts, as have many others. As I said, they are like Digikey & Mouser in terms of what you can expect from them.
The issue was that I was connecting the reset to the 6-pin header which goes HEADER > 100nF Capacitor > RESET on IC, in the end I just connected a wire directly to the RESET pin on the IC and BOOM, it works AND the RESET line goes low and holds low. The capacitor was basically keeping the RESET line held high, hence it dropped down, then would rise up as the capacitor charged up.
Feel a bit stupid for not thinking about that earlier, but oh well, at least it's not some major fault.
Argh - my bad for overlooking that on the scope traces you posted; Had I noticed that reset line behavior, I would have instantly recognized what happened.
ISP programming is essentially SPI slave with RESET used as CS.
