[bug #49082] avrdude 6.3 fails with AT90S8515

[avrs-admin]

dg1afg Tue 13 Sep 2016 05:46:32 PM UTC

I have problems programming old AT90S8515 with avrdude 6.3. It's impossible to program the controller. The output dialog as below. Reading the controller after programming shows every 2nd bit is $FF! avrdude 6.1 did work properly.

avrdude: Version 6.3
Copyright (c) 2000-2005 Brian Dean, [http://www.bdmicro.com/](https://savannah.nongnu.orghttp://www.bdmicro.com/)
Copyright (c) 2007-2014 Joerg Wunsch

System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/home/shack/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9301 (probably 8515)
avrdude: stk500isp_read_byte(): invalid operation AVR_OP_READ on fuse memory
avrdude: stk500isp_read_byte(): invalid operation AVR_OP_READ on fuse memory
avrdude: safemode: Fuse reading not support by programmer.
Safemode disabled.
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "DCF77.hex"
avrdude: input file DCF77.hex auto detected as Intel Hex
avrdude: writing flash (4932 bytes):

Writing | ################################################## | 100% 112.85s

avrdude: 4932 bytes of flash written
avrdude: verifying flash memory against DCF77.hex:
avrdude: load data flash data from input file DCF77.hex:
avrdude: input file DCF77.hex auto detected as Intel Hex
avrdude: input file DCF77.hex contains 4932 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 14.81s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0001
0xff != 0xc0

This issue was migrated from https://savannah.nongnu.org/bugs/?49082

[avrs-admin]

Joerg Wunsch Tue 13 Sep 2016 06:33:33 PM UTC

This appears to have been broken with the elimination of the old "ISP multi" command in SVN r1336.

[avrs-admin]

Lukas Raschendorfer Mon 27 Apr 2020 05:52:17 AM UTC

comment #1:

This appears to have been broken with the elimination of the old "ISP multi" command in SVN r1336.

Thanks for the tip, this is a solution for #58251 as well! See this bug also for a more detailed description of the problem.

[avrs-admin]

Joerg Wunsch Sun 07 Nov 2021 03:56:41 PM UTC

Not sure how to proceed on this. I wouldn't want to re-introduce the obsolete ISP_MULTI command.

What programmer hardware is that? Isn't it possible that the hardware be upgraded to support a more recent STK500 protocol?

[dl8dtl]

With the current code base, flash writes to AT908515 do not work at all (tried both, AVRISPmkII and STK500), and run into timeouts.

[mcuee]

Now the question is wether we want to keep supporting the first generation AT90S parts like AT90S8515 as they have been long obsolete.

[mcuee]

Looks like the following is the root cause. https://github.com/avrdudes/avrdude/issues/509#issuecomment-1238655829

This gets a bit complicated. The older AVRs that don't have paged flash used to have a single "write program memory" low-level ISP command where the low and high bytes of flash memory could be written individually. This was used up to v6.2 with the SPI_MULTI command (ISP passthrough). However, the STK500v2 protocol only offers CMD_PROGRAM_FLASH_ISP which assumes a prior CMD_LOAD_ADDRESS command to describe the address. For word-oriented flash, this address is a 16-bit word address though, so there's no option to individually address single (odd) bytes in flash that way. However, AVRDUDE can right now only distinguish between "paged mode" and "byte mode" - there is no 16-bit word mode at all inside.

[mcuee]

Help wanted from the community. PR is welcome.

[stefanrueger]

TLDR; -c usbtiny or -c usbasp should work for AT90S8515; if so, then I think I have a solution for stk500v2-based programmers. @mcuee could you test?

The long of it: Looks like ATtiny12 ATtiny15 AT90S1200 AT90S4414 AT90S2313 AT90S2333 AT90S2343 AT90S2323 ATtiny22 AT90S4433 AT90S4434 AT90S8515 AT90S8535 are all affected by this (those which have write_lo and write_hi flash commands, see avrdude -p*/St | grep write_lo). Using PR #1385 the dryrun programmer with debug messages tells us that the programmer's write_byte() routine is used, as it should in this case as these parts have no paged write:

$ avrdude_pr1385 -qvvv -cdryrun -p AT90S8515 -U flash:w:1,2,3,4,5:m
[...]
avrdude: processing -U flash:w:1,2,3,4,5:m  
avrdude: reading input file 1,2,3,4,5 for flash
         with 5 bytes in 1 section within [0, 4]
avrdude: writing 5 bytes flash ...
avrdude: dryrun_err_led(0)
avrdude: dryrun_write_byte(flash, 0x0000, 0x01)
avrdude: dryrun_write_byte(flash, 0x0001, 0x02)
avrdude: dryrun_write_byte(flash, 0x0002, 0x03)
avrdude: dryrun_write_byte(flash, 0x0003, 0x04)
avrdude: dryrun_write_byte(flash, 0x0004, 0x05)
avrdude: 5 bytes of flash written
avrdude: dryrun_vfy_led(1)
avrdude: verifying flash memory against 1,2,3,4,5
avrdude: reading on-chip flash data ...
avrdude: dryrun_read_byte(flash, 0x0000) returns 0x01
avrdude: dryrun_read_byte(flash, 0x0001) returns 0x02
avrdude: dryrun_read_byte(flash, 0x0002) returns 0x03
avrdude: dryrun_read_byte(flash, 0x0003) returns 0x04
avrdude: dryrun_read_byte(flash, 0x0004) returns 0x05
avrdude: verifying ...
avrdude: 5 bytes of flash verified
avrdude: dryrun_vfy_led(0)
avrdude: dryrun_disable()
avrdude: dryrun_rdy_led(0)
avrdude: dryrun_close()

avrdude done.  Thank you.

avrdude: dryrun_teardown()

Reading stk500v2.c's stk500isp_write_byte() routine I can confirm that it does not do the right thing for the parts mentioned above. However, I believe that the avr_write_byte_default() routine is old enough to work for these parts. Other ISP programmers that use avr_write_byte_default() should program these parts correctly. @mcuee could you try one of the programmers (grep avr_write_byte_def -rl src) with one of the parts above? So, for example usbtiny, usbasp or ft245-based programmers should do the trick. If these work, I predict the following change in stk500v2.c should rectify the problem at hand:

index 27c4de6e..c88397b8 100644
--- a/src/stk500v2.c
+++ b/src/stk500v2.c
@@ -1805,9 +1805,11 @@ static void stk500v2_enable(PROGRAMMER *pgm, const AVRPART *p) {
       stk600_setup_xprog(pgm);
     } else {
       stk600_setup_isp(pgm);
+      AVRMEM *mem = avr_locate_mem(p, "flash");
+      if(mem && mem->op[AVR_OP_WRITE_LO]) // Old part that can only write flash bytewise
+        pgm->write_byte = avr_write_byte_default;
     }
   }
   return;
 }

