When using avrdude+usbasp on programming avr chips, often one would get:
avrdude error: program enable: target doesn't answer (0x01)
This is a very common error and there are tons of messages related to it on the Internet. Typical answers/suggestions are:
- check programmer pins/wiring connection
- MCU's fuses were previously programmed to use external crystal
- programmer default speed (375KHz usbasp) too fast for MCU with internal Oscillator
- bad avr chip
However, what happens to me really did not appear to belong to any one of the above. I moved to Linux (MX 23, Debian 12) from Windows and is using new tool chains for AVR. To upload the object HEX file to the AVR, I use AVRDUDE. The hardware programmer is a common Ali express Usbasp I bought 5 years ago. The target MCU is ATMega16 with a crystal of 7.3728MHz and fuses set up accordingly.
The first object hex file upload operation using avrdude was fast and completed without any issues. However, starting from the second and subsequent operations, the avrdude interface was consistently reporting the above dreaded "Target does not answer" error message. I unplugged the usbasp and plug it back in again. Same thing happens with successful first operation and subsequent failures. I tried reading only the Fuses but its just the same. (Screen capture terminal log)
/?action=dlattach;attach=2303595)
The part that intrigues me most is why it all went so well in the first operation using the default SCK programming clock speed, but failed consistently afterwards. I need to find out what part of the system is at fault. Being a hardware guy I dug out my logic analyser(LA) and connected up four channels directly on the following (reset, SCK, MISO, MOSI) AVR pins, right on the AVR chip itself. With the Usbasp plugged in and the LA trigger set on falling reset level, I issue the first command to Avrdude and got the following response. You can clearly see the 4-bytes "enable programming mode" request(0xAC, 0x53, 0x00, 0x00) on MOSI line and AVR echo back 0x53 on the MISO line as an acknowledgment. This is in perfect agreement with what the data sheet recommended for serial programming. So far so good as it is expected. (First run screen capture)
/?action=dlattach;attach=2303615)
Now, what will the situation be like on issuing subsequent commands? This is what I've got on the LA. It is completely different from the initial capture. I got a lot of activity on SCK and MOSI line, and they were all the 4-byte "enable programming" request sequences. Sadly the AVR does not acknowledge any of them. But wait, what happens to the first few bytes of the request? Looking carefully, instead of the usual 4-bytes, it is only 3 bytes long. The 0x53 bytes was missing. To be absolutely sure I did the capture again the third time and no, byte 0x53 is still missing.( second run screen capture)
/?action=dlattach;attach=2303583)
No wonder the AVR does not answer. After taking the Reset pin low, AVR is expecting a 4-byte data packet. Giving it only three would just means the following byte will be taken as the fourth byte. After issuing many many "out of sync" 4-byte enable programming packets to the AVR, usbasp finally gave up and report failure to avrdude. This is the reason why we get the "Target does not answer" error.
My next trial was to reduce the programming speed manually to see what happens. The 0x53 byte is still missing at SCK=94KHz bit but it suddenly reappears at SCK=32KHz. I tried many operations at SCK=32KHz and all were successful. This indicates to me that the problem lies entirely on the "missing 0x53" byte. If we can figure out why it is missing, then we can solve the above error.
/?action=dlattach;attach=2303587)
This is new to me. The same code producing different result when run for a second time. This type of software troubleshooting is out of my depth. I look at the most recent Source Code of usbasp "usbasp.2011-05-28.tar.gz (519 kB)" from the Thomas Fischl website and find the following code inside the isp.c file, relating to the output of these four bytes, but everything seems in good order and I couldn't figure out why 0x53 is missing. Also in reality I didn't observed any pulsing on the reset line when the program enable check fails, which it should.
uchar ispEnterProgrammingMode() {
uchar check;
uchar count = 32;
while (count--) {
ispTransmit(0xAC);
ispTransmit(0x53);
check = ispTransmit(0);
ispTransmit(0);
if (check == 0x53) {
return 0;
}
spiHWdisable();
/* pulse RST */
ispDelay();
ISP_OUT |= (1 << ISP_RST); /* RST high */
ispDelay();
ISP_OUT &= ~(1 << ISP_RST); /* RST low */
ispDelay();
if (ispTransmit == ispTransmit_hw) {
spiHWenable();
}
}
return 1; /* error: device dosn't answer */
}
Finally, it dawns on me that even I couldn't figure out why byte 0x53 is missing, I can patch up the situation by forcefully inserting one extra byte such that the byte packet length returns to 4 again. I did it by doing one more "ispTransmit(0x00)" if the enable check fails.(see image) I built the usbasp firmware from source with the patched isp.c file and flash it to the usbasp programmer. The resulting LA capture confirms that the patch works and AVR responded by the next enable programming request. Now I can issue commands to avrdude and I do not get that dreaded error message again. Also the up/down load speed is about 375KHz instead of the slow 32KHz which everything works. I even try the option of "-B 0.5" on the command line, which increase the SCK speed to 1.5MHz. Reading the whole flash feels like a breeze compares to the 32KHz speed before.
If your are currently still using "-B 32kHz" in your avrdude command line because of the dreaded error above, I hope this post can offer the needed help.
/?action=dlattach;attach=2303591)
Remaining questions: (probably no one would want to answer)
1. Why 0x53 is missing in second and subsequent trials, but magically reappears if SCK is reduced down to 32KHz?
2. How would one troubleshoot such situation and find out the real cause?
When sending data you should read SPDR after each byte to clear SPIF:Code: [Select]