attiny441/841 not working in Studio 6.1 or 6.2

Go To Last Post
25 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I am trying to install Attiny441/841 support in AVR Studio, but with no sucess.
In the "device prorgamming" window, the target attiny 441 or attiny 841 still does not appear.

Has anyone succeeded to install with recent versions ?

What I did was install AVR studio 6.1, install GCC ttolchain update, and Device Support Package for ATtiny441 and ATtiny841.
I followed explanations as shown here:
http://www.atmel.com/tools/atmel...

I tried also with AVR Studio 6.2, but same result

Any idea ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have the standard AS6.2beta installation.
I can select ATtiny441/841 as Device in my GCC project.
Likewise, I can select ATtiny441/841 as Device in my CodeVision project.

I don't own either chip. So I have never used the generated code.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your help,
I found the reason,
my programming tool based on STK500 is not supported by attiny 441/841.
That's why it does not appear in the list of devices.
grrr...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That does not matter. You can do the programming with avrdude or other third party software.
Or if you have a genuine STK500, add the XML entry. Then AS6.2 should program the chip.

Explain exactly what hardware you have.
Explain what you want to do.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure if the *41 actually works on the 500 (basically, that's why it's not in the supported list). If enough people get it to work, then I might be able to add it into the supported list for a later release. The required xml is in /tools/stk500/xml , and the easiest way to make them is just to copy one similar device and modify the device name in the xml content (2 entries ish?).

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have an AVRISP programmer from Olimex.
With AtmegaXX MCUs, I used to flash with avrdude, it is so easy and automatic by command line. Doing the same way with attiny441 would be great !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So what you are really asking about is tiny*41 support in avrdude and an avrisp clone?

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrdude source is here:

http://svn.savannah.nongnu.org/v...

If you search:

http://svn.savannah.nongnu.org/v...

You will find that "attiny441" does not appear. So, no, there is no official support yet in avrdude for tiny441 (or 841).

(avrdude has nothing to do with Atmel apart from the fact that it happens to program their chips).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

can you suggest any other tool (atmel or not) that can run from cygwin command line ( no mouse click please) to flash an attiny 411 ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No avrdude would be the usual choice. For devices that are not yet supported it's usually possible to edit avrdude.conf and find the device description for a similar existing part then copy that and change the name, signature bytes and so on. Having done that avrdude should then work for the part as long as it uses the same programming mechanism as the existing part you copied.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Someone have posted an avrdude.conf entry for the tiny841 in the AVR forum. I have used it without any problems.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it's me again, figthing with avrdude 6.1.
I can't succeed to compile it under cygwin, i always get errors related to "dfu.c" file. I tried install to libusb (obsolete), the libusb version 1, both, one only, but it sill block at compilation on usb related stuff.

My last configure says:


Configuration summary:
----------------------
DON'T HAVE libelf
DON'T HAVE libusb
DO HAVE libusb_1_0
DON'T HAVE libftdi1
DON'T HAVE libftdi
DON'T HAVE libhid
DO HAVE pthread
DISABLED doc
ENABLED parport
DISABLED linuxgpio

compilation error:


make[2]: Entering directory '/cygdrive/c/avrdude-6.1'
gcc -DHAVE_CONFIG_H -I. -DCONFIG_DIR=\"/cygdrive/c/avrdude//bin\" -Wall -Wno-pointer-sign -g -O2 -DWIN32NATIVE -MT libavrdude_a-dfu.o -MD -MP -MF .deps/libavrdude_a-dfu.Tpo -c -o libavrdude_a-dfu.o `test -f 'dfu.c' || echo './'`dfu.c
dfu.c:39:5: error: conflicting types for ‘dfu_open’
int dfu_open(struct dfu_dev *dfu, char *port_name) {
^
In file included from dfu.c:22:0:
dfu.h:117:25: note: previous declaration of ‘dfu_open’ was here
extern struct dfu_dev * dfu_open(char *port_spec);
^
dfu.c:45:5: error: conflicting types for ‘dfu_init’
int dfu_init(struct dfu_dev *dfu, unsigned short usb_pid) {
^
In file included from dfu.c:22:0:
dfu.h:118:12: note: previous declaration of ‘dfu_init’ was here
extern int dfu_init(struct dfu_dev *dfu,
^
Makefile:978: recipe for target 'libavrdude_a-dfu.o' failed
make[2]: *** [libavrdude_a-dfu.o] Error 1
make[2]: Leaving directory '/cygdrive/c/avrdude-6.1'
Makefile:1516: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/cygdrive/c/avrdude-6.1'
Makefile:598: recipe for target 'all' failed
make: *** [all] Error 2

HAVE_LIBUSB is not define. If I force it I get new errors.

Any hint to workaround the problem ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well that looks like a real C problem rather than just a build issue. If you look at the .h file are there variant interfaces for dfu_init based on conditional macros. Otherwise it's true that the .h says one thing and the .c says another.

Did you pull your image of the code at a release label or HEAD? If the latter I guess someone may have simply checked in a build error.

EDIT: OK now I'm confused. I just looked at HEAD. the .h file has:

http://svn.savannah.nongnu.org/viewvc/trunk/avrdude/dfu.h?annotate=1268&...
(see line 118-119)

and the .c file has:

http://svn.savannah.nongnu.org/viewvc/trunk/avrdude/dfu.c?annotate=1275&...
(line 45 if no HAVE_LIBUSB, line 156 when it is defined)

Both the header and the C have the same "int" return type. So I can only conclude you have some outdated source tree?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I pulled a stable version, was a TGZ file (not zip file). AFAIR i tried also with avrdude 6.2 git and got same error.

Last Edited: Thu. May 1, 2014 - 10:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wait a minute. I see what it is. The latest dfu.h has this:

extern struct dfu_dev * dfu_open(char *port_spec);
extern int dfu_init(struct dfu_dev *dfu,
unsigned short vid, unsigned short pid);

that's two separate functions: dfu_open() and dfu_init(). Now consider what happens if the cursor was placed at the start of the word dfu_init and the cat stood on the [Backspace] key on your keyboard:

extern struct dfu_dev * dfu_init(struct dfu_dev *dfu,
unsigned short vid, unsigned short pid);

You'd now have a dfu_init that was documented as returning a pointer to a dfu_dev struct.

Methinks your copy of dfu_h has been corrupted.

EDIT: no it's not that. You are getting errors that seem to suggest the return types of dfu_open() and dfu_init() have been EXCHANGED?!?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Right, ignore all that, there is an error in dfu.c. It effectively says:

#ifndef HAVE_LIBUSB

int dfu_open(struct dfu_dev *dfu, char *port_name) {
...
}

int dfu_init(struct dfu_dev *dfu, unsigned short usb_pid) {
...
}

#else

struct dfu_dev * dfu_open(char *port_spec)
{
...
}

int dfu_init(struct dfu_dev *dfu, unsigned short vid, unsigned short pid)
{
...
}
#endif

and the .h file has:

extern struct dfu_dev * dfu_open(char *port_spec);

extern int dfu_init(struct dfu_dev *dfu,
unsigned short vid, unsigned short pid);

the .h matches the .c for the HAVE_LIBUSB case but not for when it's not defined.

My guess is that at one point in time they matched but then the active case was changed and the .h to match but no one updated the !HAVE_LIBUSB case.

I'd report this as an error to the avrdude maintainers.

(I'm guessing they assume that everyone just builds the HAVE_LIBUSB case)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

HAVE_LIBUSB should have been set by configure. In this case, i have only installed libusb version 1 under cygwin.
But i have trie also with libusb (obsolete) and no v 1.0, and still get errors at compilation.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

HAVE_LIBUSB should have been set by configure

Clearly it wasn't - you can always check by putting a #error in the code where it's expected to be defined.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is the error I get if I force HAVE_LIBUSB in dfu.c:


gcc -DHAVE_CONFIG_H -I. -DCONFIG_DIR=\"/cygdrive/c/avrdude//bin\" -Wall -Wno-pointer-sign -g -O2 -DWIN32NATIVE -MT libavrdude_a-dfu.o -MD -MP -MF .deps/libavrdude_a-dfu.Tpo -c -o libavrdude_a-dfu.o `test -f 'dfu.c' || echo './'`dfu.c
dfu.c:96:30: error: unknown type name ‘usb_dev_handle’
static char * get_usb_string(usb_dev_handle * dev_handle, int index);
^
dfu.c: In function ‘dfu_open’:
dfu.c:144:6: error: ‘struct dfu_dev’ has no member named ‘bus_name’
dfu->bus_name = bus_name;
^
dfu.c:145:6: error: ‘struct dfu_dev’ has no member named ‘dev_name’
dfu->dev_name = dev_name;
^
dfu.c:146:6: error: ‘struct dfu_dev’ has no member named ‘timeout’
dfu->timeout = DFU_TIMEOUT;

^
...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Here is the error I get if I force HAVE_LIBUSB in dfu.c:

Yeah but that is then complaining about "usb_dev_handle" which I rather suspect is defined in libusb.h. Just saying you HAVE_LIBUSB when you don't isn't going to make things like this magically work.

I imagine the conf predicates HAVE_LIBUSB on the existence pf /usr/include/libusb.h or something like that. If libusb is not properly installed the file won't exist and that's why it's not finding the definition.

If I were you I think I'd look at how to resolve this:

DON'T HAVE libusb 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is the result with libusb installed:


gcc -DHAVE_CONFIG_H -I. -DCONFIG_DIR=\"/cygdrive/c/avrdude//bin\" -Wall -Wno-pointer-sign -g -O2 -DWIN32NATIVE -MT libavrdude_a-dfu.o -MD -MP -MF .deps/libavrdude_a-dfu.Tpo -c -o libavrdude_a-dfu.o `test -f 'dfu.c' || echo './'`dfu.c
In file included from /usr/include/w32api/oleidl.h:7:0,
from /usr/include/w32api/ole2.h:38,
from /usr/include/w32api/wtypes.h:12,
from /usr/include/w32api/winscard.h:10,
from /usr/include/w32api/windows.h:97,
from avrdude.h:34,
from dfu.c:24:
dfu.c: In function ‘dfu_init’:
dfu.c:231:18: error: expected identifier before ‘struct’
dfu->conf_desc.interface = NULL;
^
dfu.c:233:42: error: expected identifier before ‘struct’
memcpy(&dfu->intf_desc, found->config->interface->altsetting,
...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found i way to workaround the problem, using libusb0 library, I just added "#undef interface" before line 231 in dfu.c.
Now at least it compiles this files and all next ones.


memcpy(&dfu->dev_desc, &found->descriptor, sizeof(dfu->dev_desc));
memcpy(&dfu->conf_desc, found->config, sizeof(dfu->conf_desc));
dfu->conf_desc.MaxPower = 0;
#undef interface
dfu->conf_desc.interface = NULL;

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't get studio6.2 to connect to a tiny441 in debug wire mode using an Atmel-ICE. I have replaced the device a couple of times. ST6 connects o.k. with SPI interface. I set the debug wire enable fuse and check lock bits are off and program. I power cycle the target and change the interface on ST6 to debugwire and try to start debugging and get the following error message "An ongoing operation is taking longer than expected. Details: Tool->setProperties." I have downloaded and installed the latest ICE firmware. 

The code is a simple test loop and builds without problems. Suggestions please!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Has anybody succeeded in using the tiny441 debug wire? I compiled a simple test project in AS6.2, can access the fuses but I am unable to start a debug session using either my JTAG ICE II or the new Atmel ICE. In both cases I get "An ongoing operation is taking longer than expected. Details: Tool->setProperties". It doesn't even get as far as toggling the reset line.

 

I tried using my trusty AS4 but it doesn't recognise the device, is there a way to add this device to the AS4 list?

Any help much appreciated.

 

Incidently, AS6.2 has given me a huge headache with 'Access Denied' failure messages during a compile, turned out to be an antivirus scanner problem on the temporary make file, so I have to turn off the antivirus to be able to compile, not clever!