BusPirate as an AVR programmer?

[WaveyDipole]

Some time ago I was considering the purchase of a BusPirate so as to be able to investigate devices with an SPI bus. The purchase got shelved due to other priorities, but more recently I have a requirement for an AVR programmer for my Arduino. The seem to be a number of programmers out there including some very cheap ones from the far east. I am uncertain as to which one to buy as well as the merits of the cheap ones vs the more expensive ones.

In addition, I have discovered that the BusPirate can be used as an AVR programmer. It is supported by AVRDUDE (with correct firmware and program versions) as well as by the Arduino IDE.

It ocurred to me that if I'm going to spend $30, 30GPB or more on an AVR programmer, then perhaps I could get the BusPirate and have one device that can serve both purposes. I was wondering whether anyone has experience of using the BusPirate as an AVR programmer? Whether they work well, or whether it is still best to get a seperate AVR programmer? If so, then what programmer is recommended/best avoided and why?

[ajb]

It works ok if you're okay with using AVRDUDE and only programming AVRs (also, it's worth checking the device support, does it support the whole current AVR range?).  An Atmel ICE is more expensive, but supports all of Atmel's current programming and debugging interfaces for both AVR and SAM parts (well, except for the high voltage modes, but those have only very niche appeal).  And it integrates very nicely with Atmel Studio. 

So it depends a lot on what sort of workflow and parts your interested in.  If you just want to program AVRs on the cheap you can get AVRISP clones for <$10 shipped all over the usual places.

[janoc]

Buspirate works as an AVR programmer but that is really something I would do only in a pinch. It is not particularly fast and I don't think it can program a lot of devices. It wasn't really designed to be a programmer. Buspirate is mostly meant to deal with serial devices, such as chips using I2C or SPI and that's what it is best at.

If you are pinching pennies so badly then get a $1-$2 USBASP clone and be done with it. Also if you accidentally fry it (not too hard to do if you forget about what is powering what or what voltages are you using), it will hurt you less than destroying the BP by accident.

[westfw]

if I'm going to spend $30, 30GPB or more on an AVR programmer

