Go Down

Topic: Standalone board with ATMEGA8A [solved] (Read 1 time) previous topic - next topic

KenshinPT

Jul 27, 2013, 09:19 pm Last Edit: Jul 29, 2013, 09:45 am by Nick Gammon Reason: 1
Hey! How've you been?

I know that for some guys ATMEGA8 is so old school but I have a dozen of then and I don't want to toss then out :)

I made a standalone board using:
- ATMEGA8A
- 16MHz resonator
- ICSP connections so I can use the USBasp
- 10K resistor from Vcc to reset
- 10uF capacitor from reset to ground
- Pushbutton in parallel with the above capacitor
- And a 7805 voltage regulator and the regular in and out capacitors.

The question is:
Whenever I try to re-upload a sketch the uC stays with the old firmware. Arduino IDE says that the upload was successful but it isn't. Why?

If I erase the ATMEGA and try to re-upload everything runs smoothly.

Any help?

Thanks

Regards.





CrossRoads

Under File:Preferences, check the Verbose boxes.
What is reported there?
Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.

KenshinPT

Ops... I didn't read this:

----
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0110
         0x63 != 0x61
avrdude: verification error; content mismatch

avrdude done.  Thank you.
----

However, I don't understand why the content is mismatch!

Thanks

KenshinPT

New developments:

After erasing the ATMEGA8A on eXtreme Burner I can do the following:

1) Program it OK with arduino.
2) Make a change on the code and flash it again. It's OK.
3) Make a second change on the code and flash it again. It's OK.
4) Third change on the code and a mismatch byte occur!!!

I can also do this after an erase on eXtreme Burner.
1) Program it OK with arduino.
2) Make NO changes on the code and I can flash it infinite times (I tried 4 times in a row so I guess I can say infinite :)
3) Make a change on the code and flash it again. It's OK
4) Make a second change on the code and flash it again. It's OK
5) Third change on the code and a mismatch byte occur!!!


Now what? :D

westfw

Quote
- 10uF capacitor from reset to ground

This is wrong.  The 10uF from reset to ground is a thing done to prevent auto-reset from happening when you use an Arduino as an AVR programmer (using ArduinoISP sketch.)  You shouldn't normally have it there.

(I can't see how that would cause your problems, though.)

Are you using "upload using programmer" ?  If not, and If your programmer somehow succeeded in being compatible with the Arduino bootloader, it could be getting commands that are incompatible with its functioning.  Specifically, the bootloader erases one page at a time before writing, but a programmer HAS to do a full chip-erase before it starts (HW programmers CAN'T do page erases!)  So when using the bootloader, Arduino gives avrdude the -D flag telling it NOT to do the chip erase; your symptoms could be explained by the programmer trying to overwrite the existing sketch without erasing the old one...

KenshinPT


Quote
- 10uF capacitor from reset to ground

This is wrong.  The 10uF from reset to ground is a thing done to prevent auto-reset from happening when you use an Arduino as an AVR programmer (using ArduinoISP sketch.)  You shouldn't normally have it there.
(I can't see how that would cause your problems, though.)

I agree with you. This capacitor can't make no harm! Because the reset line is sent from the USBasp directly to the reset pin.


Are you using "upload using programmer" ?  If not, and If your programmer somehow succeeded in being compatible with the Arduino bootloader, it could be getting commands that are incompatible with its functioning.  Specifically, the bootloader erases one page at a time before writing, but a programmer HAS to do a full chip-erase before it starts (HW programmers CAN'T do page erases!)  So when using the bootloader, Arduino gives avrdude the -D flag telling it NOT to do the chip erase; your symptoms could be explained by the programmer trying to overwrite the existing sketch without erasing the old one...

I am using an USBasp to do the programming. I tried with and without bootloader. This symptoms are the same.
I also agree with you. I beliese that USBasp is not able to perform a chip erase before flashing the uC,

The strange thing is that if I use eXtreme Burner to flash there is no problem at all. Maybe there is a bug on arduino IDE!

Regards

westfw

Quote
I am using an USBasp to do the programming.

Yes, but are you using the "upload" button/command, or the "upload using progammer" (SHIFT-upload button)?
The bootloader uses the "stk500 protocol" over a serial connection.  This is ALSO the protocol and communications channel used by some device programmers (in fact, it is originally a device programmer communications protocol.)  So it's entirely possible that if you are using a USBASP programmer, that it would PARTIALLY work using the "upload" command, when you should be using the "shift-upload" command.

Here's the avrdude command used for "upload" (via the bootloader.) 
avrdude  -q -q -patmega328p -carduino -P/dev/cu.usbmodemfd3141 -b115200 -D -Uflash:w:Blink.cpp.hex:i

And here's the avrdude command used for "upload using programmer" (with "programmer" set to AVRISP.)
avrdude  -q -q -patmega328p -cstk500v1 -P/dev/cu.usbmodemfd3141 -Uflash:w:/Blink.cpp.hex:i
(Note that -carduino is approximately the same as -cstk500v1)

KenshinPT

#7
Jul 29, 2013, 01:06 am Last Edit: Jul 29, 2013, 01:12 am by KenshinPT Reason: 1

Quote
I am using an USBasp to do the programming.

Yes, but are you using the "upload" button/command, or the "upload using progammer" (SHIFT-upload button)?
The bootloader uses the "stk500 protocol" over a serial connection.  This is ALSO the protocol and communications channel used by some device programmers (in fact, it is originally a device programmer communications protocol.)  So it's entirely possible that if you are using a USBASP programmer, that it would PARTIALLY work using the "upload" command, when you should be using the "shift-upload" command.

Here's the avrdude command used for "upload" (via the bootloader.) 
avrdude  -q -q -patmega328p -carduino -P/dev/cu.usbmodemfd3141 -b115200 -D -Uflash:w:Blink.cpp.hex:i

And here's the avrdude command used for "upload using programmer" (with "programmer" set to AVRISP.)
avrdude  -q -q -patmega328p -cstk500v1 -P/dev/cu.usbmodemfd3141 -Uflash:w:/Blink.cpp.hex:i
(Note that -carduino is approximately the same as -cstk500v1)


Problem solved! Thank you so much for your help.

I was not aware about the shift+upload.

Also, I was able to program the uC the way I report above because I made a change on the boards.txt file in the "atmega8.upload.protocol" from "arduino" to "usbasp".

I found it strange... But hey! I am not an expert ^^!

Regards

Go Up