Hello all, not been here for a while, I've have been on the 8266 forum a lot. But I've come across a problem I can't wrap my head around. It started out with wanting to migrate a project started last year and put aside, which used 3 DS 18b20 sensors on 1Wire bus that I'd set up back then on a pro-mini. That was done using an older IDE (1.6.x)
It worked great, and I wanted to move that over to an ESP-12 (8266). I ran into issues, reading the sensors so I put them back on the pro-mini. When I tried to upload the sketch however the pro-mini did not respond. This led me to believe that somehow the bootloader had gotten corrupted. I've tried several methods found around the internet and the forum of reloading the boot loader using the UNO as an ISP. None were successful. A good example is here [url=https://www.instructables.com/id/Burn-a-New-Bootloader-Arduino-Pro-Mini/?ALLSTEPS[/url]. the result was an error from the IDE of:
Arduino: 1.8.1 (Windows 10), Board: "Arduino Pro or Pro Mini, ATmega328 (5V, 16 MHz)"
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.
Error while burning bootloader.
This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
Then my USB port froze up. I rebooted my laptop and tried again with this as an error:
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x03
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x03
Error while burning bootloader.
I'm totally confused at this point as to how to properly reload the bootloader on to the pro-mini. I can tell you it is a 5v 16mhz version. Any and all help would be greatly appreciated.
It doesn't matter how the sensors are connected, as long as only one is connected it reads, more than one it errors. My concerns here are 2 fold. 1. the issues with the sensors, and 2. the issues with reloading the bootstrap loader.
Hi Pert, thanks for the reply, yeah, I saw that verbose notification in the error message. I had done just as you suggested, and that time around I got the same thing without the "verbose suggestion". I'll try duplicating it and post as you suggest, thanks again.
Arduino: 1.8.1 (Windows 10), Board: "Arduino Pro or Pro Mini, ATmega328 (5V, 16 MHz)"
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.
Error while burning bootloader.
That's about it. I'm wondering if there is some configuring to be done in the sketch I may have missed, but when I followed the instructional I'd mentioned, it didn't refer to any.
No DrAzzy I did not miss it. I invoked it. And what you see is what I got.
Now onward.
I have after close scrutiny discovered the pro-mini I'm working on has pins mislabeled. After straightening that mess out. I tried it again. this is the result.
***failed;
avrdude: WARNING: invalid value for unused bits in fuse "efuse", should be set to 1 according to datasheet
This behaviour is deprecated and will result in an error in future version
You probably want to use 0xfd instead of 0x05 (double check with your datasheet first).
flagtrax:
No DrAzzy I did not miss it. I invoked it. And what you see is what I got.
Strange, usually it should show what signature was read, which can give us a clue to the problem.
flagtrax:
***failed;
Is that all there was? It doesn't give us much to go on.
flagtrax:
avrdude: WARNING: invalid value for unused bits in fuse "efuse", should be set to 1 according to datasheet
This behaviour is deprecated and will result in an error in future version
You probably want to use 0xfd instead of 0x05 (double check with your datasheet first).
Well I'm as confused as a newborn baby in a topless bar.
I'd think "failed" shows a problem.
This website indicates that the ext fuse should be 0x05 why does averdude tell me otherwise?
The bit about 0xfd vs 0x05 is a warning not an error. You can disregard it. It's a matter of semantics, and what convention is used for "unused" fuse bits. It used to be that (via avrdude.conf) they could be specified to be treated as 1s or 0s. That was changed in recent version of avrdude to enforce treating them as 1's - but since it wasn't always enforced, lots of material exists that treats it differently, and fixing it causes backwards compatibility issues; the arduino version of it was modified to make it a warning (in one version, the included version enforced that, and it was a shitshow, as you might imagine). The reasons behind the AVRdude author's decision on this behavior is unclear to me.
The output you have posted does not look like verbose output. Verbose output includes a whole bunch of junk at the beginning, and also prints what it expected for signature, and what it also got. Could you have instead only set verbose compile output or something?
ER ah phew. OK well... I think... I get what your telling me but it sure makes an unsure neophyte sweat
As far as the verbose output the options are during compilation and upload. No I didn't check the upload box being unsure if it is considered an "upload" when using the Uno as the ISP. The "failed" indication still has me puzzled though. More so now Because I uncoupled the two, and connected the pro-mini to another USB port, and it appears to be functioning normally?!?! At least I've loaded a couple sketches to it. But with that dirty word "failed" I'm not sure it's totally clean............BTW Your guidance is greatly appreciated. If you'd like I can plug them together again an run another test.......
I'm guessing this is more what you expected to see. This run seemed to be clean.
Could that "failed" been from an earlier message? The initial culprit I'd say here was the mislabeled pins. Thanks again for the great help. Now I can go back to the 18b20 issue.
Well I tried to place the verbose output here but it exceeded the character limit for the post
(>9000) I'll try to attach a .txt
Ah, much better, "upload" just means any avrdude output in this case. Obviously that suggestion the IDE provides automatically about verbose output on compilation is wrong in this case. I've been meaning to report that to the developers but didn't manage to reproduce it when I last tried. Glad to see things are working for you now. I've seen that "failed" thing show up before, and in fact even the Arduino developer thought it was strange when it was bought to his attention:
but as you can see from the verbose output it did verify so I think it's safe to ignore.
I generally leave verbose output on compilation disabled unless I need to debug something involving the build process because the information it provides is not generally useful and it really clutters up the console and makes it harder to see the important compiler warnings or errors. I think it's best to not have verbose compilation enabled when you post console output to the forum unless it's specifically relevant because it makes it much more likely that you'll go over 9000 characters and you will likely get less eyes on your issue if people need to download a file to see what's going on. I always have verbose output during upload enabled because I like to see the progress of the upload.
OK so this saga continues. I can write a sketch to the pro-mini......once. Then it will not accept input. If I reload the bootloader I can cycle it again.....once. I thought I'd seen mention of this behavior somewhere on the forum, but can't seem to find it. Anyone know what the solution to this is?
Thanks
flagtrax:
OK so this saga continues. I can write a sketch to the pro-mini......once. Then it will not accept input. If I reload the bootloader I can cycle it again.....once. I thought I'd seen mention of this behavior somewhere on the forum, but can't seem to find it. Anyone know what the solution to this is?
Thanks
Generally this indicates a problem with the autoreset - is the DTR (or RTS) pin of your serial adapter connected to the last pin on the 6-pin serial header at the end of the board?
Also, if you're manually setting fuses or something and use the fuse settings for non-bootloader configuration (ie, no BOOTRST, or incorrect BOOTSZ fuses combined with a large sketch), you get the same behavior - this requires a good deal of effort to do it wrong, though . And I got a batch of bad pro minis from china ($2 each, I can't complain too hard) where the autoreset circuit was just straight up wrong, like a year and a half ago.
