bugAVR Downloader/UploaDEr - Bugs: bug #34027, avrdude AT90S1200 Problem

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #34027: avrdude AT90S1200 Problem

Submitted by:  Günter Meinel <kyriako>
Submitted on:  Tue 16 Aug 2011 07:18:17 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: FixedPrivacy: Public
Assigned to: Joerg Wunsch <joerg_wunsch>Originator Name: kyriako
Open/Closed: ClosedRelease: None
Programmer hardware: Device type: 

Tue 30 Aug 2011 07:32:18 AM UTC, comment #4:

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.

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Mon 29 Aug 2011 09:45:10 AM UTC, 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.

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Sat 27 Aug 2011 10:25:15 PM UTC, comment #2:

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.

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Tue 23 Aug 2011 09:20:22 PM UTC, comment #1:

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.

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Tue 16 Aug 2011 07:18:17 PM UTC, original submission:

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.

Günter Meinel <kyriako>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by joerg_wunsch (Posted a comment)
  • -unavailable- added by kyriako (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 30 Aug 2011 07:32:18 AM UTCjoerg_wunschStatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Mon 29 Aug 2011 09:45:10 AM UTCjoerg_wunschStatusConfirmed=>In Progress
      Assigned toNone=>joerg_wunsch
    Tue 23 Aug 2011 09:20:22 PM UTCjoerg_wunschStatusNone=>Confirmed

    Back to the top


    Powered by Savane 3.1-cleanup1