Nabble - AVR - AVRdude - Dev

[patch #6866] bug #26703: [Feature Request] Support device reset for 'arduino' programmer type

2009-12-13T04:09:35Z

Follow-up Comment #12, patch #6866 (project avrdude):

Can I add this feature (I created patches diffing directly the svn files and
5.8 release) to the avrdude macport as a variant?

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/patch/?6866>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: writing two Fuse Bytes faild

2009-12-12T12:02:23Z

As Markus Burrer wrote:

> > Depending on which programmer you're using, if it's an STK500 like
> > one, you could setup a trace for it under AVR Studio, and have a
> > look what they are doing. See the STK500 (online) documentation.

> I'm using AVRISP mkII.

That counts as "STK500 alike". It's using the same higher-level
protocol, just on top of an USB transport instead of RS-232 with the
old STK500.

> Maybe it is possible to debug the USB communication?

Yes, as I mentioned: have a look into the STK500 documentation.
Towards the end, there's a debugging hint. IIRC, you can create a
registry entry denoting a log file that logs the entire programmer
communication.

In AVRDUDE, you can see the equivalent of that with -vvvv (four
options "v").

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: writing two Fuse Bytes faild

2009-12-12T11:59:47Z

Joerg Wunsch schrieb:
> I didn't program AVR Studio, so I don't know. ;-)
>
> Depending on which programmer you're using, if it's an STK500 like
> one, you could setup a trace for it under AVR Studio, and have a look
> what they are doing. See the STK500 (online) documentation.
>
>

I'm using AVRISP mkII. Maybe it is possible to debug the USB communication?

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: writing two Fuse Bytes faild

2009-12-12T11:49:47Z

As Markus Burrer wrote:

> how does AVR Studio handels this?

I didn't program AVR Studio, so I don't know. ;-)

Depending on which programmer you're using, if it's an STK500 like
one, you could setup a trace for it under AVR Studio, and have a look
what they are doing. See the STK500 (online) documentation.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: writing two Fuse Bytes faild

2009-12-12T03:20:19Z

Joerg Wunsch schrieb:

> As Markus Burrer wrote:
>
>
>> If I repeat the same command, both fuse bytes are written
>> successfull. What's wrong here? (I'm using Ubuntu Linux)
>>
>
> I suspect this is due to the latching of fuse byte changes.
> All fuse changes affecting oscillator options are latched
> internally, and deferred until after the current ISP session
> has terminated. That way, one ISP session always operates
> with the same CPU clock source.
>
> All AVRDUDE -U options are handled within a single ISP session.
> Running a separate command, of course, initiates a new session.
>
>

how does AVR Studio handels this? There it seems to be a single session

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: writing two Fuse Bytes faild

2009-12-12T02:08:16Z

As Markus Burrer wrote:

> If I repeat the same command, both fuse bytes are written
> successfull. What's wrong here? (I'm using Ubuntu Linux)

I suspect this is due to the latching of fuse byte changes.
All fuse changes affecting oscillator options are latched
internally, and deferred until after the current ISP session
has terminated. That way, one ISP session always operates
with the same CPU clock source.

All AVRDUDE -U options are handled within a single ISP session.
Running a separate command, of course, initiates a new session.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

writing two Fuse Bytes faild

2009-12-12T01:54:10Z

Hi, if I try to write more than one fuse byte with one command, the
second fuse byte fails. For example

avrdude -pm32 -Ulfuse:w:0xff:m -U hfuse:w:0xc9:m

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9502
avrdude: reading input file "0xff"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xff:
avrdude: load data lfuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip lfuse data:

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

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xc9"
avrdude: writing hfuse (1 bytes):

Writing | | 0% 0.00s
***failed;
Writing | ################################################## | 100% 0.03s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xc9:
avrdude: load data hfuse data from input file 0xc9:
avrdude: input file 0xc9 contains 1 bytes
avrdude: reading on-chip hfuse data:

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

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0xc9 != 0x99
avrdude: verification error; content mismatch

avrdude: safemode: hfuse changed! Was c9, and is now 99
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK

avrdude done. Thank you.

If I repeat the same command, both fuse bytes are written successfull.
What's wrong here? (I'm using Ubuntu Linux)

Regards
Markus

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: Compiling avrdude with libusb

2009-12-07T07:10:28Z

I am using this library right now. I posted on it a short while ago. You
need libusb and a lib-compat that provides glue functions that map into
the old libusb:

(my previous post)

Sending this for the archives - had good luck getting libusb-1.0.3 and
the compatibility library (which maps the new library calls into what
avrdude expects from libusb.0.1). Its seems faster when downloading but
didn't really measure it.

For OSX Mac users, a note: if you use a portable, as I do, both old and
new libusb libraries try to get info out of suspended USB devices like
the camera. This adds many seconds of delay before the download starts.
I edited the darwin_usb.c file in libusb.1.0, and essentially commented
out code. This resulted in a much much faster download.

David

if (ret != kIOReturnSuccess) {
int try_unsuspend = 0; // DFH - was 1
#if DeviceVersion >= 3200 // DFH - was 320

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: Compiling avrdude with libusb

2009-12-06T21:11:44Z

As dlc wrote:

> I've finally gotten a need to use avrdude with a USB AVR
> programmer. I downloaded libusb 1.0.6, ...

Sorry, avrdude so far only works with libusb 0.1.x.

The reason for that is that libusb 1.x covers only a small subset of
the operating systems libusb 0.1.x used to cover, and both versions
are completely API incompatible.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Compiling avrdude with libusb

2009-12-06T21:06:14Z

Greetings,

I've finally gotten a need to use avrdude with a USB AVR programmer.
I downloaded libusb 1.0.6, built that, got the latest avrdude source
5.8, configured pointing to the libusb libs, but the configure says this
about libusb:
checking for usb_get_string_simple in -lusb... no

Nothing I do will get avrdude's configure to recognize libusb. Here are
the "things" that I set up:

export CFLAGS=-I$IDIR/include
export LDFLAGS=-L$IDIR/lib
cd avrdude-5.8/
./configure --prefix=$IDIR

where IDIR is the installation directory where the libusb stuff lands in
the appropriate lib and include directories. I've checked, they're there.

There seems some confusion (to me) in on-line resources which refer to
"the latest libusb", but then they talk about 0.1.12 which is a year
old, libusb 1.0.6 is a couple of months old. I vaguely remember reading
something about one of the libusb trees being abandoned and not working
correctly, but the dates on the two repositories leave me wondering
which "branch" might be the old or defective one.

Can someone shed some light on this for me - It is obvious to me that
I've missed some note or page that details what I should be doing since
I'm pretty sure that I have the procedure correct, just something is not
working...

Thanks all,
DLC

--
-------------------------------------------------
Dennis Clark TTT Enterprises
www.techtoystoday.com
-------------------------------------------------

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

[patch #7010] Win32 enhanced bitbang_delay

2009-12-02T01:37:41Z

URL:
<http://savannah.nongnu.org/patch/?7010>

Summary: Win32 enhanced bitbang_delay
Project: AVR Downloader/UploaDEr
Submitted by: dougy83
Submitted on: Wed 02 Dec 2009 09:37:40 AM GMT
Category: None
Priority: 5 - Normal
Status: None
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
Discussion Lock: Any

_______________________________________________________

Details:

I read that the bitbang_delay is not calibrated for Win32 so I wrote the
following code. It uses the performance counters which are high accuracy
hardware counters (3.6MHz on my 5 yr old laptop). If the counters are not
available, it falls back to the uncalibrated delay method. Seems to have a
~3us overhead on my laptop.

void bitbang_delay(int us)
{
#if defined(WIN32NATIVE)
static LARGE_INTEGER freq;
static enum {eNotInit, eInitOK, eInitFail}freqInit = eNotInit;

if(freqInit == eNotInit)
{
if(!QueryPerformanceFrequency(&freq))
freqInit = eInitFail; // perf counters not available
else
freqInit = eInitOK;
}

if(freqInit == eInitOK)
{
LARGE_INTEGER countNow, countEnd;
QueryPerformanceCounter(&countNow);
countEnd.QuadPart = countNow.QuadPart + freq.QuadPart * us / 1000000ll;

while (countNow.QuadPart < countEnd.QuadPart)
QueryPerformanceCounter(&countNow);
}
else // no performance counters -- run normal uncalibrated delay
{
volatile int del = us * delay_decrement;

while (del > 0)
del--;
}

#else
volatile int del = us * delay_decrement;

while (del > 0)
del--;
#endif /* WIN32NATIVE */
}

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/patch/?7010>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: Fwd: Win32 enhanced bitbang_delay

2009-12-02T01:24:53Z

As Doug Brown wrote:

> Could someone incorporate this into the SVN? I've got no idea how to, & I'm
> not on the dev team.

Please, file it as a patch under

https://savannah.nongnu.org/patch/?group=avrdude

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Fwd: Win32 enhanced bitbang_delay

2009-12-02T01:11:33Z

Hi avrdude dev,

I read that the bitbang_delay is not calibrated for Win32 so I wrote the
following code. It uses the performance counters which are high accuracy
hardware counters (3.6MHz on my 5 yr old laptop). If the counters are not
available, it falls back to the uncalibrated delay method. Seems to have a
~3us overhead on my laptop.

Could someone incorporate this into the SVN? I've got no idea how to, & I'm
not on the dev team.

Regards,
Doug.

void bitbang_delay(int us)
{
#if defined(WIN32NATIVE)
static LARGE_INTEGER freq;
static enum {eNotInit, eInitOK, eInitFail}freqInit = eNotInit;

if(freqInit == eNotInit)
{
if(!QueryPerformanceFrequency(&freq))
freqInit = eInitFail; // perf counters not available
else
freqInit = eInitOK;
}

if(freqInit == eInitOK)
{
LARGE_INTEGER countNow, countEnd;
QueryPerformanceCounter(&countNow);
countEnd.QuadPart = countNow.QuadPart + freq.QuadPart * us / 1000000ll;

while (countNow.QuadPart < countEnd.QuadPart)
QueryPerformanceCounter(&countNow);
}
else // no performance counters -- run normal uncalibrated delay
{
volatile int del = us * delay_decrement;

while (del > 0)
del--;
}

#else
volatile int del = us * delay_decrement;

while (del > 0)
del--;
#endif /* WIN32NATIVE */
}
_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Xmega/AVRispMkII reset bug fixed

2009-11-23T20:15:43Z

I'm working on a contract that currently involves build stuff around the
ATxmega16A4 chip, and so far have managed to bash a toolchain into
shape, but was having problems with avrdude requiring me to completely
disconnect the programmer from USB after every programming cycle, which
was getting rather obnoxious.

I compared the verbose avrdude output from the STK500 log generated by
AVRstudio, and on a hunch added one missing command, and voila! fixed.
Why that command has anything to do with hanging on 2nd program I have
no idea, but so far it's working repeatedly.

The fix is to call stk500v2_loadaddr(pgm,addr) just before the main
block write loop in stk600_xprog_paged_write(). I'd provide a diff, but
it's against 5.6 (which works, unlike 5.8 or svn...) and it's a trivial
change.

I will be filing a bug report with this information shortly.

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

[bug #28066] dragon_jtag and atxmega128A1 fails chip erase

2009-11-21T07:54:51Z

Follow-up Comment #1, bug #28066 (project avrdude):

Some more data

Added usb messages sniffed from AVR Studio 4.18 (b684) pressing the "erase
device" button; grouped by sequence numbers.

It seems to be an undocumented command, 0x34 (sequence number 0x17 in the usb
dump).

(file #19100)
_______________________________________________________

Additional Item Attachment:

File name: usb-dump-avrstudio.txt Size:0 KB

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28066>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

[bug #28066] dragon_jtag and atxmega128A1 fails chip erase

2009-11-20T15:19:43Z

URL:
<http://savannah.nongnu.org/bugs/?28066>

Summary: dragon_jtag and atxmega128A1 fails chip erase
Project: AVR Downloader/UploaDEr
Submitted by: None
Submitted on: Fri 20 Nov 2009 11:19:41 PM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Originator Name: Andreas
Originator Email: alohre@...
Open/Closed: Open
Discussion Lock: Any

_______________________________________________________

Details:

Programmer: dragon_jtag
Part: ATXMEGA128A1
avrdude svnrev: 879

commandline: avrdude -vvvvvv -c dragon_jtag -p x128a1 -P usb -e 2>
full-output.log

error message:
jtagmkII_chip_erase(): bad response to chip erase command:
RSP_ILLEGAL_COMMAND
For full output see attached logfile.

The dragon is running latest firmware, upgraded in AVR Studio 4.18 (b684) the
firmwareversion reported in the sign-on message is 6.04

_______________________________________________________

File Attachments:

-------------------------------------------------------
Date: Fri 20 Nov 2009 11:19:42 PM UTC Name: full-output.log Size: 30kB
By: None

<http://savannah.nongnu.org/bugs/download.php?file_id=19096>

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28066>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: dragon_jtag and atxmega128A1 fails on chip erase

2009-11-20T14:48:03Z

As Andreas Løhre wrote:

> When trying to erase and program the ATXMEGA128A1 with latest svn
> (rev. 879) using dragon_jtag:

I haven't been able to test a Dragon firmware that supports the Xmega.
Quite possible there are still bugs with that.

Please file a bug tracker for this.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: Re: jtagmkII_close(): bad response to GO command: RSP_ILLEGAL_EMULATOR_MODE

2009-11-20T14:47:09Z

As Shaun Jackman wrote:

> My target is the AT90PWM316, which supports ISP and DebugWire, but
> not JTAG. I believe I'm operating in ISP mode and not DebugWire
> mode. Shouldn't this command be supported in this configuration?

No, ISP mode doesn't know a "GO" command, because it is not a
debugging mode. It asserts /RESET all the time anyway, and as soon as
you leave ISP mode, the target is supposed to start, as /RESET is
being deasserted.

In contrast, the debugging modi (JTAG or debugWIRE) can arbitrarily
stop and resume CPU operation; the latter is what CMND_GO is intended
for.

The attempt to send a CMND_GO command even in ISP mode is a benign bug
that slipped in somehow in one of the recent releases.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Internal oscillator calibration

2009-11-20T13:56:58Z

I'm attempting to use the AVR JTAG ICE mkII to calibrate the internal
8 MHz oscillator of the AT90PWM316. I downloaded the source code that
runs on the target device from application note AVR0053 and compiled
it using the open source assembler avra. I flashed the target device
using avrdude and set its fuses to use the internal 8 MHz RC
oscillator (lfuse=0xa2). I then ran avrdude -O to start the
calibration, which is intended to store the result in EEPROM. However,
afterwards the EEPROM is still empty.

Has anyone successfully used the OSCCAL calibration routine specified
in AVR053 with avrdude?

The man page should mention that the target device requires special
firmware to be able to use the OSCCAL feature. The man page makes it
sound as though the programmer does it all automagically with no help
from the target.

Thanks,
Shaun

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

dragon_jtag and atxmega128A1 fails on chip erase

2009-11-20T13:52:32Z

Hello

When trying to erase and program the ATXMEGA128A1 with latest svn
(rev. 879) using dragon_jtag:
avrdude -vvvvv -c dragon_jtag -p x128a1 -P usb -e -U flash:w:testing.hex
it errs out with the error below.

There is no problem programming the part without the erase option.

avrdude: erasing chip
avrdude: jtagmkII_chip_erase(): Sending chip erase command:
avrdude: jtagmkII_send(): sending 1 bytes
avrdude: Sent: . [1b] . [16] . [00] . [01] . [00] . [00] . [00] . [0e]
. [13] . [a9] . [e2]
avrdude: jtagmkII_recv():
avrdude: Recv: . [1b]
avrdude: Recv: . [16]
avrdude: Recv: . [00]
avrdude: Recv: . [01]
avrdude: Recv: . [00]
avrdude: Recv: . [00]
avrdude: Recv: . [00]
avrdude: Recv: . [0e]
avrdude: Recv: . [aa]
avrdude: Recv: . [e3]
avrdude: Recv: . [ca]

avrdude: jtagmkII_recv(): Got message seqno 22 (command_sequence == 22)

Raw message:
0xaa
Illegal command

avrdude: jtagmkII_chip_erase(): bad response to chip erase command:
RSP_ILLEGAL_COMMAND
avrdude: jtagmkII_program_disable(): Sending leave progmode command:
avrdude: jtagmkII_send(): sending 1 bytes
avrdude: Sent: . [1b] . [17] . [00] . [01] . [00] . [00] . [00] . [0e]
. [15] [20] . [06]
avrdude: jtagmkII_recv():
avrdude: Recv: . [1b]
avrdude: Recv: . [17]
avrdude: Recv: . [00]
avrdude: Recv: . [01]
avrdude: Recv: . [00]
avrdude: Recv: . [00]
avrdude: Recv: . [00]
avrdude: Recv: . [0e]
avrdude: Recv: . [80]
avrdude: Recv: . [04]
avrdude: Recv: . [c5]

avrdude: jtagmkII_recv(): Got message seqno 23 (command_sequence == 23)

Raw message:
0x80
OK

Dragon info:

JTAG clock : 891.7 kHz (1.1 us)
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
boot-loader FW version: 255
firmware version: 6.04
hardware version: 1
S_MCU:
boot-loader FW version: 255
firmware version: 6.04
hardware version: 7
Serial number: 00:a2:00:00:77:21
Device ID: AVRDRAGON

.Andreas

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: jtagmkII_close(): bad response to GO command: RSP_ILLEGAL_EMULATOR_MODE

2009-11-20T13:47:45Z

2009/11/17 Shaun Jackman <sjackman@...>:
> I am using a Atmel JTAG ICE mkII with a AT90PWM316. Whenever avrdude
> exits, it prints the following error message:
>
> avrdude: jtagmkII_close(): bad response to GO command:

RSP_ILLEGAL_EMULATOR_MODE
The application note AVR067 says that

CMND_GO
RSP_ILLEGAL_EMULATOR_MODE
The operation cannot be performed in this emulator mode. (JTAG / DebugWire).

My target is the AT90PWM316, which supports ISP and DebugWire, but not
JTAG. I believe I'm operating in ISP mode and not DebugWire mode.
Shouldn't this command be supported in this configuration?

Cheers,
Shaun

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: jtagmkII_close(): bad response to GO command: RSP_ILLEGAL_EMULATOR_MODE

2009-11-17T10:46:48Z

Here's the verbose output:

$ avrdude -cjtag2isp -Pusb -ppwm316 -vvv
...
avrdude: jtagmkII_close()
avrdude: jtagmkII_close(): Sending GO command:
avrdude: jtagmkII_send(): sending 1 bytes
avrdude: jtagmkII_recv():
avrdude: jtagmkII_recv(): CRC OK
avrdude: jtagmkII_recv(): Got message seqno 0 (command_sequence == 0)

Illegal emulator mode

avrdude: jtagmkII_close(): bad response to GO command: RSP_ILLEGAL_EMULATOR_MODE
avrdude: jtagmkII_close(): Sending sign-off command:
avrdude: jtagmkII_send(): sending 1 bytes
avrdude: jtagmkII_recv():
avrdude: jtagmkII_recv(): CRC OK
avrdude: jtagmkII_recv(): Got message seqno 1 (command_sequence == 1)

OK

avrdude done. Thank you.

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

jtagmkII_close(): bad response to GO command: RSP_ILLEGAL_EMULATOR_MODE

2009-11-17T10:40:41Z

I am using a Atmel JTAG ICE mkII with a AT90PWM316. Whenever avrdude
exits, it prints the following error message:

avrdude: jtagmkII_close(): bad response to GO command: RSP_ILLEGAL_EMULATOR_MODE

I usually just ignore it. What does it mean, and can it be fixed?

Thanks,
Shaun

$ avrdude -cjtag2isp -Pusb -ppwm316

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.15s

avrdude: Device signature = 0x1e9483
avrdude: current erase-rewrite cycle count is -50463491 (if being tracked)

avrdude: safemode: Fuses OK
avrdude: jtagmkII_close(): bad response to GO command: RSP_ILLEGAL_EMULATOR_MODE

avrdude done. Thank you.

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

[bug #21797] AT90PWM316: New part description

2009-11-16T16:36:50Z

Follow-up Comment #1, bug #21797 (project avrdude):

Ping. Could this patch please be applied? It works for me.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?21797>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: USB

2009-11-16T06:01:09Z

Russell Shaw wrote:
> Joerg Wunsch wrote:
>> As Russell Shaw wrote:
>>
>>> Avrdude runs ok as root, but not as a normal user.
>>
>> Sure, device permission problems.

I got it working now. Directory permissions must have been wrong.
I did: sudo chmod -R +X /dev/bus

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: USB

2009-11-16T05:42:26Z

Joerg Wunsch wrote:

> As Russell Shaw wrote:
>
>> Avrdude runs ok as root, but not as a normal user.
>
> Sure, device permission problems.
>
>> This returns -1 and i can't figure out why.
>
> That's the way permission problems manifest under Linux: you can still
> open the USB device in libusb (apparently, this is done through
> something else than the actual device node), but it fails as soon as
> you try sending a message to it (which is needed in order to request a
> string descriptor entry from the device).
>
>> Just to make sure of things, i also tried:
>>
>> # chown -R root:avrdude /dev/usb*
>> # chown -R root:avrdude /dev/bus/usb
>> # chmod -R 660 /dev/usb*
>> # chmod -R 660 /dev/bus/usb
>
> Doesn't help. All these devices are created by your system
> dynamically. As soon as you say "Goodbye!" to the AVRISPmkII, it
> disconnects from and reconnects to the USB, and voila, you've got a
> new /dev/bus/usb/... entry -- again with the wrong permissions.

I did that temporarily while the device was plugged in to see
what effect it had. If that didn't work (which it didn't), then
no amount of udev rules will help either.

> Why do you insist on ignoring the udev hints that have been given to
> you?

I tried that as well as my own, and various combinations, but it
didn't work.

I currently have a udev rule:

SUBSYSTEMS=="usb", ATTRS{product}=="AVRISP mkII", GROUP="avrdude"

ls -l /dev/usb*

...
crw-rw---- 1 root avrdude 252, 17 2009-11-17 00:34 usbdev8.8_ep02
crw-rw---- 1 root avrdude 252, 18 2009-11-17 00:34 usbdev8.8_ep00
crw-rw---- 1 root avrdude 252, 16 2009-11-17 00:34 usbdev8.8_ep82

Works ok: sudo avrdude -p m8535 -c avrispmkII -P usb -U flash:w:proj.hex
Doesn't work: avrdude -p m8535 -c avrispmkII -P usb -U flash:w:proj.hex

avrdude: usb_open(): cannot read serial number "error sending control message:
Operation not permitted"
avrdude: usb_open(): cannot read product name "error sending control message:
Operation not permitted"
avrdude: usbdev_open(): error setting configuration 1: could not set config 1:
Operation not permitted
avrdude: usbdev_open(): did not find any USB device "usb"

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: USB

2009-11-16T05:19:20Z

Joerg Wunsch wrote:

Re: USB

2009-11-16T05:10:45Z

As Russell Shaw wrote:

> Avrdude runs ok as root, but not as a normal user.

Sure, device permission problems.

> This returns -1 and i can't figure out why.

That's the way permission problems manifest under Linux: you can still
open the USB device in libusb (apparently, this is done through
something else than the actual device node), but it fails as soon as
you try sending a message to it (which is needed in order to request a
string descriptor entry from the device).

> Just to make sure of things, i also tried:
>
> # chown -R root:avrdude /dev/usb*
> # chown -R root:avrdude /dev/bus/usb
> # chmod -R 660 /dev/usb*
> # chmod -R 660 /dev/bus/usb

Doesn't help. All these devices are created by your system
dynamically. As soon as you say "Goodbye!" to the AVRISPmkII, it
disconnects from and reconnects to the USB, and voila, you've got a
new /dev/bus/usb/... entry -- again with the wrong permissions.

Why do you insist on ignoring the udev hints that have been given to
you?

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: USB

2009-11-16T04:48:04Z

Joerg Wunsch wrote:

> As Russell Shaw wrote:
>
>> I just got a usb AVRISP. What permission should i fix?
>
> You need read/write permission.
>
> As these devices are created dynamically, you cannot do that with a
> plain chmod, but you have to consult your systems dynamic device
> facilitie's documentation. Most Linux systems use udev for that
> purpose, so you'd have to add another udev rule for the VID/PID pairs
> you are interested in.

Hi,
Avrdude runs ok as root, but not as a normal user.

I traced in to libusb:

(gdb) bt
#0 usb_control_msg (dev=0x82437a8, requesttype=128, request=6, value=768,
index=0, bytes=0xbfffd245 "\333", <incomplete sequence \373\267>, size=255,
timeout=1000) at ../linux.c:143

#1 0xb7fbeaea in usb_get_string (dev=0x82437a8, index=0, langid=0,
buf=0xbfffd245 "\333", <incomplete sequence \373\267>, buflen=255) at ../usb.c:226

#2 0xb7fbeb32 in usb_get_string_simple (dev=0x82437a8, index=3, buf=0xbfffd484
"\1", buflen=256) at ../usb.c:242

#3 0x08073d1d in usbdev_open (port=0xbffff985 "usb", baud=8452, fd=0x8099528)
at usb_libusb.c:117

#4 0x0806d95a in stk500v2_open (pgm=0x8098468, port=0xbffff985 "usb") at
stk500v2.c:1271

#5 0x0804b239 in main (argc=9, argv=0xbffff7c4) at main.c:778

usb.c:242

char tbuf[255]; /* Some devices choke on size > 255 */
...
ret = usb_get_string(dev, 0, 0, tbuf, sizeof(tbuf));

This returns -1 and i can't figure out why. The system hasn't
read anything out of /dev yet.

Just to make sure of things, i also tried:

# chown -R root:avrdude /dev/usb*
# chown -R root:avrdude /dev/bus/usb
# chmod -R 660 /dev/usb*
# chmod -R 660 /dev/bus/usb

and i'm in group avrdude. I have the avrisp plugged in.

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: USB

2009-11-16T01:46:40Z

On 11/16/2009 09:12 PM, Russell Shaw wrote:

> The udev rules are intended for modifying the files in /dev only.
> However, avrdude is reading stuff in /proc

According to your original post it's clearly accessing /dev:

> open("/dev/bus/usb/007/001", O_RDWR) = -1 EACCES (Permission denied)

Modifying udev rules should help.

Michal

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: USB

2009-11-16T00:58:11Z

On Mon, 2009-11-16 at 16:52 +1100, Russell Shaw wrote:

> Hi,
> I just got a usb AVRISP. What permission should i fix? :
>
> strace avrdude -p m8535 -c avrispmkII -P usb -v -U flash:w:proj.hex
>
> open("/dev/bus/usb/007/001", O_RDWR) = -1 EACCES (Permission denied)
> ...
>
> dev/bus/usb/007/001 exists, but i don't know what to do about the
> permissions in this part of the system (debian/unstable).
>
> ls -l /dev/bus/usb/007/001
> crw-rw-r-- 1 root root 189, 768 2009-11-16 16:15 /dev/bus/usb/007/001
>
>
> Avrdude 5.8
>
>

I created a new group called "isp" then added the following lines to
my /etc/udev/rules.d/91-permissions.rules

# AvrISP
SUBSYSTEM=="usb_device", GROUP="isp", \
ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2104"

With that any member of the group isp can access the avrisp2.

--
Ormund Williams
OrmLab LLC

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: USB

2009-11-16T00:12:56Z

Joerg Wunsch wrote:

Hi,
The udev rules are intended for modifying the files in /dev only.

However, avrdude is reading stuff in /proc, which has no way
of configuring the permissions of dynamically created files
from what i can see.

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: USB

2009-11-15T23:57:28Z

As Russell Shaw wrote:

> I just got a usb AVRISP. What permission should i fix?

You need read/write permission.

As these devices are created dynamically, you cannot do that with a
plain chmod, but you have to consult your systems dynamic device
facilitie's documentation. Most Linux systems use udev for that
purpose, so you'd have to add another udev rule for the VID/PID pairs
you are interested in.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

USB

2009-11-15T21:52:56Z

Hi,
I just got a usb AVRISP. What permission should i fix? :

strace avrdude -p m8535 -c avrispmkII -P usb -v -U flash:w:proj.hex

open("/dev/bus/usb/007/001", O_RDWR) = -1 EACCES (Permission denied)
...

dev/bus/usb/007/001 exists, but i don't know what to do about the
permissions in this part of the system (debian/unstable).

ls -l /dev/bus/usb/007/001
crw-rw-r-- 1 root root 189, 768 2009-11-16 16:15 /dev/bus/usb/007/001

Avrdude 5.8

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev

Re: Speeding up buspirate

2009-11-15T11:15:02Z

As Michal Ludvig wrote:

> I wanted to implement paged programming for buspirate but as far as
> I can tell that requires support on the programmer side, doesn't it?

At least, in order to help speed things up.

> Is there anything else I can do to speed things up? (apart from
> writing shorter code ;-)

Not without improving the programmer itself. FTDI ran into that some
years ago. They offer some generic bit-banging support, but together
with USB latencies and overhead, that is also pretty slow. In recent
chips, they added a kind of sophisticated hardware block that can be
completely programmed over USB (so it doesn't need to be fixed into a
single target programming architecture), yet allows to speed up things
like page programming by running that at hardware speed. (I didn't
really look into the details, so that's merely hearsay.) I'm afraid
without something like that, any kind of bit-banging beyond that that
could be done directly at some IO port of your computer will always be
very slow. (That's the reason why parallel-port attached simple
bit-bangers were so popular about 10 years ago when the AVR started to
gain its popularity.)

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
avrdude-dev@...
http://lists.nongnu.org/mailman/listinfo/avrdude-dev