SOLVED. Problem: sketch deletion after power off

I uploaded a new bootloader on a virgin ATmega328; then I mounted it on an Arduino UNO.
Now i can upload any sketch on it but, when I power off Arduino, the sketch is deleted and I must upload it again.

What's wrong?

uploaded a new bootloader on a virgin ATmega328; then I mounted it on an Arduino UNO.
Now i can upload any sketch on it but, when I power off Arduino, the sketch is deleted and I must upload it again.

This simply us not possible. A sketch is in flash memory, the bootloader has access to this space to write, but user-code does not. The flash (program) area is persistent storage- just like a camera flash card.

Something else is wrong.

The bootloasder must follow the board description, so Optiboot is the preferred bootloader for the UNO, but others exist and may require changes as a new entry in boards.txt file.

Flash the chip again and select Uno (stock, unchanged entry) as the board. Burn the bootloader. The chip should be a perfect clone if the Atmega328P-PU that came with the Uno board.

Manual process:
http://www.instructables.com/id/Copy-n-Paste-Arduino-Firmware/

Ray

We do get this perceived problem from time to time here.
Most of the time it boils down to one of powering or misunderstanding of when it is running a sketch.

So can you give more details please.

this is EXACTLY what happens when flash wears out. it starts behaving more like ram than flash. unlikely the case here as it takes considerable effort to wear out flash. more likely grumpys theory is correct, ie user error.

I uploaded a new bootloader on a virgin ATmega328

this is EXACTLY what happens when flash wears out. it starts behaving more like ram than flash.

@john1993:
AVRDUDE and the bootloader doors a page-by-page erase, write, verify. I have never heard of flash programming correctly and working only until power is removed. I am not disputing your statement, I have just never experienced or read about this particular behavior. I have seen bad flash where programming would start but error-out before complete.

In any event, your explanation should not apply to a "virgin" uC.

Ray

a couple guys on freaks (old timers) experienced same "worn out" flash syndrome. i can tell you i have three 90s1200 and one m8 on hand in my museum of special chips that dont hold code. one 1200 loses program as soon as power is removed and the others overnight. 100% reproducible. only thing these have in common is hundreds of thousands of isp flash/erase cycles. if you understand just how these device work it also what is expected from theory. lattice degradation with subsequent leakage.

a couple guys on freaks (old timers) experienced same "worn out" flash syndrome.
<..>
lattice degradation with subsequent leakage.

I have just never worn one out. My gut feeling would have been the page verify after write would have caught the issue; but since I have not personally witnessed it, I will update my thinking process to include this scenario for the elder chips.

Thanks,

Ray

I solved the problem. I just reloaded the bootloader on the chip with the standard procedure, and now every problem is gone. However, I do not know give me an explanation.

Thanks for replies!

Sounds to me like you might have had a different version of the boot loader.
It could happen if the initial start up vectors are not set correctly.

Was a sketch loaded without using the bootloader?
If so the bootloader is erased and has to be loaded again.
--- bill