I was an happy man until tomorrow morning
My happiness of using all of the 32K of flash memory (see my post here) has completely flatted down after I discovered that, after turning the power ON, my pro mini simply doesn't start like it was doing yesterday. And I touched nothing! :o
Here what is happening: after uploading a sketch with the USBasp programmer the pro mini reset and start the program normally. If I turn it off and on again, it re-starts without problems.
BUT, if I
turn off the pro mini,
wait 1 minute,
turn on the pro mini again.
then... nothings happens. The uploaded sketch simply doesn't start.... :o
If I turn it off/on in a range of max 20 seconds then no problems, if I wait too much before turning it on then I'm done. It doesn't restart.
I have to upload again the same sketch to see arduino starting and working. What's going on?
(In the attachment my simple circuit)
I thought that maybe the Vcc was going down for some strange reason, so I have attached my multi-meter to check it.
The voltage is 3.3-3.35 V, perfect for my ProMini 8Mhz/3v3.
I've also discovered one thing: after switching off the power, the voltage goes slowly down (like a discharging capacitor).
If I turn on arduino before it goes below around 0.10 Volt then it starts normally. On the other side, if the voltage drops below that value then arduino doesn't restart when I switch the power on again.
If I replace my arduino on the breadboard with another one programmed by using a traditional FTDI breakout (max 30K of flash) then zero problem. I can power it off and on as many times as I want, zero problems.
So the problem must be the ISP programming itself.
What's going on? Any idea? :-\
P.S: the arduino I'm using is new, never used before. By Sparkfun.
Have you burned bootloader with a configuration that has the fuses configured to not jump to bootloader?
You need to "burn bootloader" with a board definition that doesn't have BOOTRST set (even though you are not using a bootloader, you still need "burn bootloader" to set the fuses), otherwise it will try to jump to the location where it's expecting the bootloader - and which, if you've uploaded a large program to it, is populated with program code now. The behavior of this could conceivably vary based on the contents of ram, and since some of the data in memory can persist with power off longer than you'd expect, it's not inconceivable that the behavior you describe could be generated.
you could be right. Maybe arduino is still expecting to find a bootloader...
I just picked a new Pro Mini from my drawer. It comes from Sparkfun with their "big" 2K bootloader.
After, I simply uploaded the sketch by using the following configuration:
So I didn't preventively burned the bootloader.
I never burned a boot-loader before, can you post a link to an example?
More difficult for me is how I can understand if a board definition set the fuses or not. What I should check/search? In what configuration file?
Below what is reported in the main page of the Minicore libs on GitHub:
"Note that you need to select Bootloader: "No" and actually hit Burn bootloader in order to set the correct fuse bits. Now you're no longer able to upload using serial, until you select Bootloader: "Yes" and burn the bootloader again."
Shame on me.... :-[
Seems that all I have to do is:
Step 1: press "Burn Bootloader" to set the fuse bits. Step 2: upload the sketch as before.
Now I cannot access to my little "laboratory" to test this solution. I have to wait until tomorrow, I will report my results here.
I really hope that this is the reason of the problem. I cross my fingers!
With the same configuration as above (Bootloader = No) I tried to burn the bootloader via USBasp.
As output, I see the "burner" program setting the fuse bits without problems (three or four bits, if I remember right), but it end with an error message:
avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: error: program enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
the selected serial port
does not exist or your board is not connected
After this, I tried the same to upload my sketch but the operation ends immediately: "avrdude: error: program enable: target doesn't answer. 1 "
I tried to burn again the bootloader but, again, the operation is aborted as above.
The fusebits set and then an error is characteristic of the fusebits being set wrong in a way that broke the board. But you're using an 8mhz pro mini which should have external crystal (besides, that gives signature of 0x000000, not target didn't answer), so what other setting could be breaking the board?
Say, measure the voltage on it's vcc with it connected to the USBAsp... Are you really getting 3.3v on vcc? (if it's undervoltage enough to trip the BOD, maybe that would give that error?)
I was constantly monitoring the voltage with a DMM. When the pro mini is powered via the USBasp dongle it is constantly at 3.4 V +/- 0.1.
Anyway, even powering arduino via a stabilized power supply at 3.3V does not affect the defect.
Now I have two brand new pro mini in front of me. Nevertheless, I would be sure of what I'm doing before going to fry them too.
BTW, after the setting of the four fuse bits, I clearly remember a line reporting a "content mismatch error" against a file called "empty.hex".
If I remember right, the following line was reporting an error like "0x00 is not 0x0c", or something like that.
Unfortunately, when I clicked on the command "Upload" the previous output on the screen was wiped out. Was better to make a copy of that text-output before going further. Shame on me!
After investigating in the "MiniCore" directory located under my home folder, I have found the file "board.txt" containing the settings for all of the supported boards:
Line from #141 to #248 contains the settings for the fuse bits. But I have not necessary background about the Atmel processor to decide if the values are correct or not...
I was strongly suspecting that the TFT was sucking current in the exact moment when the pro mini is reset. In fact, the default behaviour of the TFT is to show a blank white screen when it is turned on. White color drains a lot of current!
So I completely detached the pro-mini from the breadboard. Then I connected all the wires from the USBasp to the arduino pins.
BOOM!
The "Burn bootloader" command (with Bootloader=No option) has worked like a charm:
/home/giulio/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino9/bin/avrdude -C/home/giulio/.arduino15/packages/MiniCore/hardware/avr/2.0.0/avrdude.conf -v -patmega328p -cusbasp -Pusb -Uflash:w:/home/giulio/.arduino15/packages/MiniCore/hardware/avr/2.0.0/bootloaders/empty/empty.hex:i -Ulock:w:0x0f:m
avrdude: Version 6.3, compiled on Jan 17 2017 at 11:00:16
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/home/giulio/.arduino15/packages/MiniCore/hardware/avr/2.0.0/avrdude.conf"
User configuration file is "/home/giulio/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : usb
Using Programmer : usbasp
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : usbasp
Description : USBasp, http://www.fischl.de/usbasp/
avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3f:
avrdude: load data lock data from input file 0x3f:
avrdude: input file 0x3f contains 1 bytes
avrdude: reading on-chip lock data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "0xfd"
avrdude: writing efuse (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xfd:
avrdude: load data efuse data from input file 0xfd:
avrdude: input file 0xfd contains 1 bytes
avrdude: reading on-chip efuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0xd7"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xd7:
avrdude: load data hfuse data from input file 0xd7:
avrdude: input file 0xd7 contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0b11110111"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0b11110111:
avrdude: load data lfuse data from input file 0b11110111:
avrdude: input file 0b11110111 contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude done. Thank you.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "/home/giulio/.arduino15/packages/MiniCore/hardware/avr/2.0.0/bootloaders/empty/empty.hex"
avrdude: writing flash (2 bytes):
Writing | ################################################## | 100% 0.13s
avrdude: 2 bytes of flash written
avrdude: verifying flash memory against /home/giulio/.arduino15/packages/MiniCore/hardware/avr/2.0.0/bootloaders/empty/empty.hex:
avrdude: load data flash data from input file /home/giulio/.arduino15/packages/MiniCore/hardware/avr/2.0.0/bootloaders/empty/empty.hex:
avrdude: input file /home/giulio/.arduino15/packages/MiniCore/hardware/avr/2.0.0/bootloaders/empty/empty.hex contains 2 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.07s
avrdude: verifying ...
avrdude: 2 bytes of flash verified
avrdude: reading input file "0x0f"
avrdude: writing lock (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x0f:
avrdude: load data lock data from input file 0x0f:
avrdude: input file 0x0f contains 1 bytes
avrdude: reading on-chip lock data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude done. Thank you.
After that, I uploaded my sketch (32726 bytes) with success by using the command "Upload Using Programmer"
Now the bed news....
After placing the pro-mini back to the breadboard and powering it......... nothing. It doesn't start. The TFT screen stay blank and even pressing the reset button can resuscitate the arduino.
While keeping it on the breadboard (and the TFT connected) I tried to issue the command "Upload Using Programmer" to see if it can force the re-start of the program as before.
Below the output:
avrdude: error: program enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
the selected serial port
does not exist or your board is not connected
To summarize, here my experience after burning pro-minis for an equivalent value of 35 dollars:
1. USB cable + FTDI breakout + "Upload command"
Works solid as a rock. Doesn't matter if the TFT is attached or not. Drawback: the original bootloader from Sparkfun is a dinosaur, it occupies 2K of the 32K of flash memory available.
2. USBasp dongle + "Upload Using Programmer"
Works with the TFT attached (but you have to use a 10K resistor on the MISO line). Drawbacks: sometimes the sketch won't start during a series of power-cycles.
3. USBasp dongle + "Burn Bootloader" + "Upload Using Programmer"
Two sub-cases:
3.1 It will destroy your pro mini if the TFT is attached.
3.2 It will works if the TFT is completely disconnected. Drawback: the sketch won't start when the TFT is connected.
Note: in both cases 2 and 3 I was trying to use almost all of the flash memory available (32768 bytes), so I was using the option "Bootloader=No"
EDIT
About point 3.1, I've discovered a wire not firmly inserted into the breadboard. Maybe that was the problem. I have to redo the test for final confirmation
He reports that the problem is caused by a bad firmware on his USBAsp.
It may be that there's a new batch of USBAsps going around that has firmware with a fatal bug going around (this would explain why we're only now getting reports like that). If you can confirm f/w upgrade fixes it, complain to seller and try to make them aware so that the problem reports get propagated up the supply chain...
Boards are probably recoverable with HVSP, but HVSP requires modifying the board because of the probably unnecessary diode from reset to vcc.
Maybe I'have solved this issue.
But wait before clapping hands, I have to check if the sketch works properly once soldered on my PCB with all the rest of the circuitry around.
The key seems very simple: you have to completely remove the Pro mini from your breadboard or PCB before attempting to do anything with it.
It doesn't matter if you want to burn the bootloader or simply update your sketch with a new version. Get it out from your circuit in any case. Then connect the wires from the USBasp dongle directly to the opportune pins. Nothing else should be attached/connected to the Pro mini when using the programmer. Simple as that.
I made a lot of power-cycles tests: the arduino restarts in any condition of voltage status. Zero issues at all.
Also, I allowed the discharging of all of the inner capacitances during the night. When I powered again this morning, it has started flawlessly.
I also repeatedly uploaded the same sketch (32726 bytes) six times using the above technique. Again, zero issues.
As stated in the beginning, now I have to test it into the "real world" before considering this problem closed. But we are in the weekend and my family needs me as driver!