Why would you do that, when you can get a USPASP clone for about $3, or an Arduino Clone that you can run programmer SW on (that you can FIX!) for a similar price?  Or this, if you don't want to buy from China: https://www.pololu.com/blog/758/new-product-pololu-usb-avr-programmer-v2.1
(Note that the cheap programmers don't support debugging, and may not support the newer programming protocols like TPI (super-tinys), SWD (ARM), PDI (Xmega), or UPDI ("Xtiny", Mega-zero.)  Or the older protocols like HV parallel or HV Serial programming.)

Buspirate works as an AVR programmer but that is really something I would do only in a pinch.   Buspirate is mostly meant to deal with serial devices, such as chips using I2C or SPI ...

Many popular AVRs are programmable with exactly SPI...

[janoc]

Buspirate works as an AVR programmer but that is really something I would do only in a pinch.   Buspirate is mostly meant to deal with serial devices, such as chips using I2C or SPI ...

Many popular AVRs are programmable with exactly SPI...

The point is not whether BP can program them (it can, as I wrote in my reply) but that it is far from an optimal solution if the goal is to have a programmer. By I2C or SPI devices I meant stuff like EEPROMs, various I2C/SPI sensors and similar hardware, not programming AVRs.

[madires]

The BusPirate works fine as ISP programmer but it's quite slow. I'm using a Diamex ALL-AVR which also supports PDI and TPI.

[WaveyDipole]

Why would you do that, when you can get a USPASP clone for about $3, or an Arduino Clone that you can run programmer
SW on (that you can FIX!) for a similar price?

Well, the $30 came from a suggestion I received to buy another AVR programmer (Diamex) which happened to be around that price.

I have one of these cheap 2-3GBP gizmos that I purchased maybe a year and a half ago to program the ATMega16. I have a spare chip and got the programmer and zif socket board board with a view to doing something with it but the project ended up shelved and the programmer was never used. It might still come useful for something one day...

In the meantime I discovered when I fetched it out that it has a 10-pin socket at each end of the ribbon cable whereas, naturally, the Uno has a 6 -pin header.... It seems that there is no way to be sure whether this will work with the Uno (or Nano for that matter) anyway so I started thinking about buying another programmer. As part of my research I had a look at what was supported by the Arduino IDE and AVRDUDE. Well it turned out that BusPirate was supported by both and since I was already considering it for other purposes it seemed I could solve both requirements with one purchase.

The point is not whether BP can program them (it can, as I wrote in my reply) but that it is far from an optimal solution if the goal is to have a programmer.

That was exactly the reason why I asked the question - to make that determination, so thanks for the comment. The BusPirate was engineered for a different purpose and although in both cases, the connection is via the SPI bus, I wasn't sure how well it might perform as an AVR programmer or whether there were any caveats.

(Note that the cheap programmers don't support debugging, and may not support the newer programming protocols like TPI (super-tinys), SWD (ARM), PDI (Xmega), or UPDI ("Xtiny", Mega-zero.)  Or the older protocols like HV parallel or HV Serial programming.)

I hadn't really considered working with other hardware. For the present all I need is to work with the Uno and Nano. I did notice that the link to the AtMega328P datasheet takes you to the microchip.com website, and they seem to make the tiny range as well as PIC and other microcontrollers. Did they buy put AtMega? It does seem a good idea to consider support for other and newer protocols which might be used by other controllers. I had. perhaps erroneously, thought that protocol support is within the programming application and that the hardware was just an interface.

Anyway, it seems that the BusPirate may not be the best way forward, so I'm now open to the consideration of which programmer to buy. So far, the Diamex has been suggested and the Atmel ICE has also been mentioned. It does seem that I might be better off going for something a little better than the cheap 2-3GPB ones so I am open to further suggestions.

[tsman]

In the meantime I discovered when I fetched it out that it has a 10-pin socket at each end of the ribbon cable whereas, naturally, the Uno has a 6 -pin header....

The 10 pin connector has more ground pins and a pin for a LED. The 6 pin one omits most of the ground pins and that LED so it is more compact. The actual programming pins are the same. You can buy/make an adapter or just use jumper wires.

http://i39.tinypic.com/4vl1c4.jpg

Did they buy put AtMega?

Yes. Microchip bought Atmel in 2016.

Anyway, it seems that the BusPirate may not be the best way forward, so I'm now open to the consideration of which programmer to buy. So far, the Diamex has been suggested and the Atmel ICE has also been mentioned. It does seem that I might be better off going for something a little better than the cheap 2-3GPB ones so I am open to further suggestions.

If you just want something cheap then getting one of the cheapo USBASP clone AVR ISP programmers will be sufficient to get you started. They're actually a ATmega themselves so you can reuse them for other tasks with the V-USB library.

Can't argue with the price of those programmers but you don't have any debugging ability. If you're not careful then it is possible to configure the fuses in an ATmega that prevents you from reprogramming it using ISP. You'll need a high voltage AVR programmer to reset the fuses.

You can actually configure your Arduino to act as a AVR ISP programmer.

If you're serious about AVR development then look into getting one of the more expensive programmers/debuggers.

[WaveyDipole]

Thanks. I have now ordered a USBASP to get me started:

https://www.ebay.co.uk/itm/USBASP-USBISP-ISP-Programmer-Cable-Adapter-KK2-0-KK2-1-Atmel-AVR-ATMega-ARDUINO/131241223483

According to the seller it has the latest firmware with TPI support and supports a range of ATMega devices. It seems it is supported by AVRDUDE and the Arduino IDE. One thing I forgot about was whether it supports both 3.3v and 5v devices. The seller does not say although it does seem to have some jumpers on board. So long as it gets me started with the Uno and Nano, that will be fine for now.

[janoc]

Be careful with the 3.3V support on the Chinese usbasp clones. There are all sorts of versions floating around, many don't support 3.3V operation and the jumper only disconnects the Vcc pin on the connector from the on-board voltage regulator so that you don't try to back-power USB port from your device in case it has its own power supply.

The ones supporting 3.3V operation will have an on-board voltage regulator and usually a switch or set of jumpers to change the voltage between 5 and 3.3V.

Better verify with a meter before use.

[WaveyDipole]

janoc, thanks for that. The board has a Q1 which may or may not be a regulator next to the two jumpers marked J1 and J2 but with no indication of their function. I will check it out with the DMM when I get it.

The old programmer (purchased a couple of years ago to program the ATMega16A) has a switch with the 3.3v and 5v positions and an AtMega8A Processor on board. There are no jumpers, but this one definitely has a 3.3V regulator on board. I just noticed that one corner of this board is actually marked EvUSBasp so perhaps this is also a USBasp programmer? Not sure what the Ev prefix means?

I just wondered whether it could be flashed with the latest firmware from https://www.fischl.de/usbasp/ and still work with the ATMega16 as well as the Uno and Nano? In which case all I would need is a 10-pin to 6-pin adapter which can be had cheaply enough. However, I had a look at the readme, and since there are no jumpers, I have no means to "Set jumper J2 to activate USBasp firmware update function."....

[janoc]

The old programmer (purchased a couple of years ago to program the ATMega16A) has a switch with the 3.3v and 5v positions and an AtMega8A Processor on board. There are no jumpers, but this one definitely has a 3.3V regulator on board. I just noticed that one corner of this board is actually marked EvUSBasp so perhaps this is also a USBasp programmer? Not sure what the Ev prefix means?

Most likely it is - all these use the original usbasp firmware and design, which is bitbanged USB on some sort of ATMega8/168/... You will almost always find two zener diodes there to clamp the USB voltages to 3.3V levels and some have the 3.3V regulator too.

I actually have that same programmer, it reports itself as usbasp:

Code: [Select]

[119518.141514] usb 1-5.4.2: new low-speed USB device number 13 using xhci_hcd
[119518.235744] usb 1-5.4.2: New USB device found, idVendor=16c0, idProduct=05dc
[119518.235747] usb 1-5.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[119518.235748] usb 1-5.4.2: Product: USBasp
[119518.235749] usb 1-5.4.2: Manufacturer: [url=http://www.fischl.de]www.fischl.de[/url]


I just wondered whether it could be flashed with the latest firmware from https://www.fischl.de/usbasp/ and still work with the ATMega16 as well as the Uno and Nano? In which case all I would need is a 10-pin to 6-pin adapter which can be had cheaply enough. However, I had a look at the readme, and since there are no jumpers, I have no means to "Set jumper J2 to activate USBasp firmware update function."....

I don't think you can use the integrated USB update function, you would likely need another programmer to reflash it. If they maintained the pinout it should work, but there could be some minor differences. But you shouldn't need to reflash that, the firmware it comes with is likely a bit older but should still work.

The usbasp firmware works with all ATMegas that use this SPI-based ISP protocol, so it will certainly work with ATMega16 and your Arduinos (which use ATMega328). It won't work with the newer XMega chips, none of the ARM-based Arduinos and may not work with the Arduino Mega which uses ATMega 2560 - I remember some of these cheap programmers were unable to program chips with more than 32kB of flash.

And if you need an adapter from 10 pin to 6 pin connector, just get one of these (there are tons of these on eBay, AliExpress and elsewhere):
https://www.aliexpress.com/item/10Pin-To-6PiN-Convert-To-Standard-10-Pin-To-6-Pin-Adapter-Board-For-ATMEL-STK500/32838046397.html

Or make your own, e.g. from a piece of ribbon cable and two IDC connectors.

[WaveyDipole]

Janoc, thanks again for your reply and helpful comments.

Just got back from work and have investigated a little further.

I got this from lsusb which initially didn't look very promising:

Code: [Select]

Bus 002 Device 007: ID 16c0:05dc Van Ooijen Technische Informatica shared ID for use with libusb
But then I then had a look at the dmesg output:

Code: [Select]

[  258.365595] usb 2-1.6: new low-speed USB device number 7 using ehci-pci
[  258.483526] usb 2-1.6: New USB device found, idVendor=16c0, idProduct=05dc
[  258.483529] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  258.483532] usb 2-1.6: Product: USBasp
[  258.483534] usb 2-1.6: Manufacturer: [url=http://www.fischl.de]www.fischl.de[/url]
This looks very similar to your output so looks promising. Interestingly, I had a look on fischl.de and found that the last firmware is dated 2011? Is that definitely the latest firmware? If so, then it seems quite possible that this programmer could have that firmware, but that does seem a long time without an update?

I have an adapter such as the one you linked coming with the new programmer I ordered. When it arrives I will test it out with this older programmer as well. If it works then I will get another one. In the meantime, I have a handful of Dupont leads somewhere which I could probably use to hook this one up to an Arduino. I know I will need to be careful to get them in the correct order! The adapter would, of course, make this a lot easier.

I also understand that these programmers have no real protection and it is easy to blow them up so if this older one works it would give me a spare. I take your point about the limitations when it comes to ATMega2560 and XMega chips. If I move on to working with such microcontrollers (BTW, I didn't know they ARM versions), then I will look at suitable programmers at that time. Being able to program the Uno and Nano will suffice for now.

I found I had to set up a udev rule file before the Arduino could communicate with the programmer, but once that was done and the programmer to "USBasp" in the Arduino IDE, I'm now at the state where Upload Using Programmer in the IDE is no longer complaining about not finding a programmer but actually tries to do something. The next step is to connect a microcontroller and attempt to program it. However, before I do that, I still have some unanswered questions. I understand that uploading a sketch this way overwrites the bootloader. This is what I will ultimately want to do, but for now, how does one put a boot loader back? Is it as simple as Tools | Burn Bootloader? What about fuses? Where do I configure these? Am I correct in presuming that once Burn bootloader has been done then Sketch | Upload will work as usual? These are some points I need to research first when I'm feeling less tired!

[janoc]

Code: [Select]

[  258.365595] usb 2-1.6: new low-speed USB device number 7 using ehci-pci
[  258.483526] usb 2-1.6: New USB device found, idVendor=16c0, idProduct=05dc
[  258.483529] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  258.483532] usb 2-1.6: Product: USBasp
[  258.483534] usb 2-1.6: Manufacturer: [url=http://www.fischl.de]www.fischl.de[/url]

This looks very similar to your output so looks promising. Interestingly, I had a look on fischl.de and found that the last firmware is dated 2011? Is that definitely the latest firmware? If so, then it seems quite possible that this programmer could have that firmware, but that does seem a long time without an update?

Yes, that looks good. And yes, I don't think USBASP had a major update in years, it is a mature project. Also the programming protocol it uses is very old, AVRs that use this started to be sold from the early 90s. The more modern chips use different protocols, that's why e.g. the XMegas  and some ATTiny's don't work.

I have an adapter such as the one you linked coming with the new programmer I ordered. When it arrives I will test it out with this older programmer as well. If it works then I will get another one. In the meantime, I have a handful of Dupont leads somewhere which I could probably use to hook this one up to an Arduino. I know I will need to be careful to get them in the correct order! The adapter would, of course, make this a lot easier.

Well, normally it is fairly safe, in the worst case it just won't work. Only take care to not connect the Vcc line to a wrong place, that's about the only thing that could damage something.

I also understand that these programmers have no real protection and it is easy to blow them up so if this older one works it would give me a spare. I take your point about the limitations when it comes to ATMega2560 and XMega chips. If I move on to working with such microcontrollers (BTW, I didn't know they ARM versions), then I will look at suitable programmers at that time. Being able to program the Uno and Nano will suffice for now.

The USBASP website (https://www.fischl.de/usbasp/) shows the schematic too, that's pretty typical with the clones too. Only some add an extra 3.3V regulator for the Vcc to permit their use with 3.3V targets. But there are no buffers or overcurrent/overvoltage protection, nor ESD protection, only a bare ATmega MCU. I didn't manage to fry one yet but it is certainly not "idiot-proof".

And just to be clear - I meant that there are Arduinos that use ARM MCUs from Atmel/Microchip, such as Arduino Due (uses AT91SAM3X8E instead of ATMega) or the Genuino Zero (ATSAMD21G18), not that ATMega2560 or XMega chips are ARMs (they aren't).

I found I had to set up a udev rule file before the Arduino could communicate with the programmer, but once that was done and the programmer to "USBasp" in the Arduino IDE, I'm now at the state where Upload Using Programmer in the IDE is no longer complaining about not finding a programmer but actually tries to do something. The next step is to connect a microcontroller and attempt to program it. However, before I do that, I still have some unanswered questions. I understand that uploading a sketch this way overwrites the bootloader. This is what I will ultimately want to do, but for now, how does one put a boot loader back? Is it as simple as Tools | Burn Bootloader? What about fuses? Where do I configure these? Am I correct in presuming that once Burn bootloader has been done then Sketch | Upload will work as usual? These are some points I need to research first when I'm feeling less tired!

Normally uploading using a programmer shouldn't overwrite the bootloader - if the bootloader was correctly programmed, it is protected by the fuse bits. Those would need to be cleared first in order to let you reprogram that part of the flash. When you do "Burn Bootloader" from the IDE, it will set the fuses correctly for you. The configuration is in the boards.txt file.

Alternatively, you can always flash the bootloader by hand, for example Sparkfun has this tutorial:
https://learn.sparkfun.com/tutorials/installing-an-arduino-bootloader/all

Just make sure to modify any commands to match your programmer type and when messing with the fuses make sure to verify everything twice otherwise you could "brick" the target MCU - for example disable ISP programming, enable DebugWire (which disables the /RESET line and thus programming) or enable external clock source when you don't have external oscillator present. All of these would lock you out and will require a parallel, high voltage programmer to reset.

[WaveyDipole]

Normally uploading using a programmer shouldn't overwrite the bootloader - if the bootloader was correctly programmed, it is protected by the fuse bits. Those would need to be cleared first in order to let you reprogram that part of the flash. When you do "Burn Bootloader" from the IDE, it will set the fuses correctly for you. The configuration is in the boards.txt file.

Ok, that's good to know. At some point I will need to experiment with removing the bootloader and disabling the BOOTRST fuse, but for now, I just want to get the process of programming sorted.

Just make sure to modify any commands to match your programmer type and when messing with the fuses make sure to verify everything twice otherwise you could "brick" the target MCU - for example disable ISP programming, enable DebugWire (which disables the /RESET line and thus programming) or enable external clock source when you don't have external oscillator present. All of these would lock you out and will require a parallel, high voltage programmer to reset.

Yup, I have read about the possibility of bricking an Arduino which did make me a bit nervous so I am proceeding cautiously but making progress. I first tried the ATMega16 board with this command just to get the device SPI signature:

Code: [Select]

$ avrdude -c usbasp-clone -p m16 -P usb:xx -v
avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9403 (probably m16)
avrdude: safemode: hfuse reads as 59

avrdude: safemode: hfuse reads as 59
avrdude: safemode: Fuses OK (E:FF, H:59, L:CF)

avrdude done.  Thank you.

So far so good. I then hooked up the Uno and tried something similar:

Code: [Select]

$ avrdude -c usbasp-clone -p m328p -P usb:xx -v
...
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.
Not so good. Checked that I had the wiring correct and tried again. Still the same. I then realised my silly mistake. I had been working on a project involving two Uno's which were still connected via a breadboard, including pins 10 thru 13. I had forgotten to remove the wires from the breadboard! That sorted I now get:

Code: [Select]

$ avrdude -c usbasp-clone -p m328p -P usb:xx -v
...
avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: safemode: hfuse reads as DE
avrdude: safemode: efuse reads as FD

avrdude: safemode: hfuse reads as DE
avrdude: safemode: efuse reads as FD
avrdude: safemode: Fuses OK (E:FD, H:DE, L:FF)

avrdude done.  Thank you.
Ok, so now it works and I have a connection and can read the device signature. I am still concerned about the first two lines in this output:

Code: [Select]

avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Since they appear for both interfaces, this clearly isn't controller specific, so must relate to the programmer. Its a warning rather than an error and the third line does report that the device is initialised and ready to accept instructions, so presumably programming should now work. Is this warning anything to be concerned about?

If not, then the next step will be to upload a sketch as see what happens.

Perhaps of greater concern is the fact that I couldn't get AVRDUDE/AVRDUDESS on Windows (Win7, not tried Win10 yet) to recognize the programmer. I got an error telling me that it could find a device with Manuacturer ID 16c0 and device ID 05dc. I installed the driver using Zadig and the board is correctly identified with those IDs in Device Manager. As per the outputs above, I seem to have no such problem on Linux.

[tsman]

I am still concerned about the first two lines in this output:

Code: [Select]

avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Since they appear for both interfaces, this clearly isn't controller specific, so must relate to the programmer. Its a warning rather than an error and the third line does report that the device is initialised and ready to accept instructions, so presumably programming should now work. Is this warning anything to be concerned about?

If not, then the next step will be to upload a sketch as see what happens.

The warning is harmless and can be ignored. The Chinese USBasp clones have a modified firmware that automatically sets the slow clock if needed instead of having a specific command for it. If you reflash it with the stock USBasp firmware then you don't get that error but you lose the auto clock feature and you need to use the avrdude -B option for slow AVRs.

[WaveyDipole]

The warning is harmless and can be ignored. The Chinese USBasp clones have a modified firmware that automatically sets the slow clock if needed instead of having a specific command for it. If you reflash it with the stock USBasp firmware then you don't get that error but you lose the auto clock feature and you need to use the avrdude -B option for slow AVRs.

Ok, thank you for that explanation. That being the case, I guess I will now proceed to having a go with actually programming something on to the controller.

Alternatively, you can always flash the bootloader by hand, for example Sparkfun has this tutorial:
https://learn.sparkfun.com/tutorials/installing-an-arduino-bootloader/all

I have now located the boards.txt file (in arduino/hardware/arduino/avr/boards.txt) and I can see a 328p definition template in that file. I would prefer not to mess with these default definitions so I will review the manual process as provided in your link. Thanks.

[WaveyDipole]

BTW, I think I have solved the Windows problem I mentioned, where AVRDUDE/AVRDUDESS will not recognize the programmer. I had to do a couple of things:

1. The AVRDUDE mingw32 package comes supplied with avrdude.exe and avrdude.conf which is convenient as it does not need to be compiled. Frustratingly, it does not appear to come with supporting DLL files, which becomes apparent when you try to run it. It seemed simpler to install WinAVR instead which contains everything required. AVRDUDESS was downloaded seperately, and although it is possible to select a USBasp clone in its GUI, the 2010 version of AVRDUDE that came with WinAVR did not have support for the USBasp programmer. What I then did was to copy avrdude.exe and avrdude.conf from the avrdude-6.3-mingw32.zip package downloaded from the avrdude project page, into the C:\WinAVR-20100110\bin directory. I now had a version of AVRDUDE that would accept "usbasp-clone" as a valid parameter for the -c option.
 
2. I thought I had installed the correct driver using Zadig, but for whatever reason, when I selected the USBasp device, it was still showing me the WinUSB driver. I replaced it again with the libusb0 driver. The USBasp programmer now appears in device manager under "libusb-win32 devices" instead of "Universal Serial Bus controllers" and I am getting a response from the device.

I thought I would post this information as it may be helpful to someone else if they run into this problem.

[janoc]

Good, glad to see you have got it to work.

BTW, for USB connected programmers you shouldn't need to use -P flag with avrdude - it should be able to detect the device automatically. The port parameter is only needed for devices that show as serial ports and such.

You should be also able to use the protocol "usbasp" instead of "usbasp-clone" - I have yet to see a clone which would require the latter.

[WaveyDipole]

Good, glad to see you have got it to work.

BTW, for USB connected programmers you shouldn't need to use -P flag with avrdude - it should be able to detect the device automatically. The port parameter is only needed for devices that show as serial ports and such.

You should be also able to use the protocol "usbasp" instead of "usbasp-clone" - I have yet to see a clone which would require the latter.

Yes, it is slowly coming together. Thank you.

I have also noted your points. I also did an "Upload using programmer" test with the Arduino IDE which seemed to work OK although I have noticed a couple of interesting things. I am working on Linux.

Firstly I intermittently get the following:

Code: [Select]

Wrong microcontroller found.  Did you select the right board from the Tools > Board menu?

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

Initially I got worried that I had corrupted the microcontroller board in some way, but after a couple more attempts it worked again.

Secondly, I have found that uploading the program in this way erases the EEPROM memory. My sketch makes use of this area and the previously saved data was wiped. No big deal, but since EEPROM is a dedicated memory space I didn't expect that.

It also seems that after uploading using the programmer, uploading using the default USB serial method no longer works. I get:

Code: [Select]

Arduino: 1.8.7 (Linux), Board: "Arduino/Genuino Uno"

Sketch uses 12656 bytes (39%) of program storage space. Maximum is 32256 bytes.
Global variables use 856 bytes (41%) of dynamic memory, leaving 1192 bytes for local variables. Maximum is 2048 bytes.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
....
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
Since I'm using USB serial rather than the programmer, it should not make any difference, but "USBasp" is selected as the programmer and I am selecting Sketch | Upload rather than Sketch | Upload Using Programmer.

I did then discover that it was necessary to burn the bootloader first and after that a sketch could be uploaded in the usual manner via USB serial again. I was given to understand earlier that the bootloader is not overwritten by AVR programming, but evidently something seems to be happening to it? Since I have a workaround, I can work with that, but I would like to understand the mechanics of what is happening.

In any case it would seem that I can upload code to the microcontroller using this programmer.

[janoc]

Firstly I intermittently get the following:

Code: [Select]

Wrong microcontroller found.  Did you select the right board from the Tools > Board menu?

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

Initially I got worried that I had corrupted the microcontroller board in some way, but after a couple more attempts it worked again.

Turn the verbose output on and you will likely see that it mis-read the signature of the MCU. That may happen if you have something else connected to the microcontroller and it interferes with the SPI lines. And sometimes it happens anyway, for whatever reason. Could be a glitch of the programmer too. I

Secondly, I have found that uploading the program in this way erases the EEPROM memory. My sketch makes use of this area and the previously saved data was wiped. No big deal, but since EEPROM is a dedicated memory space I didn't expect that.

ATMega328 will erase the EEPROM when the flash is erased by default. If  you don't want that, you need to set the EESAVE bit in the high fuse byte. Then it will be preserved.

(see: http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega328p )

It also seems that after uploading using the programmer, uploading using the default USB serial method no longer works. I get:

Code: [Select]

Arduino: 1.8.7 (Linux), Board: "Arduino/Genuino Uno"

Sketch uses 12656 bytes (39%) of program storage space. Maximum is 32256 bytes.
Global variables use 856 bytes (41%) of dynamic memory, leaving 1192 bytes for local variables. Maximum is 2048 bytes.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
....
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
Since I'm using USB serial rather than the programmer, it should not make any difference, but "USBasp" is selected as the programmer and I am selecting Sketch | Upload rather than Sketch | Upload Using Programmer.

I did then discover that it was necessary to burn the bootloader first and after that a sketch could be uploaded in the usual manner via USB serial again. I was given to understand earlier that the bootloader is not overwritten by AVR programming, but evidently something seems to be happening to it? Since I have a workaround, I can work with that, but I would like to understand the mechanics of what is happening.

In any case it would seem that I can upload code to the microcontroller using this programmer.

That's weird but it is possible that your Arduino didn't have the bootloader protected so it got wiped when you have used the programmer. Normally some of the lock bits need to be programmed to protect the bootloader from being overwritten, see the the page 242 or the datasheet:

http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7810-Automotive-Microcontrollers-ATmega328P_Datasheet.pdf

[WaveyDipole]

janoc, thanks. Something for me to research further.

I had to switch to Windows in order to proceed with some tests I had in mind using Windows programs with the Arduino project that I am working on. Working with USBasp on Windows was problematic.

Aruduino IDE version 1.8.7 does NOT work with avrdude. I found that Arudino IDE has its own version of avrdude but this version will not find the programmer. I am running the downloaded standalone version that is supplied in a ZIP file. I thought maybe that I needed the installer. However, I tried the standalone version that I previously used (1.6.11) and this worked perfectly fine and pretty much the same as on Linux. I did come across a comment on a forum about avrdude not working with 1.8.7, but no solution. I notice that version 1.8.8 of the Arduino IDE has been released so I might give that a try.

The standalone avrdude works fine and I was able to use this to change the BOOTRST fuse as I had originally intended. As it happened it did not solve the problem I was facing. I still needed a capacitor across RESET and GND, but that's another issue.

The main thing is that I have learned something about AVR programming and can continue to build on this knowledge. I appreciate all the feedback.

[janoc]

Quick search shows that avrdude as shipped with Arduino 1.8.7 seems to have some issues. Try updating to 1.8.8. I think the Arduino folks have some kind of patched version for whatever reason and it is possible that they have messed something up.

For me usbasp worked in Windows too but keep in mind that this programmer is a hack - the bitbanged USB is marginal at best, so problems are to be expected. The same device may work fine on one PC and not on another, may work on one USB port and not another, may work when connected directly but not through a hub and so on. Sometimes simply the component tolerances, such as of the zener diodes used, will cause it to not work properly.

The bitbanged V-USB stack this is using (ATMegas used on these don't have a proper hardware USB interface) is a cute hack but you do get what you pay for there. I have used this technique for a few gadgets myself but gave up on it very quickly because it was a reliability nightmare.

[WaveyDipole]

It turned out that this was a driver issue.  Using Zadig and replacing the libusb-win32 driver that I had installed when following the online tutorial with the libusbK driver solved the problem. It seems something changed with the later Arduino versions of advdude:

https://github.com/arduino/avrdude-build-script/issues/1

With the libusbk driver, all versions work just fine.

My new programmer arrived today. This also works fine and seems a little faster!

[janoc]

Great, good to hear!