[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ludovic COURTES
Subject: [avr-gcc-list] Troubles uploading to a Mega103
Date: Tue, 27 Mar 2001 11:32:54 +0200
User-agent: Mutt/1.2.5i


I recently probed new home-made PCBs featuring a ATMega103 and I am having
troubles uploading to it. I use Uisp latest tarball (uisp-20010211.tar.gz)
with Dapa protocol.

Here is the problem : we managed to perform only one successful upload (the
first one) and now the MCU behaves just as if it was locked (lock bits set
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 and
here is what i got :

[leo ~/tmp/uisp-20010211/src]$ uisp -dapa --verify 
if=~/unitec/code_avr/board_test/tiny_prg.srec  -dt_wd_flash=80000
send(recv): AC(FF) 53(FF) 00(53) 00(00) 
send(recv): 30(00) 00(30) 00(00) 00(FF) 
send(recv): 30(00) 00(30) 01(00) 00(FF) 
send(recv): 30(00) 00(30) 02(00) 00(FF) 
An error has occurred durring the AVR initilization.
 * Target status:
   Vendor Code = 0xff, Part Family = 0xff, Part Number = 0xff
Probably the wiring is incorrect or target might be `damaged'.
[leo ~/tmp/uisp-20010211/src]$ uisp -dapa --verify 
if=~/unitec/code_avr/board_test/tiny_prg.srec  -dt_wd_flash=80000
send(recv): AC(01) 53(AC) 00(53) 00(00) 
send(recv): 30(00) 00(30) 00(00) 00(00) 
send(recv): 30(00) 00(30) 01(00) 00(01) 
send(recv): 30(00) 00(30) 02(00) 00(02) 
Cannot identify device because is it locked.
Verifying: flash
Segmentation fault

As you can see, the 'Enable Programming' command (0xAC530000) works fine,
but then, the signature bytes are wrong. Moreover, the strange thing is that
it first time (after power-up) it returns 0xFFFFFF as its signature bytes
and then, if we don't switch it off, it always returns 0x000102...
BTW, note that uisp continues even if device is locked and then crashes... ;)

Well, if someone has already had this kind of problem, i would be glad
to know more about it !


Ludovic Courtès
  Université de Technologie de Belfort-Montbéliard
  Unitec (Club de Robotique de l'UTBM)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]