[bug #34027] avrdude AT90S1200 Problem

[avrs-admin]

kyriako Tue 16 Aug 2011 07:18:17 PM UTC

Hello avrdude, I wanted to use avrdude for programming older AVR types, especially AT90S1200. For testing the installation, I wrote a "blink test" program. Download:http://home.arcor.de/guentermeinel/div/blinktest.zip and tried two ISP-programmers:

1. avrispmkII: avrdude.exe -p 1200 -c avrispmkII -P usb -U flash:w:BlinkTest.hex:i -F
2. siprog: avrdude.exe -p 1200 -c siprog -P com1 -U flash:w:BlinkTest.hex:i -F

With both programmers, the same error occured: avrdude.exe: verifying ... avrdude.exe: verification error, first mismatch at byte 0x0017 0xcf != 0xc9 avrdude.exe: verification error; content mismatch

I don't have an avrdude version number, but the first line of the config file is:

$Id: avrdude.conf.in 916 2010-01-15 16:36:13Z joerg_wunsch $

Besides that, I have the impression that the program destroyed the device signature: avrdude.exe: Device signature = 0x009001 avrdude.exe: Expected signature for AT90S1200 is 1E 90 01

I tried three chips with the same result. Other chips, like AT90S2313 and ATtiny2313 were programmed correctly.

With "PonyProg2000", the AT90S1200-programming worked well. My OS is Windows XP. The libusb-driver installation is libusb-win32-bin-1.2.5.0

Regards Kyriako.

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

[avrs-admin]

Joerg Wunsch Tue 23 Aug 2011 09:20:22 PM UTC

I can confirm this for an AVRISPmkII programmer, but currently have no idea why it happens.  AT90S1200 devices are fairly rare these days, so while this must have been working some day in the past, it broke unnoticed till day.

Analysis will take some time.

[avrs-admin]

Joerg Wunsch Sat 27 Aug 2011 10:25:15 PM UTC

The problem appears to be the specific AT90S1200 requirements after a chip erase operation.  The datasheet says:

3. If a Chip Erase is performed (must be done to erase the Flash), wait tWD_ERASE after the instruction, give RESET a positive pulse, and start over from step 2. [...]

The latter is attempted by calling pgm->initialize again after the chip erase, but that (obviously) doesn't relly release the /RESET line as mandated by the datasheet.

As a workaround, separate the "chip erase" and "program device" steps as follows:

. First, call AVRDUDE with the -e option to perform the chip erase operation.

. Then, perform the actual programming using the -D option to prevent AVRDUDE from executing the implied chip erase.

As already explained in a private email, accidentally erasing or manipulating the signature bytes on the AT90S1200 could easily happen. Use the -F option to override the signature check.

[avrs-admin]

Joerg Wunsch Mon 29 Aug 2011 09:45:10 AM UTC

Things are pretty mysterious with this ancient device.

The analysis from comment #2 applies to modern programmers (like the AVRISPmkII) which apparently nobody has ever been testing with an AT90S1200 before.

Bitbang programmers, however, have been in extensive use back in the days of the AT90S1200, and they used to work with AVRDUDE quite fine. Now, there are programming failures where the high byte of a particular cell always has more bits written than desired.  Reducing the ISP speed (way below the allowable one!) remedies the situation, but as the logic analyzer shows no glitches or other time-dependent signal distortions, this could not be the solution.  (The logic analyzer traces reflect the -vvvv data 100 %.)

The failure always happens in a pattern like this:

001: bitbang_cmd(): [ 20 00 0B 00 ] [ 00 20 01 FF ] 002: bitbang_cmd(): [ 40 00 0B F9 ] [ 00 40 00 0B ] 003: bitbang_cmd(): [ 20 00 0B 00 ] [ F9 20 01 FF ] 004: bitbang_cmd(): [ 20 00 0B 00 ] [ 00 20 01 F9 ] 005: bitbang_cmd(): [ 28 00 0B 00 ] [ 00 28 01 F9 ] 006: bitbang_cmd(): [ 48 00 0B CF ] [ 00 48 00 0B ] 007: bitbang_cmd(): [ 28 00 0B 00 ] [ CF 28 01 FF ] 008: bitbang_cmd(): [ 28 00 0B 00 ] [ 00 28 01 C9 ] 009: bitbang_cmd(): [ 28 00 0B 00 ] [ 00 28 01 C9 ] 010: bitbang_cmd(): [ 28 00 0B 00 ] [ 00 28 01 C9 ] 011: bitbang_cmd(): [ 28 00 0B 00 ] [ 00 28 01 C9 ] 012: bitbang_cmd(): [ 28 00 0B 00 ] [ 00 28 01 C9 ]

In line 1, the low byte of cell 0x0b (i.e. address 0x16) is tested, and yields 0xff (erased).  Then (line 2), this byte is written to 0xF9, and polled (lines 3 and 4) until it returns 0xF9.

In line 5, the high byte of cell 0x0b (address 0x17) is tested (to see whether it already contains the desired value), and this byte is returned as 0xf9 rather than the expected 0xff for an erased byte. Subsequently (line 6), it is attempted to be programmed to 0xcf, and the result of the write operation is polled (lines 7 through 12 and beyond).  While line 7 still shows it as 0xff (erased), all further polls yield the ANDed value between the 0xf9 from the low byte, and the 0xcf from the desired high byte = 0xc9.  I have no idea why that happens, but leaving out the pre-write test avoids that problem, so I implemented a respective workaround for the AT90S1200.

Part 2 of the problem, the requirement to release /RESET after a chip erase for non-bitbang programmers, has not been fixed yet, but the current SVN version should make it work with bitbang programmers again.

[avrs-admin]

Joerg Wunsch Tue 30 Aug 2011 07:32:18 AM UTC

The stk500v2 part (which affects the AVRISPmkII) has been fixed in r1004.  By that, both programmer types mentioned in the bug report are fixed now.

Other programmer types probably still suffer from this.  Given the relatively low importance of the AT90S1200 these days, and the amount of work to spend in implementing and testing this for each of these programmers, unless there are volunteers to do this work, I'll rather defer that job until someone really pops up who wants to use yet another programmer with an AT90S1200.

The documentation has been updated to mention the programmer type restrictions that apply to the AT90S1200.