[mcuee]

@stefanrueger

Unfortunately I do not own any of the above-mentioned old parts. Maybe we have to wait for @MCUdude or @dl8dtl who has the ATtiny15 from the comments of #509.

There are three related issues.

• https://github.com/avrdudes/avrdude/issues/433

• 500

• 509

[mcuee]

These are all really old parts (obsoleted parts) and unfortunately my efforts to secure them failed (the vendor cancelled my order for ATtiny12/15 due to no stock). I will try my luck at others.

https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html](https://www.nongnu.org/avr-libc/user-manual/using_tools.html)

avr1
mcu = attiny11, attiny12, attiny15, attiny28, at90s1200 (no SRAM)

avr2
mcu = attiny22, attiny26, at90s2313, at90s2323, at90s2333, at90s2343, at90s4414, 
at90s4433, at90s4434, at90c8534, at90s8515, at90s8535

[stefanrueger]

no SRAM

How do these parts carry out subroutine calls or interrupts?

[mcuee]

no SRAM

How do these parts carry out subroutine calls or interrupts?

I am not familiar with these old parts but a quick glance of the datasheet seems to indicate they use a 3-level hardware stack for the above. https://media.digikey.com/pdf/Data%20Sheets/Atmel%20PDFs/ATtiny%2011_12%20Complete.pdf

Page 12: Subroutine and Interrupt Hardware Stack

The ATtiny11/12 uses a 3-level-deep hardware stack for subroutines and interrupts. The hardware stack is 9 bits wide and stores the program counter (PC) return address while subroutines and interrupts are executed.

RCALL instructions and interrupts push the PC return address onto stack level 0, and the data in the other stack levels 1-2 are pushed one level deeper in the stack. When a RET or RETI instruction is executed the returning PC is fetched from stack level 0, and the data in the other stack levels 1-2 are popped one level in the stack.

If more than three subsequent subroutine calls or interrupts are executed, the first values written to the stack are overwritten. Pushing four return addresses A1, A2, A3, and A4, followed by four subroutine or interrupt returns, will pop A4, A3, A2, and once more A2 from the hardware stack.

[MCUdude]

I can test with the ATtiny15 when I'm back home. Best case on Sunday if the jet lag isn't all that bad

[mcuee]

I can test with the ATtiny15 when I'm back home. Best case on Sunday if the jet lag isn't all that bad

@MCUdude

Please check whether terminal mode works or not.

Then please try #1386 using both CLI mode the terminal mode.

In #500, it is said that terminal mode may work.

• 500

[MCUdude]

I can read all memories in terminal mode and write to EEPROM. However, I can't write to flash using my AVRISPmkII in CLI or terminal. Tested with git main