Hi Zak,I use USBASP and I need to use PDI interface to write the ATXMEGA flash memory,Here is the project and the patches:which can be used.But I didn’t have success to add this to your wonderful tool AVRDUDESS. I’m sure that you have a lot of experience in this kind of things. So, do you think that can you find some time to add this patch to your AVRDUDESS in order to works also on PDI for ATXMEGA and USBASP?Or if you find any solution here, it will be very helpful for me!Many many thanks!.
![]() Avr Serial Bootloader Avrdude Download
Hi Zak,I’ve just installed AVRDUDESS on a Win 10 x64 machine. I get the following errors:ERROR: avrdude is missing!ERROR: avrdude.conf is missing!WARNING: Programmer ‘usbasp’ not foundWARNING: MCU ‘t85’ not foundavrdude and avrdude.conf are in the AVRDUDESS folder. Usbasp programmer was in the usb port and driver correctly installed.I suspect that the issue is that AVRDUDESS is installed in C:Program Files (x86)AVRDUDESS rather than C:Program FilesAVRDUDESS? Is there any way to address this?Thanks in advance,Adam. Are the Arduino Pro Micro clones supported? Uses the ATmega32u4 chip.
That chip is not showing up on the MCU list and using the detect button results in this:avrdude.exe: stk500recv: programmer is not respondingavrdude.exe: stk500getsync attempt 10 of 10: not in sync: resp=0xa5avrdude.exe: serdrain: read error: The device does not recognize the command.I have Arduino selected as the programmer and I’ve selected com 5 (from windows 10 device manager). I have uninstalled and reinstalled your program multiple times hoping that would solve the issue. I have tried it on 2 of the pro micros with the same results. They are supposed to have the Leonardo bootloader installed on them. I have selected:Programmer – “Atmel-ICE (ARM/AVR) in JTAG mode”Port – USBMCU – ATmega32So, command line was right: “-c atmelice -p m32 -P usb”Then have pressed “Detect” button.In the message window:avrdude.exe: jtag3initialize: part ATmega8 has no JTAG interfaceSame command line passed to avrdude directly works fine:avrdude -c atmelice -p m32 -P usbavrdude: AVR device initialized and ready to accept instructionsReading ################################################## 100% 0.11savrdude: Device signature = 0x1e9502 (probably m32)avrdude: safemode: Fuses OK (E:FF, H:08, L:3F)avrdude done.
Hi Dmitry,Avrdude needs an MCU specified before it will attempt to do anything, but the MCU is not known if it’s doing an auto-detect so I hardcoded in the ATmega8. However, there are multiple types of programming interfaces (debugWire, HVSP, ISP, JTAG, PDI, PP, TPI), so the interface avrdude uses depends on the programmer and MCU combination. Some programmers will automatically use the correct interface based on the MCU (like the USBASP will switch between ISP and TPI), while other programmers need to have it manually set (like the Atmel ICE).In your case it’s trying to use the JTAG programmer with an ATmega8 which doesn’t have JTAG, so it fails.I’ll have a go at making AVRDUDESS have a guess at choosing an MCU with the correct interface when auto-detecting for the next version. Yes, it no longer loads the last used preset. It loads each individual setting instead. If you load a preset, then close and open again it will still have all of the same settings, but they are no longer associated with a particular preset.However, you are right that it should not display “Default” when opening the program, a blank entry would be better.Presets were designed to be a one-way set of configuration options.
I guess I should perhaps implement a “Profile” system, where you load a profile and any changes are automatically saved to that profile, and the last used profile is then loaded when the program opens. I used avrdudess 2.6 for some time and got the update message today.So i downloaded the 2.7 installer exe and tried to run it.After starting, it from an explorer widow, it locks it for several minutes (ok, i am using a cheap laptop which is not very fast).After that, i only get a borderless, not resizeable, window which contains weird (asian style) characters, a scrollbar and a close X icon on the top right.So whats wrong with it (or my laptop)?As a solution i downloaded the zip and just copied its files over the 2.6 installation 😀A yeah I use Windows 10 pro x64 insider preview. I downloaded it 3 or 4 times. Everytime it fails.So now i got it.I enabled in Windows Setup the.net s.5 features (sorry, do not remember them) as the.net 3.5 installer also refuses to work.Then i tried to install avrdudess once more.Now, the cryptic popup turned out to be awindows defender message, telling me that i does not alow the installaton of an untrusted app and s on 😉Clicking on ore information in the popup enabled the ‘install anyway’ button and the installer starts.Very strange. Thank you for response,i will buy an Arduino,for now i try to use avrdudess(avrdude )with Pony Prog STK200 i have, and i give this error avrdude.exe: can’t open device “giveio”avrdude.exe: failed to open parallel port “LPT1”avrdude.exe done. Thank you.Mine STK200 Pony Prog with pony prog work very wellI try to install giveio sys in windows 32 /drivers and make the same errori try to install giveio in c /avrdudess and the sameHow can i fix thisThank you very much. When I use avrdudessI I get this error when detect is clicked// WARNING: Unable to detect MCUavrdude.exe: error: could not find USB device with vid=0x16c0 pid=0x5dc vendor=’www.fischl.de’ product=’USBasp’avrdude.exe done.
The reading of fuses on an atmega8 does not work for me. Avrdudess fails at reading the efuse (which doesn’t exist on a atmega8). The error message from avrdude is: “efuse” memory type not defined for part “ATMEGA8”Since apparently Arduino had a similar problem at some point, I found a solution to add the efuse memory type with size 0 for an atmega8 to avrdude.conf. This got rid of the not defined error, but now gives a “flash is empty, resulting file has no contents” message (avrdude says flash even if you are reading fuses). Unfortunately this didn’t convince avrdudess to read the lfuse and hfuse. I think you need to either check if the efuse type exists for a chip or check the returnvalue.If I use avrdude (the one included with avrdudess) from the command line ( avrdude -c usbasp -p m8 -U lfuse:r:-:h -U hfuse:r:-:h ), reading fuses is now problem. So the problem is definitely in avrdudess.I found that problem because I wanted to flash an usbasp clone with exactly the same firmware/fuses of two other clones that I already have.
Since I can’t remember what firmware and fuse settings I used and the China clones are always different, I wanted to read back the flash and fuses. Reading the flash worked, reading the fuses only with using avrdude directly. Writing the fuses with avrdudess works, btw., even though it tries to write the non-existing efuse.
IntroductionThere is this USB specialized family or group of everyone’s favorite AVR microcontrollers. Apparently, you can use them as USB devices or hosts without any external components. Hell, you can even program them via USB port. All of that without any external component.
One of those little guys I wanted to use for my last project (reflow oven) and I decided to try the cheapest one, ATmega8u2 as a controller. I ordered some pcbs, some components, soldered everything together and started programming. But the tiny little ATmega8u2 didn’t like the idea AVR USB microcontrollersFew years ago, beloved family of Atmel’s AVR microcontrollers got a new branch in its family tree, the USB mega.
Some of the most popular were AT90usb82, ATmega32u2 or ATmega32u4, differentiating by size of Flash memory or number of peripherals. They would have fully embedded USB capability allowing them variety of beautiful possibilities – they could act as the USB devices at your PC, they could be USB controllers for many peripheral devices in e. Keyboards and mice, printers etc. You’d just need to solder the standard USB connector next to them, put two lines, and magnificent world of USB would be opened for you. Best of all you could program them directly from your PC, over the USB cable. That’s right. No programmer in between or any other piece of hardware (looking at you, FT232).
That was the magic of embedded USB that not many could master. Getting clear with the namesSo, when they came out, not many people could work with them.
USB protocol is hard to understand and even harder to implement. I’m not sure if Atmel published any getting-started documentation or anything useful but it was as good as nothing. I found myself in the same desperate position few days ago when I wanted to make fully USB operable circuit with ATmega8u2.
I searched up and down for any help, how to make the damn USB work, I read every post on AVR Freaks forum. I got totally confused with all the things mentioned apparently without order, DFU, CDC, probably 3-5 definitions of firmware and boot loader, FlipSo, to make things very short, every microcontroller on this world may be programmed to the the stuff we want. The software that sits in the μC’s Flash memory is called firmware and we put it there via small device called programmer. The programmer uses either ISP ( in-system-programming) port or JTAG port to “put the code” in flash memory. “Putting the code” in the flash memory of the microcontroller is often referred to as burning the flash, flashing or simply, programming.Atmel’s USB microcontrollers brought a novelty here – they made it possible to burn the flash without programmer, simply by connecting USB cable from PC to μC. To do that we need something called a boot loader. The boot loader is a piece of firmware that already sits in the μC’s memory and is able to talk to your PC when you plug in the USB cable (or any programmer).
They have disadvantages however; they cannot change the fuse bits of the AVR (special configuration settings that control the operation of the chip itself) and a small portion of the AVR’s FLASH program memory must be reserved to contain the boot loader firmware, and thus cannot be used by the loaded application. All of the USB AVRs like ATmega32u2 or AT90usb162 come with the USB compatible boot loader already burned on them when you buy them so you don’t need to think about it. Just write your code and program the Flash. All of them except one, and of course Mr. Murphy, that’s the one I was using, ATmega8u2.ATmega8u2 comes empty, naked, virgin, with nothing on it. On a hard way I learned the tricky part where you need to burn the bootloader in the flash before you can do anything meaningful with it, and this you do with conventional ISP or JTAG programmer.
Though sometimes the chips can be bought with the bootloader already in the memory, a lot of times you have to do it your self. USB Boot loaders for AVRsI hope you are clear by now that if you want to have a USB programmable microcontroller without additional components, you need to burn some sort of boot loader on it via ISP or JTAG first. For USB based AVRs there are few boot loader options and excellent overview of them is given by.
DFU – USB Device Firmware Upgrade ClassOnce you burn it, the Windows will recognize it as a “Atmel Device” on your PC. Then can use Atmel tool to burn.hex files on it. You have probably encountered this if you have ever tried to. Downside is that no command line tool is available for Windows.
For Linux, an. And you can’t integrate it into Arduino IDE. DFU boot loader comes in almost all off the shelf USB AVRs. Once you burn the DFU bootloader on your AVR chip, the PC will recognize it as a Atmel USB device.which you can program via Atmel’s official tool called FLIP. CDC – USB Communication Device ClassOnce you burn it, the Windows will recognize it as a serial port (so called virtual port) on your PC (LUFA CDC Class Boot loader). Then you can burn.hex files of your program on it with with avrude via, which also means that you can integrate into Arduino IDE.
The command I used for programming was the following one: avrdude -p usb82 -c avr109 -P COM7 -b 19200 -U flash:w:MyHexFile.hex -Favrdude doesn’t have ATmega8u2 on its list so I use AT90usb82 to fool it. The -F at the end prevents signature check so that avrdude doesn’t make troubles out of this incompatibility. Window beautifully recognizing CDC bootloader AVR as a COM port that you can easily program with standard tools like avrdude.
HID – USB Human Interface Device ClassThis one I haven’t tried because I couldn’t have it burned –.hex file was larger than the Flash of ATmega8u2. Here’s what people say about it: PRO – Trouble free – doesn’t require any device drivers – just plug and play, CON- doesn’t integrate into Arduino IDEDFU and CDC require special drivers to be recognizable by the Windows, while HID, apparently works like a charm. To find those drivers on your own can be a pain in the ass but usually they are packed in Boot loader edition folder.To sum this part up – to work with your USB AVR you need to have a boot loader on it. The boot loader either comes on it when you buy the chip, or you burn it yourself with ISP. You can choose between three USB compatible boot loaders: DFU, CDC and HID. For the first two you need a driver to make it recognizable on your PC.
Then you make your program in regular way (with Atmel Studio, WinAVR, or smtg else) and generate the.hex file. Using simple USB connection, you can burn your program onto the AVR’s Flash either by FLIP or avrdude, depending on the boot loader type (HID I haven’t tried yet).Once you have your program burned on the chip’s memory, it will execute every time you power your circuit.
The boot loader will not execute anymore and your circuit won’t be visible on your PC. If you’re unhappy with your program and want to re-program your chip, you need to get back to the boot loader – make it visible on PC once again. This you do simply by reseting the chip – ground the RST pin for a few seconds and the chip will get back to its boo tloader.
It’s almost the same as when you open the BIOS system on your Windows PC. Fuses, fuses they give me bruisesI bet you ran to your work desk immediately to start programming, aren’t you? Well, not so fast! Windows 95 cd download iso. This is what I did and failed. I burned the CDC boot loader, compiled my application and tried the upload it.and everything crashed. So, I had to get back to studying somethin more about AVRs.There is one more thing you need to be careful about, so called fuse bits.
Fuse bits are parts of permanent system registers that describe how will the μC interact with its surroundings. What do you need to know is the hexadecimal value that gets to be written in those registers. Luckily, there is a very neat of fuse values for almost all AVR chips. There are three kinds of fuses: low fuses that determine the clock type of the system; high fuses determine the memory distribution (very important when working with the boot loaders) and extended fuses that determine the brown-out detection (what’s the supply voltage drop that causes internal shut down). Hi,Thanks, for the giving a valuable information on ATMEL USB micro controllersi am an engineering student and electronic hobbiest, new to this type of micro controller.
I am doing a project which contains AT90USB1286 microcontroller, ADS7825(ADC 16-Bit, 4 CHANNEL), strain gage and with analog signal conditioning circuit. Hence, it is nothing but a data acquisition systemi need to transfer the data(processed strain gage data) from Micro controller to PC Via both UART and USB Modes. I wrote all the program and compiled successfully, i am able to transfer the data from AT90USB1286 microcontroller to PC(on Hyper terminal) through UART(RS-232) protocol.i was using ISP protocol, kanda isp(driver software), stk200 dongle(which was made by my self).i made my total hardware circuit on general purpose board and its working functionality is quite good.i am able to program the AT90USB1286 micro controller. I was not using any DFU boot loaders/ FLIP etc.i want to transfer the data(i.e processed strain data) from Micro controller’s inbuilt USB to PC via USB, I read through multiple documents including AT90USB1286 datasheet but i don’t understand them, maybe because i am a student and newbie to this type of micro-controller and no software background(except ‘ C ‘), What i would like to know is how to use the USB hardware build in AT90USB1286(to communicate with PC). And also is there any simple stand alone software, that i can use, write and send the data from AT90USB1286 to PC?i read LUFA-151115. Because of my poor knowledge, i am getting confuse that which one is suited to me among all examples which they provided and i don’t know how to use that library.it is my kindly request you that please help me what i have to do to get transferring the data from AT90USB1286 to PC via USB.if possible, please tell me the step wise procedure to get the data transfer from AT90USB1286 to PC via USB.thank you in advance,excuse me for bad english,regards,vasu. Hello Vasu,sorry for the late response, I was on my honeymoon in South America and didn’t have a proper access to my site host.
Now, if I understood correctly, you would like to use USB as a communication protocol between your AVR and a PC, right? If yes, good, that I can answer, because I’ve also struggled with it myself some time ago.A good way to start it is to look up a Virtual Serial example in LUFA.
In there you establish a USB protocol by initializing a Communications Device Class (CDC) and you can transfer text data using the standard functions fprintf and fscanf.
![]()
This is my first article. There are many areas about creating an instructables which I am new.I just like to share a simple circuit and hope it helps those starting out with AVR who does not have a programmer and like to build one.This article is about building a serial TTL breakout pcb using CH340G.You can use it to program Arduino bootloader firmware on to a blank ATMEGA328 for Arduino board.You can also program USBTINY ISP firmware on to ATTINY85 to make a USB AVR ISP.NOTE: the red jumper wire on the bottom side of the PCB is added due to a broken trace during etching. Parts required1 x CH340G IC 1 x 12MHz crystal 2 x 1N4148 diode 1 x 10nF ceramic capacitor 1 x 10nF capacitor 1 x 100uF capacitor 1 x 2x5 pinheader 1 x 1x4 pnheader 1 x homemade PCB ( above image is 600dpi )This main IC is CH340G which is a USB to serial convertor. Windows drivers for the chip ca be downloaded from D2 diode and JP1 is for selecting 5V or 3.3V operation. ( 3.3V is not exact. It would be about 3.6V)Decoupling capacitors for crystal has been remove to reduce the PCB size and component count.All RS232 signals are routed to pinheader SV1.JP2 is for RS232 assist operation, which inverts RXD signal if shorted. ( Not sure what this function is for but added it as it part of the chip's function.
Maybe it is useful for future project.)The circuit can be use for serial TTL operation.You can also use PL2303 but the schematics has more components.
That's where I got the Atmel-ICE programmer definition from. That should probably be fine. The reason that MCUdude includes avrdude.conf with his hardware packages is that for some reason the stock avrdude.conf is missing definitions for some microcontrollers and he has to add them. I'm not sure if that was actually the case for MegaCore specifically or if he just did it for consistency with his other cores. Certainly the ATmega2560 is defined in the stock avrdude.conf so that is no problem but it's possible one of the less common parts supported by MegaCore is missing.
I'm not sure, it's certainly progress. I get that same exact error when I try to burn bootloader using Atmel ICE (AVR) programmer with no ICE connected to my computer.
I don't own an ICE so I don't know what it would do without.Can you check the VID/PID of the ICE on your computer to make sure it matches the ones expected? I know you can do this via Device Manager in Windows.
I'm not sure what the equivalent is for other operating systems.It's possible it could be a driver issue. I seem to remember I got a similar error when I was trying to use my Atmel AVRISP mkII after installing the Jungo driver for it that is used by Atmel Studio. I had to install a different driver to get it working with AVRDUDE/Arduino. OK, then look into the driver thing. That seems quite likely since you were previously using it with Atmel Studio. I think it's the libusb driver you need.
Traditionally that was libusb-win32 but I've been using libusbK lately and it seems to be better. I use this program to install either:The way I ended up doing it was uninstalling Jungo and installing libusb so it's an either avrdude or Atmel Studio sort of thing but there is a way to allow both drivers to be installed and the correct one used for each program. It's explained here:and you'll notice they had the same error message.
Avrdude is a command line program, so you'll have to type in all the commands (later you'll find out how to shortcut this with a Makefile)UnderWindows, you'll need to open up a command window, select Run. From the Start Menu and type in cmd and hit OK.Under MacOS X, you can use the Terminal program to pull up a command line interface, its in the Utilities folderNow in the new terminal window type in avrdude you should get this response, which is basically a simple list of what avrdude can do.
There are a lot of options, lets review them quickly. Don't try to memorize them, just get a sense of what some of them may do.p: This is just to tell it what microcontroller its programming. For example, if you are programming an ATtiny2313, use attiny2313 as the partnumber.b: This is for overriding the serial baud rate for programmers like the STK500. Don't use this switch, the default is correct.B: This is for changing the bitrate, which is how fast the programmer talks to the chip.
If your chip is being clocked very slowly you'll need to talk slowly to it to let it keep up. It'll be discussed later, for now don't use it.C: The config file tells avrdude about all the different ways it can talk to the programmer.
Theres a default configuration file, so lets just use that: don't use this command switch.c: Here is where we specify the programmer type, if you're using an STK500 use stk500, if you're using a DT006 programmer use dt006, etc.D: This disables erasing the chip before programming. We don't want that so don't use this command switch.P: This is the communication port to use to talk to the programmer. It might be COM1 for serial or LPT1 for parallel or USB for, well, USB.F: This overrides the signature check to make sure the chip you think you're programming is. The test is strongly recommended as it tests the connection, so don't use this switch.e: This erases the chip, in general we don't use this because we auto-erase the flash before programming.U:r w v::format: OK this one is the important command.
Its the one that actually does the programming. The is either flash or eeprom (or hfuse, lfuse or efuse for the chip configuration fuses, but we aren't going to mess with those). The r w v means you can use r (read) w (write) or v (verify) as the command.
The is, well, the file that you want to write to or read from. And :format means theres an optional format flag. We will always be using 'Intel Hex' format, so use iSo, for example. If you wanted to write the file test.hex to the flash memory, you would use -U flash:w:test.hex:i. If you wanted to read the eeprom memory into the file 'eedump.hex' you would use -U eeprom:r:eedump.hex:i.n: This means you don't actually write anything, its good if you want to make sure you don't send any other commands that could damage the chip, sort of a 'safety lock'.V: This turns off the auto-verify when writing. We want to verify when we write to flash so don't use this.u: If you want to modify the, use this switch to tell it you really mean it.t: This is a 'terminal' mode where you can type out commands in a row. Don't use this, it is confusing to beginners.E: This lists some programmer specifications, don't use it.v: This gives you 'verbose' output.in case you want to debug something.
If you want you can use it, but in general we won't.q: This is the opposite of the above, makes less output. In general we won't use it but maybe after a while you wold like to.The ones you'll use 99% of the time are highlighted in red. Let's review them in more detail. To get a list of supported programmers, type in avrdude -c asdf ( asdf is just some nonsense to get it to spit out the list of programmers) Here is my output, yours may vary a little.
To get a list of parts supported by avrdude, type in avrdude -c avrisp (it doesnt matter if you're not useing an avrisp programmer) without a part number into the command line. This switch tells avrdude where to look for your programmer.
![]()
If you are using a USB connected device, you can just use -P usb or, leave it out. The programmer automatically knows when the programmer is a USB device.If you are using a parallel port or serial port programmer, you should use this option to indicate what port the programmer is connected to. 99% of the time its lpt1 (parallel) or com1 (serial) but you can always check it by looking under the Device Manager. Open the System Properties control panelClick on Device Manager, and open up the Ports submenu.All of the serial and parallel ports are listed. There may be multiple COM ports but there's usually only one parallel (printer) port.For Mac's, there are no parallel ports.
However, if you're using a (which lets you use an STK500 or AVRISP v1 with a Mac) then you'll need to specify the serial port. I don't know a foolproof way yet but the way I do it is in the Terminal I type in ls -l /dev/cu. and it will spit out a bunch of stuff (I screwed up the screen capture, this image has another window in front of it, but just ignore that)/dev/cu.Bluetooth is the built in bluetooth stuff, dont use that.
/dev/cu.modem is the modem (if there is one), dont use that either. What you're looking for is something like /dev/cu.usbserial or /dev/cu.KeySerial1 or something similar. In this case its /dev/cu.usbserial-FTCTYG5U. OK we're at the important part.
This is where we actually get around to telling avrdude how to put the data onto the chip. This command is rather complex, but we'll break it down. can be flash, eeprom, hfuse (high fuse), lfuse (low fuse), or efuse (extended fuse)r w v - can be r (read), w (write), v (verify) - the input (writing or verifying) or output file (reading):format - optional, the format of the file. You can leave this off for writing, but for reading use i for Intel Hex (the prevailing standard )For example:.
To write a file called firmware.hex to the flash use the command: -U flash:w:firmware.hex. To verify a file called mydata.eep from the eeprom use the command -U eeprom:v:mydata.eep. To read the low fuse into a file use the command -U lfuse:r:lfusefile.hex:i. OK enough of this jibber-jabber. Its time to program the firmware into a chip!Get your AVR target board ready to go, we'll be using an attiny2313 in this example but of course you should substitute the chip you're using (in which case the code will probably not do anything).
Fuse memory is a seperate chunk of flash that is not written to when you update the firmware. Instead, the 3fuses tend to be set once (altho they can be set as many times as you'd like). The fuses define things like the clock speed, crystal type, whether JTAG is enabled, what the brownout (minimum voltage) level is, etc.First you'll want to calculate fuses using the very convenientTo program the fuses, use:avrdude -c usbtiny -p attiny2313 -U lfuse:w::mavrdude -c usbtiny -p attiny2313 -U hfuse:w::mavrdude -c usbtiny -p attiny2313 -U efuse:w::mWhere is the desired fuse value, in hex. For example to set the high fuse to 0xDA:avrdude -c usbtiny -p attiny2313 -U hfuse:w:0xDA:mSetting the fuses incorrectly can 'brick' the chip - for example you can disable future programming, or make it so the chip is expecting an external crystal when there isn't one.
For that reason I suggest triple-checking the fuse values. Then check again, make sure you aren't disabling ISP programming or the Reset pin or setting the clock speed to 32kHz.
Then verify again that you have the correct chip for calculation. Then finally you can try writing them to the chip!Remember: once you set the fuses you do not have to set them again. If the programmer is not properly connected to the chip, you'll get the following message: initialization failed, rc=-1 Double check connections and try again, or use -F to override this checkDon't use -F to override the check, even though it is suggested!This means that the programmer couldn't talk to the chip. If you are using a 'simple' programmer such as a serial or parallel port bitbang programmer, it could mean the programmer is at fault. Otherwise, it usually means the programmer is OK but it couldnt find the chip.Check that the chip is powered, plugged into the socket or programmer properly, the programming cables are plugged in correctly, the header is wired correctly, etc.
99% of the time, it is a problem with wiring.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |