[avrdude-dev] [bug #34027] avrdude AT90S1200 Problem

[Joerg Wunsch]

Update of bug #34027 (project avrdude):

                  Status:               Confirmed => In Progress            
             Assigned to:                    None => joerg_wunsch           

    _______________________________________________________

Follow-up Comment #3:

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.


    _______________________________________________________

Reply to this item at:

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

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