Digistump Forums
The Digispark => Digispark (Original) Support => Topic started by: albercook on August 17, 2013, 09:31:25 pm
-
I think I understand how this is supposed to work but let me explain what I'm doing to see if I have it right.
I have the latest version of the DigiSpark Arduino software and it works on
1) I have and Arduino that I have installed the ArduinoISP sketch on. It is running at 3.3V not sure if that matters.
2) I have connected the pins of the ISP programmer as follows
Reset - 1
MIOS - 6
SCK - 7
MOSI - 5
GND - 4
VCC - 8
I also tried external power with a common ground.
The raw attiny is on a carrier board and plugged into a breadboard
3) I choose tools>Board>DigiSpark (tiny core) Not sure what "tiny core" means
4) I choose tools>programmer> Arduino as ISP
5) I choose tools>Burn Bootloader
I get the following error.
Running AVRDUDE...
avrdude_original: stk500_getsync(): not in sync: resp=0x00
Running AVRDUDE...
avrdude_original: invalid file format '\Documents' in update specifier
avrdude_original: error parsing update operation 'flash:w:C:\Documents'
The problem must be rather fundamental
because I can us the programmer to program other attiny chips. The 14 pin attiny84 for example. I did this following the high-low tech example at http://hlt.media.mit.edu/?p=1695
I have tried several different chips even some off of DigiSparks.
Do I need to do something with the fuse bits?
The part number is ATTINY85-20SH-ND from DigiKey.
Any help will be much appreciated. If there is interest I will write this up in the wiki once I get it working.
Thanks
-
Some small success. I was able, once, to program the attiny85 with a version of the Blink sketch by setting the board to attiny85 1 mHz. I read somewhere that they come set to 1 mHz. It only work once. I gather that when you select "Burn Bootloader" it does different things depending on which board you have selected.
-
Once you use Burn Bootloader, you can never program that chip again using an ISP programmer. To gain access with an ISP programmer again you need to use a tiny fuse resetter circuit or a high voltage serial programmer - both require 12v power supply and the later costs at least $50. If your goal is simply to upload programs to attiny85 chips using an ISP programmer, never use the burn bootloader feature. The cost of not using the bootloader is that you cannot use the reset pin (pin 5) for anything - it's used by the ISP upload process exclusively.
Once you burn the bootloader, the ISP mode is disabled and the only way to upload new programs is via HVSP device, or by connecting the chip directly to a USB port using the same circuit as the littlewire.cc schematic. You maybe able to get it to work on your computer without zenner diodes - but some computers require them, or alternatively you can run the attiny85 on 3.6v itself, and that seems to work, but I can't promise you it wont break glitch out and break at such low voltages using the bootloader as it is totally out of spec for these chips.
If you don't need that extra pin and you don't need to add a USB port anyway for something else, you might as well just use ISP upload mode. To do this, choose your programmer in the tools menu, then in the file menu choose Upload Using Programmer. I think the regular "Upload" works too. Depending on what sort of programmer you're using you may need to also choose it's serial port in the tools menu, but this isn't necessary for USBtinyISP devices like the littlewire firmware loaded on a digispark.
And here's where I was about to write how the sketch detects it's on a non-bootloaded chip and automatically switches the speeds around so the 8mhz sketch runs at 8mhz even on blank chips that normally run at 1mhz, without even having to change the fuses. Neat huh? Except I guess I only thought a lot about implementing it and never actually wrote the code! Frick! Okay that's going to be a feature in a future version of the digispark IDE. Cool.
In the mean time you need to use some kind of avr fuse setting app to set it to use the internal PLL clock source, or all the boards will run their programs at half the speed you selected. Lame I know! I really thought I had fixed this :-\
-
Thanks for your reply. I understand a lot more now. Let me explain what I'm trying to do and ask a few more questions.
I have designed and built a pcb for a small helicopter. I want to use the Digispark version of the Arduino software. I have the diodes and all working with an attiny that i have removed from a DigiSpark. So I only want to program the bootloader once. From then on I will use the USB interface.
So my plan is to program the attiny85 chips before i solder them onto my boards. Now for the questions.
1) I have an Arduino Mini that I have turned into an ISP. It runs at 8 mHz and 3.3 Volts. Do you see any reason that will be a problem?
2) is it the case that the DigiSpark version of the Arduino software chooses to install micronucleus, as opposed to the Arduino bootloader based on the board that is selected?
3) will there be any indication that the bootloader has loaded properly?
Thanks
-
OK so I tried this again. The first time I did get activity on the TX and RX LEDs on the FTDI board connected to the Arduino Mini that is running the Arduino ISP code. I also got the following errors
Running AVRDUDE...
avrdude_original: please define PAGEL and BS2 signals in the configuration file for part ATtiny85
avrdude_original: please define PAGEL and BS2 signals in the configuration file for part ATtiny85
Running AVRDUDE...
avrdude_original: invalid file format '\Documents' in update specifier
avrdude_original: error parsing update operation 'flash:w:C:\Documents'
The first two I have seen before when following the High-Low Tech example and was able to ignore them.
The next two errors do not look good.
If I try it again i get the very little activity on the LEDs and the following errors
Running AVRDUDE...
avrdude_original: please define PAGEL and BS2 signals in the configuration file for part ATtiny85
avrdude_original: stk500_program_enable(): protocol error, expect=0x14, resp=0x50
avrdude_original: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude_original: stk500_disable(): protocol error, expect=0x14, resp=0x51
-
I think the path to Arduino can't have spaces in it for this to work - and because the command also sets the fuses then the fuses are set and so you can't program it again.
-
@albercook: have a look at my tutorial in the wiki: http://digistump.com/wiki/digispark/tutorials/programming
That should cover a a lot of your questions. While you are working on similar stuff, you may be able to add some things I have missed.
.g
-
Hello,
i have the exact same problem, im trying to upload the digispark bootloader with an arduino as isp to an Attiny85.
ive uploaded the arduino isp code to an UNO and then select the Digispark (Tiny Core) board and Arduino as ISP as a programmer and im getting the same error as albercook.
Running AVRDUDE...
avrdude_original: please define PAGEL and BS2 signals in the configuration file for part ATtiny85
avrdude_original: please define PAGEL and BS2 signals in the configuration file for part ATtiny85
Running AVRDUDE...
avrdude_original: please define PAGEL and BS2 signals in the configuration file for part ATtiny85
avrdude_original: stk500_program_enable(): protocol error, expect=0x14, resp=0x50
avrdude_original: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude_original: stk500_disable(): protocol error, expect=0x14, resp=0x51
After this the attiny85 was bricked and i used a high voltage programmer in order to reset the fuses and the chip works again but still cant burn the bootloader.
albercook did you find a solution to this or did anyone find a solution of how to burn the bootloader using Arduino as ISP?
thanks
-
That's the error I would expect to see if the bootloader has already been burnt successfully
-
i dont think its burned successfully cause im connecting the attiny85 with usb after that and im getting Unknown Device.
Im sure my connection is right because its the same as digispark
-
Which core-files and core-configuration you are using?
Using the arduino as ISP, forces some avrdude to use STK500 compatible protocol informations.
However, if you search for those error-messages, most people write, that they are false positives in case using an arduino as an isp.
You can suppress that message, defining the two values in your avrdude.conf for your selected board.
# # STK500 parameters (parallel programming IO lines)
# pagel = <num> ; # pin name in hex, i.e., 0xD7
# bs2 = <num> ; # pin name in hex, i.e., 0xA0
I guess, that you are having another problem, I have already described here: http://digistump.com/wiki/digispark/tutorials/programming#creating_digispark_compatible_clones (http://digistump.com/wiki/digispark/tutorials/programming#creating_digispark_compatible_clones)
Using AVRDude to flash a chip, there are two runs: In the first run avrdude sets the fuses, in the second avrdude stores the binary image to flash-memory.
If you have fuses defined in your board-definition, which will kill ISP-functions, you will brick your attiny.
So make sure, that you have ISP-compatible fuses in that board definition, you are using to burn the boot-loader. First AFTER you have verified the boot-loader, you can change your fuse settings!
regards
gogol
-
That's not how avrdude works. It connects to the chip and sets the fuses and uploads the program in one go, and the fuses don't take effect until after avrdude is totally finished and releases the chip. If the arduino app however is running avrdude two separate times and setting the fuses first, we're kinda stuffed. :/
I think the fuses set by the Burn Bootloader function are identical to those of the retail digispark - i.e. no ISP function. Should this change?
-
thats how the arduino IDE works and uses avrdude!
-
Just for demonstration:
I take an fresh attiny85 in my digispark-littlewire programmer and select: Digispark (Tiny Core) as Board and USBtinyISP as programmer.
When I now select bootloader installation, the IDE fires two avrdude-commands:
The first one bricks the attiny, because it sets FUSES, which will not allow for the second run!
X:\Digispark-Arduino-1.0.4\hardware/tools/avr/bin/avrdude -CX:\Digispark-Arduino-1.0.4\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -pattiny85 -cusbtiny -e -Uefuse:w:0xfe:m -Uhfuse:w:0x5f:m -Ulfuse:w:0xf1:m
Running AVRDUDE...
[...]
avrdude_original: Version 5.11, compiled on Sep 2 2011 at 19:38:36
[...]
avrdude_original: 1 bytes of efuse written
[...]
avrdude_original: 1 bytes of efuse verified
[...]
avrdude_original: 1 bytes of hfuse written
[...]
avrdude_original: 1 bytes of hfuse verified
[...]
avrdude_original: 1 bytes of lfuse written
[...]
avrdude_original: 1 bytes of lfuse verified
[...]
avrdude_original done. Thank you.
-----------------------------------
X:\Digispark-Arduino-1.0.4\hardware/tools/avr/bin/avrdude -CX:\Digispark-Arduino-1.0.4\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -pattiny85 -cusbtiny -Uflash:w:X:\Digispark-Arduino-1.0.4\hardware\digispark\bootloaders\micronucleus\micronucleus-1.06-upgrade.hex:i
Running AVRDUDE...
[...]
avrdude_original: programmer operation not supported
avrdude_original: Using SCK period of 10 usec
CMD: [ac 53 00 00] [00 00 00 00]
CMD: [ac 53 00 00] [00 00 00 00]
avrdude_original: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
-------------------------------------
When you however will follow my recipe, and select an board, which has ISP-compatible FUSES, you are able to flash the bootloader
X:\Digispark-Arduino-1.0.4\hardware/tools/avr/bin/avrdude -CX:\Digispark-Arduino-1.0.4\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -pattiny85 -cusbtiny -e -Uefuse:w:0xfe:m -Uhfuse:w:0xdf:m -Ulfuse:w:0xf1:m
Running AVRDUDE...
[...]
avrdude_original: 1 bytes of efuse written
[...]
avrdude_original: 1 bytes of efuse verified
[...]
avrdude_original: 1 bytes of hfuse written
[...]
avrdude_original: 1 bytes of hfuse verified
[...]
avrdude_original: 1 bytes of lfuse written
[...]
avrdude_original: 1 bytes of lfuse verified
[...]
avrdude_original done. Thank you.
X:\Digispark-Arduino-1.0.4\hardware/tools/avr/bin/avrdude -CX:\Digispark-Arduino-1.0.4\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -pattiny85 -cusbtiny -Uflash:w:X:\Digispark-Arduino-1.0.4\hardware\digispark\bootloaders\micronucleus\micronucleus-1.06-upgrade.hex:i
Running AVRDUDE...
[...]
Programmer Type : USBtiny
Description : USBtiny simple USB programmer, http://www.ladyada.net/make/usbtinyisp/
[...]
avrdude_original: Device signature = 0x1e930b
avrdude_original: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
CMD: [a0 01 fc 00] [00 a0 01 ff]
CMD: [a0 01 fd 00] [00 a0 01 ff]
CMD: [a0 01 fe 00] [00 a0 01 ff]
CMD: [a0 01 ff 00] [00 a0 01 ff]
avrdude_original: erasing chip
CMD: [ac 80 00 00] [00 ac 80 00]
avrdude_original: Using SCK period of 10 usec
CMD: [ac 53 00 00] [00 ac 53 00]
[...]
#CMD: [4c 05 e0 00] [17 4c 05 e0]
# | 100% 8.02s
avrdude_original: 3018 bytes of flash written
avrdude_original: verifying flash memory against X:\Digispark-Arduino-1.0.4\hardware\digispark\bootloaders\micronucleus\micronucleus-1.06-upgrade.hex:
avrdude_original: load data flash data from input file X:\Digispark-Arduino-1.0.4\hardware\digispark\bootloaders\micronucleus\micronucleus-1.06-upgrade.hex:
avrdude_original: input file X:\Digispark-Arduino-1.0.4\hardware\digispark\bootloaders\micronucleus\micronucleus-1.06-upgrade.hex contains 3018 bytes
avrdude_original: reading on-chip flash data:
Reading | ################################################## | 100% 5.06s
avrdude_original: verifying ...
avrdude_original: 3018 bytes of flash verified
avrdude_original done. Thank you.
That was the reason, why I started to build my fuse-resetter.
-
This definitely needs to be fixed! I cannot fathom why arduino would be doing it that way. Then again, the arduino project does a lot of things in very confusingly overcomplicated ways.
-
Totally agree! As IDE users will brick their attinies almost at 100% . An they don't understand why, because verbose output is switched off by default in the IDE.
Something I also don't like.
I would expect, to find much cleaner and better Arduino code, when people would see warnings!
I need to look to the 1.5 branch of the IDE, what they have fixed over there.
.g
-
Ugh. I wish I had searched here earlier. I recently got a USB µISP and was trying to program a raw ATTiny85 last night. I blithely used the "Burn Bootloader" option at some point. So I guess I may have bricked that one.
Question: I'm unclear if I'm supposed to do the ISP-to-chip connections MOSI <-> MOSI and MISO <-> MISO or if I'm supposed to swap those lines. I had the impression that it's the former, though, yes?
Can anybody point me to so some clear, step-by-step instructions for programming raw chips via ISP from my Mac? Most of the tutorials I find seem to assume some prior knowledge and skip some steps, or are for setting up Arduino-as-ISP.
-
In the past I have used an old AVRISP mkII (http://avrprojectsfiuady.blogspot.fr/2011/07/programming-avr-with-avrisp-mkii.html), and yes the MOSI/MISO pins should be connected matching their counterpart. MOSI to MOSI, MISO to MISO.
I don't know if it's the same with your µISP, but one caveat is that you must supply power to the chip you are programming, the programmer doesn't.
-
With MOSI and MISO its different than with TX/RX. But the names are self explaining: Master Out Slave In and Master In Slave Out.
So "MO" from the Master connects to "SI" on the Slave, and "MI" from the master is connected to "SO" from the Slave.
-
Obviously, I hadn't had enough coffee when I wrote my previous post. ;)
Oh, and just in case anyone is curious, the µISP can supply power to the chip. In fact, you can select between 3.3V, 5V, or separate power.