[Uisp-dev] Re: [avr-gcc-list] uisp & stk500

[Theodore Roth]

Hi,

I've been digging into this. I was able to reproduce the problem Klaus
notes using my stk500 with an at90s1200 device. I narrowed it down to this
code:

Index: src/Stk500.C
===================================================================
RCS file: /cvsroot/uisp/uisp/src/Stk500.C,v
retrieving revision 1.8
diff -u -p -r1.8 Stk500.C
--- src/Stk500.C    3 Jun 2002 06:34:56 -0000   1.8
+++ src/Stk500.C    13 Jul 2002 00:15:24 -0000
@@ -304,7 +304,7 @@ void TStk500::FlushWriteBuffer(){
     memcpy(buf+sizeof(WriteMemory)+0x100,
        CmdStopByte, sizeof(CmdStopByte));
     Send(buf, sizeof(WriteMemory)+0x100+sizeof(CmdStopByte),
-     sizeof(WriteMemory_Reply));
+     sizeof(WriteMemory_Reply),10);
     if (memcmp(buf, WriteMemory_Reply, sizeof(WriteMemory_Reply)) != 0) {
       throw Error_Device ("Device is not responding correctly."); }
   }

The problem seems to be that the programming operation was timing out. I
bumped the timeout from 1 sec to 10 seconds and it started working.

The reason for the device not starting to run the newly downloaded program
was due to the exception getting thrown which quit uisp, but the device
was still doing the programming operation. Once the programming is
complete the stk500 replies to (the now dead) uisp and never exits
programming mode. Thus the stk500 firmware is hung. We should catch
exceptions when in programming mode and then cleanup before bombing out.

If extending the timeout to 10 seconds here is acceptable, I will commit
it to cvs. I've tested with a 1200, 8515 and mega128 with no regression.

Ted Roth


On Wed, 10 Jul 2002, Klaus Rudolph wrote:

:) Hi all,
:)
:) i have some problems using at90s1200 and at90s2313.
:)
:) In detail:
:)
:) programming the at90s1200 give allways after after executing
:) uisp -dprog=stk500 -dserial=/dev/ttyS0 -dpart=at90s1200 --upload -if=xxx
:)
:) output from uisp:
:) ...
:) Uploading Flash
:) Programmer is not responding
:) ...
:)
:) After that the device does not run. If i do a --verify after
:) that all is working and the verify is ok. The programmed flash
:) contains the correct data.
:)
:) This happens in parallel and serial programming!
:)
:)
:) Fuses:
:) Reading fuses from 1200 & 2323 fails. uisp try to read
:) 4 Bytes fuses (there are 4 Bytes ?) All
:) output values written as 0xff.
:) Is it maybe impossible to read the fuses?
:)
:) I am not able to programm the fuses :-(
:) Which set of fuses I have to use. I think that I
:) should be able to set the lock bits and also
:) the Internal Clock Enable of the 90s1200
:) but all that fails.
:)
:) Writing the lock bits give allways:
:) Writing lock bits failed: are you shure this device has lock bits?
:) Lock Bit set to: 0xxx
:) where 0xxxx is allways the value i have putted behind the
:) --wr_lock=0xxxx
:) But writing the lock to 0xfe makes the internal
:) oscilator not working :-(
:)
:) Any ideas?
:)
:) Bye
:)      Klaus
:) avr-gcc-list at http://avr1.org
:)