When trying to read fuses or lockbits from AVRDude options page in project properties, the plugin outputs a wrong command line to invoke AVRDude:
avrdude -cavrisp2 -Pusb -pm16
this command fails saying "avrdude: initialization failed, rc=-1"
Since I'm using ATXMEGA128A1 mcu, the part specified in the command line doesn't reflects the project target hardware setting.
I think the command line should be: avrdude -cavrisp2 -Pusb -px128a1
This behavior is present also when trying to load the "Flash memory erase cycle counter" in the "other" page of AVRDude options.
P.S. My project is setup correctly as I can program my board and the fuses (when I set them manually).
Please take a look at this. Xmega devices uses a different type of initialization than traditional MEGA.
Some internal functions like "read fuses from MCU" try to automatically detect which MCU type is connected. This was done as a safeguard against user errors where the connected MCU is not the same as set for the project.
They do this by passing -pm16 to avrdude and parsing the response from avrdude (which will report the correct MCU type)
It seems that this autodetection fails with ATXmegas, but I don't have any ATXmegas to test this (I just ordered an XPlain board as a remedy :-).
So, in the meantime could you please provide the full avrdude console output? (If you haven't done this already please select Window->Preferences...->AVR->AVRDude -> Log internal AVRDude output to console).
This way I could already start to work on the bug while I wait for my XPlain board.
This is the output log in CDT:
Launching C:\Programmi\Atmel\WinAVR\bin\avrdude -cavrisp2 -Pusb -pm16
Output:
avrdude: stk500v2_command(): command failed
avrdude: stk500v2_command(): unknown status 0xc9
avrdude: stk500v2_program_enable(): cannot get connection status
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude execution aborted
To help you, I tryed from command line to execute the command with xmega16a4 part and
avrdude answers in the following way:
avrdude -cavrisp2 -Pusb -px16a4
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e974c
avrdude: Expected signature for ATXMEGA16A4 is 1E 94 41
Double check chip, or use -F to override this check.
avrdude done. Thank you.
and specifying the correct part (xmega128a1):
C:\Documents and Settings\s.zamboni.ELTASRL>avrdude -cavrisp2 -Pusb -px128a1
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e974c
avrdude done. Thank you.
I think avrdude must know that the target hardware is a XMEGA part because MEGA and XMEGA
series uses completely different protocols: ATMEGA is programmed over SPI and XMEGA uses the
new PDI programming port.
I know would be a better way to automatically recognize the device attached but wouldn't be
simpler to just use the one specified by the user in the target page? If the user doesn't
set any device he will receive an error.
I can perform further test if you need extra informations.
I think I have fixed this bug (and another XMega related bug that popped up once I had fixed this issue).
Could you please try the fix to see if it works for you as well?
I have uploaded the fixed plugin to the inofficial update site at avr-eclipse.sourceforge.net/previews or you could just use the following link to download the p2 repository which can be used as a local installation source.
http://avr-eclipse.sourceforge.net/previews/avreclipse-p2-repository-2.3.4.20100706betaNGT.zip
BTW the plugin still tries to determine the MCU automatically, it will just try an XMega typ if the a 'conventional' AVR MCU fails. Anything else would have meant a large rewrite of the plugin.
Yes, this works for me too!
As I stated before, the only problem is that XMEGA uses a different protocol for the external programmer than the standard MEGA parts and AVRDude doesn't try automatically both protocols, it uses only the one for the part family you have specified in the command line.
So I think your approach is optimal. This enhancement should go into the next release.
Good job and many thanks for this great plugin!
Good! I'll release the fix in the next days as 2.3.4.
Fix released with 2.3.4
Is this the same issue? I'm using Eclipse (2019) and have never been able to get the device fuses or anything else like that read from the target (now an attiny85 't85'.) As I read this it looked very similar. The supplied link is no longer functional. It works fine from the command line or during actuall programming. Here is the output from eclipse window:
Seems very similar. Any suggestions?