[avr-gcc-list] RE: Troubles uploading to a Mega103

[Heinrich Vermeulen]

Greetings Ludovic

You wrote -
"I use Uisp latest tarball (uisp-20010211.tar.gz= )with Dapa protocol.
Here is the problem : we managed to perform only one successful upload (t=
he first one) and now the MCU behaves just as if it was locked (lock bits
se=
t to 0). But when we try to erase it (uisp -dapa --erase), it still remains
locked (i.e. the MCU just send back the bytes sent by uisp - for instance=
,when uisp sends the command to get its signature bytes, it just responds =
by sending 00, 01 and 02 instead of its signature).
So i compiled uisp with the -DDEBUG flag just to see what was going on an=
d here is what i got :
send(recv): AC(FF) 53(FF) 00(53) 00(00)=20
send(recv): 30(00) 00(30) 00(00) 00(FF)=20
send(recv): 30(00) 00(30) 01(00) 00(FF)=20
send(recv): 30(00) 00(30) 02(00) 00(FF)=20
An error has occurred durring the AVR initilization.
 * Target status:
   Vendor Code =3D 0xff, Part Family =3D 0xff, Part Number =3D 0xff
"

We had the same problem with both the signature bytes being 1)FF FF FF and
being 2)00 01 02:
1)The ATMega103 loses its signature bytes for some reason after a few
erase/program cycles.  The workaround is to change the UISP code.  I made a
couple of changes already to the software already to accomodate these
defects (also to read/write fuse bits, correcting srec format downloads,
etc.).  I can give you or anyone else this code if you so wish.

2)Are you holding in the reset line using an external reset while you are
talking to the ATMega103?  If the external reset is kept LOW the signature
bytes will be FF FF FF when a
"uisp -dapa" command is performed but after that the signature bytes will be
00 01 02 when a
"uisp -dapa" command is performed.  Make sure the reset line is not
externally made LOW when the UISP talks to it.

Heinrich Vermeulen
Prism Secure Solutions
address@hidden
+27 12 663 8501