Update of bug #37489 (project avrdude):
Status:None = Need Info
Assigned to:None = joerg_wunsch
___
Follow-up Comment #1:
I just committed a
As Joerg Wunsch wrote:
I just tried the script on my FreeBSD, and it still compiles. Will
try a Linux version later today.
It stops here:
i686-w64-mingw32-gcc -Wall -Wno-pointer-sign -g -O2 -DWIN32NATIVE
-L/usr/i686-w64-mingw32/lib -static -o avrdude.exe avrdude-main.o
avrdude
Follow-up Comment #8, bug #37997 (project avrdude):
One discrepancy immediately catches attention:
The OK log says:
Programmer Type : avr910
The Failed log says:
Programmer Type : butterfly
Given the large number of device codes that are supported by
the programming hardware, I really
Update of bug #38732 (project avrdude):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #38580 (project avrdude):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #39691 (project avrdude):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #39690 (project avrdude):
Status:None = Postponed
___
Follow-up Comment #1:
Well, I asked about a couple of years ago whether anyone is
still using the erase cycle counter,
Update of bug #37441 (project avrdude):
Status:None = Need Info
___
Follow-up Comment #1:
Well, we traditionally named the lock bits section lock, not
only for Xmega devices but also for
Follow-up Comment #6, bug #37997 (project avrdude):
See comment #2: please get us a full - log of both
versions.
Yes, the avrdude.conf format has changed in the current version
(and that's the major reason why the next version will be
called 6.0). Remember that you can always specify an
I wrote (a couple of years ago):
The erase cycle counter, stored in the last 4 EEPROM cells of the
device, might have been a neat idea by its time. However, I think the
days of its usefulness have long since been past. Nobody really cares
about flash wear by normal programming cycles these
Update of patch #8045 (project avrdude):
Status:None = Done
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #38951 (project avrdude):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of patch #7769 (project avrdude):
Status:None = Done
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Enoch wrote:
Regarding r1205, incidently I just finished fixing butterfly.c as well :-)
My patch is at: http://pastebin.com/CfP5iK9q
Please don't use pastebin for that. Best is always to open a
patch tracker, or maybe a bug tracker (if it's really a bug).
After all, savannah is *our*
As Joerg Wunsch wrote:
I also added some more trace code for -vvv, but only for the TPI
portion of usbasp.c by now.
I also added it for the non-TPI functions now. Thus, USBasp can be
traced with a detailed log with -vvv, and including the low-level
device communication with -. Hopefully
As Joakim Lubeck wrote:
I think it sneeked in a bug there, it's verbose even if I not tell
it to be.
You're right, thanks for spotting it.
Fixed.
--
cheers, Joerg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
Never trust an operating system you don't have
Update of bug #38713 (project avrdude):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #38023 (project avrdude):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #37105 (project avrdude):
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Timed out on requesting more information.
Update of bug #39794 (project avrdude):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #35800 (project avrdude):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of patch #8130 (project avrdude):
Status:None = Need Info
Assigned to:None = joerg_wunsch
___
Follow-up Comment #2:
Despite some minor
As j...@maths.lth.se wrote:
So I did some brute-force testing with a lot of different versions.
Thanks, Joakim.
962 - 975 - also working.
I just committed a change to SVN trunk that enables a communications
trace for USBasp with -. If you rebuild trunk, this should get
you a trace for
(Better subscribe to the list to see all replies.)
As Robert Wheeler wrote:
Need help getting this to work on my Linux system. It won't recognize
the ubs and I don't know how to recognize the right port.
Sorry, I'm confused.
I assume ubs actually means usb. Still, what does won't
recognize
Update of bug #39893 (project avrdude):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Joerg Wunsch wrote:
Follow-up Comment #2:
It turned out when using -U flash:w:filename, the address
argument passed to stk600_xprog_memtype() was wrong, so the
page erase attempted to erase a boot page when it was about
to erase an application page.
Using plain -U filename
As Joakim Lubeck wrote:
When I use usbasp (latest firmware) with TPI (tested tiny10, 20, 40)
it gives me verification errors, like
...
But it works without problems if I use the version RELEASE_5_11_1.
This is kind of strange.
I just compared the USBasp code in AVRDUDE between
As Joakim Lubeck wrote:
But it works without problems if I use the version RELEASE_5_11_1.
Well, the USBasp code doesn't offer much debugging output.
The AVRISPmkII code does, can you please try running with -, and
compare the logs between both version in order to try finding a
difference?
Follow-up Comment #1, bug #39893 (project avrdude):
This appears to be an issue with the ATxmega128A1. I can
see verification errors there, too, while an ATxmega16D4
works without problems.
___
Reply to this item at:
As Galen Seitz wrote:
While building avrdude 6.0rc1 under CentOS 6.4, I encountered the
following warnings. Are these to be expected?
Some of them yes, but not all of them.
Please file a bug report, as I won't be able to fix them right now.
avr.c: In function 'avr_tpi_program_enable':
As Simone wrote:
after ./configure i have this situation:
Configuration summary:
--
DON'T HAVE libelf
You'd probably would like to have that one, because it allows you
to flash ELF files directly.
how can i enable or disable each of those item ?
By (not) installing
As Simone wrote:
I just want to be able to compile a different type of build without
the need to remove the library from mingw setup.
I don't see the reason. But if you think you need it, go and
implement it into configure.ac, and contribute the patch through
the patch tracker.
I currently
As Kevin Cuzner wrote:
Now, in terms of exactly what gets sent
when, PROGRAMMER-cmd is the important one...avrdude will give the
commands to the programmer 4 bytes at a time along with a buffer to fill
with whatever was received through that function.
The main reason for this is that AVRDUDE
As Simone wrote:
How can i aplly the .patch file ?
With the patch utility.
http://en.wikipedia.org/wiki/Patch_%28Unix%29
--
cheers, Joerg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)
As Simone wrote:
Can avrdude be compiled with the latest libusb-win32 or should i use 1.2.4
or older ?
So far, most of the AVRDUDE code still relies on the older
libusb 0.1 API. AFAICT, newer versions still support this
API through some kind of emulation layer, so it ought to work.
Just give
Update of bug #39399 (project avrdude):
Status:None = Invalid
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Ing. Daniel Rozsnyó wrote:
--- avrpart.c.orig2013-06-25 18:13:02.870902661 +0200
+++ avrpart.c 2013-06-25 18:13:17.979902822 +0200
Please, please, submit patches to a patch tracker. Otherwise,
they risk to get lost.
--
cheers, Joerg .-.-. --... ...-- -.. . DL8DTL
As Ing. Daniel Rozsnyó wrote:
But when I read back the fuses using:
avrdude -c jtag3pdi -p atxmega32a4u -U fuse0:r:-:h
avrdude -c jtag3pdi -p atxmega32a4u -U fuse1:r:-:h
avrdude -c jtag3pdi -p atxmega32a4u -U fuse2:r:-:h
avrdude -c jtag3pdi -p atxmega32a4u -U fuse4:r:-:h
avrdude -c
As Anton Smirnov wrote:
avrdude: ser_setspeed(): tcgetattr() failedavrdude: ser_open(): can't set
attributes for device /dev/bus/usb/002/002: Not a typewriter
That cannot work.
What is the reason of error?
You need a serial emulation device. Depending on your operating system,
the pathname
As Anton Smirnov wrote:
/dev/bus/usb devices cannot be used directly for STK500v2.
All this relates to Android. I'm not using file path (see above), but file
descriptor passed from android app.
But how is that file descriptor obtained, i.e. which pathname has
been provided to open()
As Anton Smirnov wrote:
Only the underlying driver knows how to e.g. talk to the serial
emulation device at the other end of the USB in order to adjust
baudrates, control signals etc.
Okay, so now the question is what is this file descriptor and how
can it be used in native code. Even
As Anton Smirnov wrote:
You'd end up in reimplementing (parts of) a serial device emulation
in AVRDUDE. I don't think this is a useful approach.
Okay, i've been thinking about it, but it seems to be pretty
difficult for me.
There's no uniform handling for this. If the backend implements
As Anton Smirnov wrote:
The main problem now i think is to understand what is this file
descriptor nature sincestandard posix impl can't work with it.
As I said: you have to reimplement a virtual serial port driver
on top of it. The descriptor is only useful to transmit/receive
URBs through
Update of bug #39230 (project avrdude):
Status:None = Invalid
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Axel Wachtler wrote:
Sorry for jumping in, I just roughly followed the discussion, but might
this be the missing software part:
http://code.google.com/p/usb-serial-for-android/ ?
To me, it very much looks like that, yes.
The main difference is that it needs its own method to set
As Anton Smirnov wrote:
I'm getting file descriptor for usb device on android, grant
permissions and pass usb device file descriptor to avrdude process
and getting Now a typewriter error in ser_posix while trying to
set baud rate.
What kind of programmer?
Most USB-connected programmers in
As Anton Smirnov wrote:
This relates to Arduino boards and they have bootloader which talks over
USB using stk500v1/v2 and uploads firmware itself.
OK, they indeed use a serial device emulation.
If you get an ENOTTY on setting the baudrate, it would mean your
driver (the part of the operating
As Anton Smirnov wrote:
is there any work around for it (without rooting)?
Frankly: I don't know.
Depending on your Arduino platform, setting the baudrate might be
required or not. If it's not required (e.g. since the STK500v2
protocol is handled by a controller directly attached to USB, I've
As Anton Smirnov wrote:
Frankly: I don't know.
Can you say what is required (compile params, flags, etc..) exactly?
I think i will have to ask for it from android engineers or smth.
It's the POSIX (“Single UNIX Specification”, SUS) API calls
tcgetattr()/tcsetattr(), in whatever way they
As Anton Smirnov wrote:
Okay, since i'm completely in stuck with it i have to try just
comment/remove isatty() check.
That's simple enough. Let's hope the remainder does work.
Do you think i have to just pass file descriptor as int and just
skip using socket?
You could give it a try.
As René Liebscher wrote:
TYPE_232H undeclared means, that your libftdi is version 0.20.
Yes, it's still at 0.18, as this used to be the version FreeBSD was
shipping back when I installed it. ;-) (I could probably upgrade it
again, but the old one at least works well enough for older FTDI
As Joerg Wunsch wrote:
I just bumped the version in configure.ac to 6.0rc1; it has
been at 5.11svn for way too long now. Yes, this is a strong
indication we are heading for a release. ;-)
I'd like to invite everyone to browse through the bug and patch
trackers. You might apply everything
Follow-up Comment #2, patch #7876 (project avrdude):
I hate nabble, really. They are presenting other people's
content, but no reference to the original discussion, not
even a timestamp. :-((
FWIW, here's the link to our own mailinglist archive:
As Hannes Weisbach wrote:
(I can take over the
testing part for that if you want, I've got an FT2232D board and an
FT232H sample module to try with.)
Thanks for the offer. Does it include libusb-1.0 with libusb-compat
and libftdi-0.x too? ;)
Depends on how you'd recognize FreeBSD's
Update of patch #7876 (project avrdude):
Status:None = Done
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
I've got an older libftdi installed, and my libusb doesn't install the
1.0 header file into a subdirectory (because it's not a 3rd-party
library but an OS-supplied one):
In file included from ../avrftdi.c:43:
../avrftdi_private.h:9:31: error: libusb-1.0/libusb.h: No such file or directory
As Hannes Weisbach wrote:
The usbasp.c patch doesn't work: USBasp doesn't have a cmd_tpi, so
when avr_tpi_program_enable() calls pgm-cmd_tpi(), it segfaults.
I don't understand enough of the USBasp TPI implementation to get an
idea how to establish a cmd_tpi method there.
I have whipped
As Hannes Weisbach wrote:
gcc/clang is available for Windows (mingw), Linux, *BSD, OS X,
... so which major platform causes the holdup? Or is there some
other reason I'm missing?
AVRDUDE used to be compilably on Visual C in the past, I think,
and Microsoft stopped any development on C, so
As Ing. Daniel Rozsnyó wrote:
But no mention about what the VTG is (input or output, what voltage
it accepts or supplies).
As already with the JTAGICEmkII, VTG is normally called VTREF. It's
the reference supply voltage from the target, which is used for the
levelshifters, so the ICE talks at
As Joerg Wunsch wrote:
As Joerg Wunsch wrote:
The entire pgm structure appears to be garbled after some point:
More datapoints: update.c obviously has a different idea about
struct programmer_t than anyone else:
The confusion arose out of pindefs.h testing for HAVE_STDINT_H
As René Liebscher wrote:
as C guarantees only 16 bit for an int but 32 bit for a long, you
better take the long as fallback. (even if is unlikely that avrdude
will ever be compiled for a machine with only 16 bit integer.)
We rely on default integers being 32 bit in AVRDUDE in so many places,
As Joerg Wunsch wrote:
So port is given as 0x01 here. Stack frame #1 is:
pgm-vfy_led(pgm, ON);
No idea offhand why that triggers a jtagmkII_open() with bogus
arguments.
The entire pgm structure appears to be garbled after some point:
(gdb) p *pgm
$2 = {id = 0x6df060, desc = Atmel JTAG
As Joerg Wunsch wrote:
Other AVRs require the HV on /RESET to be in the range of 11.5 through
12.5 V. You have to measure the current consumption, but after all,
this is a MOS input only, so I wouldn't expect it to draw much beyond
of about 1 µA.
Actually, it's more. I measured about 550
As Hannes Weisbach wrote:
Actually, it's more. I measured about 550 µA @ 12 V, but with a
few 100 mV more, it could be about 2 mA already.
Hm. Too much current to supply from TPICLK (it's not running
continuously). Well, a ring oscillator/voltage tripler, then.
Or, just leave it to the
As Hannes Weisbach wrote:
as of SVN r1156, avrftdi now supports TPI (and I hope I didn't break
anything else in the process).
Thanks!
Page read and write operations should speed up these operations
somewhat, but TPI requires to poll a bit (NVMBSY) after each written
word, so don't expect
As Hannes Weisbach wrote:
I think a resistor between MOSI and TPIDATA is enough; MISO is an input
only anyway, so it cannot drive any output against the TPIDATA output.
Theoretically yes. But this is freely configurable over MPSSE. So
the question is, in which state the FTDI is, before
As Louis Thiery wrote:
I am trying to understand the memory descriptions in the conf file, but
I don't understand where the offset addresses come from and am having
trouble finding documentation on it.
See
Figure 30-3. Memory map for PDI accessing the data and program memories.
in the
As Axelrod, Benjamin wrote:
I saw that support for JTAGICE3 was only recently supported in
trunk. I thought I would share that I successfully used avrdude svn
revision 1144 with JTAGICE3 over PDI on an atxmega128a1 and
atxmega32a4.
Thanks for the feedback, it's always welcome!
--
cheers,
As Hannes Weisbach wrote:
Maybe you can create a working windows binary with latest svn version, if it
is working with your hardware (just read a empty flash back in file), it
should working with my hardware too.
I don't have a Windows tool chain.
Just to mention it: no need for having a
Follow-up Comment #8, bug #38659 (project avrdude):
As “programming” 0xff into flash is effectively a no-op,
what reason should exist to store these bytes in any file?
(Sure, in a binary file, intermediate 0xff bytes cannot be
omitted; in a hex or s-record file, even that would be
possible, but
As microther...@gmail.com wrote:
I don't know if this is urgent, but the relatively new ATtiny1634
is starting to be quite popular and I guess many would want it
supported by avrdude.
I’d like to second that request!
Please submit a feature request:
Update of patch #7896 (project avrdude):
Status:None = In Progress
Assigned to:None = joerg_wunsch
___
Follow-up Comment #1:
Thanks for the
/
Copyright (c) 2007-2009 Joerg Wunsch
...
Programmer Type : flip2
Description : FLIPv2 USB DFU protocol (AVR4023)
avrdude: Found VID=0x03eb PID=0x2ff0 at 003:003
At that point, it just exits.
I guess it needs a bit of further debugging before we can
commit
Follow-up Comment #3, patch #7896 (project avrdude):
It stops at that point under Linux since it segfaults. This
is because there are zero endpoint descriptors present, so
found-config-interface-altsetting-endpoint
equals 0 here:
memcpy(dfu-endp_desc,
As Simon Sabato wrote:
1) there is an assumption built in that an erased page is full of
1's. It is slightly inelegant to not have any way of working around
that assumption in a system which behaved differently, should such a
system ever be implemented.
That system wouldn't be an AVR
Update of bug #38199 (project avrdude):
Summary: Feature request: Display a warning when using the
spifreq parameter of a Bus Pirate = Feature request: Clarify 'initialization
failed' error message
___
Reply to this item
Update of bug #38172 (project avrdude):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Lars Andersson wrote:
Here's a command line example:
avrdude -cstk500v2 -B4 -pm16 -P/dev/ttyS0 -v -e -Uflash:w:main.hex:i,10,0,6
Is this implemented in avrdude already or do I have to apply the patch and
recompile. Also, if not implemented is there a reason for this ?
Reading the
As Kirill Levchenko wrote:
The new XMEGAs A3Us and A4Us don't seem to work with the existing
JTAG code; I think the protocol may have changed in some
incompatible way.
If someone who owns such a device were about providing an USB sniffer
trace of the Atmel Studio JTAGICE communication, I'm
As Jiří Pinkava wrote:
I have made hacky utility in python for programming my ATxmega128A1
Curious, what's the purpose? The ATxmega128A1 has been supported
in AVRDUDE for many years now.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
As Stuart Cording wrote:
I am trying to add support for the ATmgea32C1 in avrdude.conf. My key aim
is to support this MCU (and some others later) to be programmed using the
Arduino IDE.
Well, the Arduino still uses the ancient STK500v1 protocol. The
parametrization in this protocol was
As N. St. wrote:
The new manpage in the repository seems to be correct, but there
haven't been any releases since the fix was added (actually, there
haven't been any for almost 15 months). Are there any plans for a
new release?
There are always plans. ;-)
There's no fixed date yet though.
Update of bug #38050 (project avrdude):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #3:
As it's already
Follow-up Comment #7, bug #37942 (project avrdude):
Yes, it appears to be a genuine firmware bug (because these
response codes are completely out of context). After
upgrading my Dragon to 7.24, I see the same.
Since earlier AVRDUDE versions could work around the bug,
I'll see what I can do
Update of bug #37942 (project avrdude):
Status: In Progress = Ready For Test
Assigned to:None = joerg_wunsch
___
Follow-up Comment #8:
I think I found a
Update of bug #37801 (project avrdude):
Status:None = Works For Me
Assigned to:None = joerg_wunsch
___
Follow-up Comment #3:
Thanks for supplying
Follow-up Comment #2, bug #37942 (project avrdude):
Thanks for the log file. Looks really strange.
Alas, I cannot reproduce it with my Dragon (but my firmware is 7.14,
yours is 7.24). Can you please also mail me the - log from the
old (working) version, for a crosscheck?
Follow-up Comment #3, bug #37942 (project avrdude):
That firmware's behaviour is really strange, but I noticed you've also
got a earlier hardware revision than me (6 vs. 7), no idea whether
that makes a notable difference. The result codes are really
unexplainable. 0x84 in response to program
Update of bug #37942 (project avrdude):
Status: Need Info = In Progress
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?37942
___
Follow-up Comment #5, bug #37942 (project avrdude):
I'm not sure how to, but I'll spend some time tonight figuring it out.
I'm afraid you have to install an older version of AVR Studio
for this. I think firmware 7.14 (7.e in Atmel's notation)
correlates to some Studio 5.x version.
Thanks for
As Joerg Wunsch wrote:
By now, I'm concentrating on the megaAVR architecture with JTAG
connection path, but other combinations (Xmega/JTAG, Xmega/PDI,
mega/tinyAVR/ISP, tinyAVR/debugWIRE) are already considered in the
code, and will be completed later.
Update: Xmega support has been
Based on USB sniffer traces Knut Schwichtenberg posted to the AVaRICE
project (and some traces I made myself), and based on much guesswork
and similarity to the JTAGICEmkII, I just added some initial support
for the Atmel JTAGICE3 to SVN.
By now, I'm concentrating on the megaAVR architecture with
Follow-up Comment #1, bug #37801 (project avrdude):
Would you be willing to also supply the hex file in question?
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?37801
___
Update of bug #23011 (project avrdude):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Follow-up Comment #1, bug #37697 (project avrdude):
Could you resend it as the output of a diff -u command between
the original and your modified version?
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?37697
Follow-up Comment #3, patch #7538 (project avrdude):
Where can I find the preamble in the patch tracker?
Just try submitting a new patch, and you'll see it. (Don't
complete the procedure, just start it, pretending you were
submitting something new.)
Should I submit a patch containing
As Ing. Daniel Rozsnyó wrote:
Is the GPIO support in FTDI devices hard to implement for new
devices, or do they follow some common design so it is just a matter
of few lines of code?
I guess you'd better ask on the libftdi mailinglist for this.
AVRDUDE relies on libusb and, where needed,
Follow-up Comment #34, bug #30559 (project avrdude):
One little problem appeared however, now avrdude
hangs after all the messages.
I've also observed this in some situations. Will be fixed
before the next release.
___
Reply to this
As John cliffer wrote:
http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopict=124601
It always helps to describe at least the *basic* problem in your mail,
too. It appears to be an issue with the USBasp. Sorry, I don't know
much about that programmer.
Please reply ASAP.
ASAP? No,
As John cliffer wrote:
http://helix.air.net.au/files/4613/4609/6931/avrdude-5.11svn1102-win32.zip
Is it right package for avrdude to use USBASP ?
It's a development snapshot, rather than a regular release.
If you've got problems with that, it's certainly good to report them
here (as the
501 - 600 of 1231 matches
Mail list logo
