kcuzner / avrdude Goto Github PK

"My initial thought was to use the chip select as the reset output, but sadly, the documentation for the SPI functions mentioned that the chip enable line is only held low so long as the transaction is going."

While that is correct, I don't believe that this is accomplished in the hardware but in the spi driver spidev.c, hence amenable.

I will poke around myself but I just wanted to share the lead in case someone was interested.

Great avrdude patch by the way!

Hi

Would you be willing to include a fix for a cross-compilation issue that was raised on the main avrdude bugtracker: http://savannah.nongnu.org/bugs/?37489 ?

It's a small fix to configure.ac. See the diff here: http://svn.savannah.nongnu.org/viewvc/trunk/avrdude/configure.ac?root=avrdude&r1=1180&r2=1214

I've tried it and it works for me.

Cheers,
-Dan

In some configurations, IE 3.3V clock 8/8 the 500Khz is too mutch, the baud parameter (-b) might be usefull to set a diferent speed (the above configurations will work at 50Khz), if 50Khz still work with other configurations, maybe the default should be lower to avoid conflicts.

You've done quite a bit of improvements, so for others to follow, we may consider cleaning up the repo a bit, by removing old logs, and outdated/ not used text files and move them into some folder. adding a license file is also essential.

Hello,

Can you please implement a loopback test function that can test the programmer hardware if the MISO and MOSI lines are shorted?

Thanks

ps: I'm using usbtiny

I would like to attach multiple ATMEL uC to a single SPI at the same time. Therefore it is necessary to support a reset GPIO pin for every uC.

Can you please provide me an hint how we can use the "x" option (Pass <extended_param> to programmer.) to the linuxspi programmer.

Maybe this helps:
#3
5a4716e

Thanks.

If using --enable-linuxgpio the ./configure script does:
$as_echo "#define HAVE_LINUXGPIO 1" >>confdefs.h

In spidev.c you use HAVE_LINUX_GPIO. One of them is wrong.

Hi, I tried to write hfuse and lfuse, and it seems like there are something weird with mac version of avrdude.

It recognize H and L fuse in a way I could not understand. Do you mind if explain it a little bit please? "(H:DA, E:05, L:FF)" with "-Uhfuse:w:0x05:m -Uefuse:w:0xda:m -Ulfuse:w:0xff:m"

client-104-39-67-216:bootloader WenhuiZhang$ avrdude -p m2560 -c usbasp -P /dev/ttyUSB0 -B 115200 -Uhfuse:w:0x05:m  -Uefuse:w:0xda:m  -Ulfuse:w:0xff:m

avrdude: set SCK frequency to 0 Hz
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9801
avrdude: reading input file "0x05"
avrdude: writing hfuse (1 bytes):

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

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

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

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

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

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

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

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

avrdude: safemode: efuse changed! Was da, and is now fa
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK (H:DA, E:05, L:FF)

avrdude done.  Thank you.

There is an issue posted on the avr-dev mailing list

http://lists.gnu.org/archive/html/avrdude-dev/2013-11/msg00018.html

but I am still trying to figure where the fixed files are posted because I can't find them in the open yet...

Hi,
Sorry for the dumb question. I'd like to use this version of avrdude but I am not sure how to compile it. I tried using automake but it gave me a load of errors:

configure.ac: error: no proper invocation of AM_INIT_AUTOMAKE was found.
configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE,
configure.ac: that aclocal.m4 is present in the top-level directory,
configure.ac: and that aclocal.m4 was recently regenerated (using aclocal)
configure.ac:28: error: required file './config.guess' not found
configure.ac:28:   'automake --add-missing' can install 'config.guess'
configure.ac:28: error: required file './config.sub' not found
configure.ac:28:   'automake --add-missing' can install 'config.sub'
configure.ac:38: error: required file './install-sh' not found
configure.ac:38:   'automake --add-missing' can install 'install-sh'
Makefile.am: error: required file './INSTALL' not found
Makefile.am:   'automake --add-missing' can install 'INSTALL'
configure.ac:34: error: required file 'ac_cfg.h.in' not found
Makefile.am: error: required file './depcomp' not found
Makefile.am:   'automake --add-missing' can install 'depcomp'
/usr/share/automake-1.16/am/depend2.am: error: am__fastdepCC does not appear in AM_CONDITIONAL
/usr/share/automake-1.16/am/depend2.am:   The usual way to define 'am__fastdepCC' is to add 'AC_PROG_CC'
/usr/share/automake-1.16/am/depend2.am:   to 'configure.ac' and run 'aclocal' and 'autoconf' again
/usr/share/automake-1.16/am/depend2.am: error: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.16/am/depend2.am:   The usual way to define 'AMDEP' is to add one of the compiler tests
/usr/share/automake-1.16/am/depend2.am:     AC_PROG_CC, AC_PROG_CXX, AC_PROG_OBJC, AC_PROG_OBJCXX,
/usr/share/automake-1.16/am/depend2.am:     AM_PROG_AS, AM_PROG_GCJ, AM_PROG_UPC
/usr/share/automake-1.16/am/depend2.am:   to 'configure.ac' and run 'aclocal' and 'autoconf' again
configure.ac: error: required file './ylwrap' not found
configure.ac:   'automake --add-missing' can install 'ylwrap'
doc/Makefile.am:33: error: required file 'doc/mdate-sh' not found
doc/Makefile.am:33:   'automake --add-missing' can install 'mdate-sh'
doc/Makefile.am:33: error: required file 'doc/texinfo.tex' not found
doc/Makefile.am:33:   'automake --add-missing' can install 'texinfo.tex'

When using avrdude linuxspi together with other programs which use spidev
avrdude fails if the other program sets a different spi mode.

I'm no expert on spidev but from what I've seen here SPI_IOC_WR_MODE and SPI_IOC_RD_MODE should be set before sending the message.

On the 2016-03-18 version of Raspbian (Jessie), ownership of the files in /sys/class/gpio are set dynamically in /etc/udev/rules.d/99-com.rules:
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio ...
However, the linuxspi driver, when running avrdude as non-root, sometimes tries to open the files before the permissions have been changed.

Suggested fix: If a file open in linuxspi_gpio_op_wr fails, wait a bit and try again, such as:

*** linuxspi-orig.c 2016-04-03 08:38:00.385085898 -0700
--- linuxspi.c 2016-04-03 08:15:27.283272150 -0700

*** 168,173 ****
--- 168,180 ----
FILE* f = fopen(fn, "w");
if (!f)
{

•     fprintf(stderr, "%s: linuxspi_gpio_op_wr(): Unable to open %s - retry", progname, fn);
  

•     sleep(2);
  

•     f = fopen(fn, "w");
  

• }
  

• if (!f)
  

• {
    fprintf(stderr, "%s: linuxspi_gpio_op_wr(): Unable to open file %s", progname, fn);
    free(fn); //we no longer need the path
    return -1;
  

I have had trouble programming fresh attiny85 chips using a Raspberry Pi 3 with a recent image and kernel. Interestingly, a pre-programmed board can be re-flashed but a new one can't be flashed.

I hooked a logic analyser up to an Arduino ISP and found that it uses an SPI clock speed of 125KHz instead of 400KHz. Setting the speed to 125KHz in avrdude.conf on the Pi fixed the issue for me. Perhaps 125KHz is a better default?