Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug #50261] JTAG1 unable to write fuse and lock bits #443

Closed
avrs-admin opened this issue Dec 11, 2021 · 12 comments · Fixed by #1031
Closed

[bug #50261] JTAG1 unable to write fuse and lock bits #443

avrs-admin opened this issue Dec 11, 2021 · 12 comments · Fixed by #1031
Labels
bug Something isn't working

Comments

@avrs-admin
Copy link

Stefan Mavrodiev stefan.mavrodiev@gmail.com
Thu 09 Feb 2017 09:40:51 AM UTC

Hello,

I'm using AVR-JTAG-USB from Olimex, witch is clone to AVR-JTAGICE.
I was unable to write fuses and lock bits.

$ avrdude -c jtag1 -p c128 -P /dev/ttyUSB0 -b19200 -U lfuse:w:0xCF:m

avrdude: jtagmkI_initialize(): warning: OCDEN fuse not programmed, single-byte EEPROM updates not possible
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9781 (probably c128)
avrdude: reading input file "0xCF"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xCF:
avrdude: load data lfuse data from input file 0xCF:
avrdude: input file 0xCF contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading |                                                    | 0% 0.00savrdude: jtagmkI_read_byte(): timeout/error communicating with programmer (resp )
avr_read(): error reading address 0x0000
read operation not supported for memory "lfuse"
avrdude: failed to read all of lfuse memory, rc=-2

avrdude: jtagmkI_read_byte(): timeout/error communicating with programmer (resp )
avrdude: jtagmkI_read_byte(): timeout/error communicating with programmer (resp )
avrdude: jtagmkI_read_byte(): timeout/error communicating with programmer (resp )
avrdude: jtagmkI_read_byte(): timeout/error communicating with programmer (resp )
avrdude: safemode: Sorry, reading back fuses was unreliable. I have given up and exited programming mode

avrdude done.  Thank you.

This is the same with lock and calibration bits.

I've notice that after write the response message has one additional ACK byte.

avrdude: jtagmkI_send(): sending 6 bytes
avrdude: Send: W [57] . [b2] . [00] . [00] . [00] . [00]   [20]   [20]
avrdude: Recv: A [41]

avrdude: jtagmkI_send(): sending 2 bytes
avrdude: Send: h [68] . [cf]   [20]   [20]
avrdude: Recv: A [41]

Here you can see write is ok, but on following read:
avrdude: jtagmkI_send(): sending 6 bytes
avrdude: Send: R [52] . [b2] . [02] . [00] . [00] . [00]   [20]   [20]
avrdude: Recv: A [41] A [41] . [cf] . [99] . [fe] . [00]

You can see the extra 'A'. Maybe this is AVR-JTAGICE bug.

What I did in the patch is after sending datacmd read 2 bytes, not 1.

Index: jtagmkI.c

--- jtagmkI.c (revision 1392)
+++ jtagmkI.c (working copy)
@@ -1056,7 +1056,7 @@
{
unsigned char cmd[6], datacmd[1 * 2 + 1];
unsigned char resp[1], writedata;
-  int len, need_progmode = 1;
+  int len, need_progmode = 1, need_dummy_read = 0;

avrdude_message(MSG_NOTICE2, "%s: jtagmkI_write_byte(.., %s, 0x%lx, ...)\n",
progname, mem->desc, addr);
@@ -1073,17 +1073,22 @@
PDATA(pgm)->eeprom_pageaddr = (unsigned long)-1L;
} else if (strcmp(mem->desc, "lfuse") == 0) {
cmd[1] = MTYPE_FUSE_BITS;
+    need_dummy_read = 1;
addr = 0;
} else if (strcmp(mem->desc, "hfuse") == 0) {
cmd[1] = MTYPE_FUSE_BITS;
+    need_dummy_read = 1;
addr = 1;
} else if (strcmp(mem->desc, "efuse") == 0) {
cmd[1] = MTYPE_FUSE_BITS;
+    need_dummy_read = 1;
addr = 2;
} else if (strcmp(mem->desc, "lock") == 0) {
cmd[1] = MTYPE_LOCK_BITS;
+    need_dummy_read = 1;
} else if (strcmp(mem->desc, "calibration") == 0) {
cmd[1] = MTYPE_OSCCAL_BYTE;
+    need_dummy_read = 1;
} else if (strcmp(mem->desc, "signature") == 0) {
cmd[1] = MTYPE_SIGN_JTAG;
}
@@ -1152,6 +1157,8 @@
avrdude_message(MSG_NOTICE2, "OK\n");
}

+  if(need_dummy_read)
+    jtagmkI_recv(pgm, resp, 1);
return 0;
}

file #39707: jtagmkI.patch

This issue was migrated from https://savannah.nongnu.org/bugs/?50261

@mcuee
Copy link
Collaborator

mcuee commented Jun 5, 2022

I am also getting a JTAG ICE clone, hopefully it works and then I can try this out.

@mcuee mcuee added the unconfirmed Maybe a bug, needs to be reproduced by someone else label Jun 20, 2022
@mcuee
Copy link
Collaborator

mcuee commented Jul 9, 2022

The patch is attached here in line with formatting for easier read.

Index: jtagmkI.c
===================================================================
--- jtagmkI.c	(revision 1392)
+++ jtagmkI.c	(working copy)
@@ -1056,7 +1056,7 @@
 {
   unsigned char cmd[6], datacmd[1 * 2 + 1];
   unsigned char resp[1], writedata;
-  int len, need_progmode = 1;
+  int len, need_progmode = 1, need_dummy_read = 0;
 
   avrdude_message(MSG_NOTICE2, "%s: jtagmkI_write_byte(.., %s, 0x%lx, ...)\n",
 	    progname, mem->desc, addr);
@@ -1073,17 +1073,22 @@
     PDATA(pgm)->eeprom_pageaddr = (unsigned long)-1L;
   } else if (strcmp(mem->desc, "lfuse") == 0) {
     cmd[1] = MTYPE_FUSE_BITS;
+    need_dummy_read = 1;
     addr = 0;
   } else if (strcmp(mem->desc, "hfuse") == 0) {
     cmd[1] = MTYPE_FUSE_BITS;
+    need_dummy_read = 1;
     addr = 1;
   } else if (strcmp(mem->desc, "efuse") == 0) {
     cmd[1] = MTYPE_FUSE_BITS;
+    need_dummy_read = 1;
     addr = 2;
   } else if (strcmp(mem->desc, "lock") == 0) {
     cmd[1] = MTYPE_LOCK_BITS;
+    need_dummy_read = 1;
   } else if (strcmp(mem->desc, "calibration") == 0) {
     cmd[1] = MTYPE_OSCCAL_BYTE;
+    need_dummy_read = 1;
   } else if (strcmp(mem->desc, "signature") == 0) {
     cmd[1] = MTYPE_SIGN_JTAG;
   }
@@ -1152,6 +1157,8 @@
       avrdude_message(MSG_NOTICE2, "OK\n");
   }
 
+  if(need_dummy_read)
+    jtagmkI_recv(pgm, resp, 1);
   return 0;
 }
 

@mcuee mcuee added bug Something isn't working and removed unconfirmed Maybe a bug, needs to be reproduced by someone else labels Jul 9, 2022
@mcuee
Copy link
Collaborator

mcuee commented Jul 9, 2022

I can reproduce the issue.

PS C:\work\avr\avrdude_test\avrdude-7.0_bin64> .\avrdude_issue1004v3.exe -c jtag1 -p m128a -P COM12 
-U lfuse:w:0xFF:m -v


avrdude_issue1004v3.exe: Version 7.0-20220705 (64ee485)
                         Copyright (c) Brian Dean, http://www.bdmicro.com/
                         Copyright (c) Joerg Wunsch

                         System wide configuration file is "C:/work/avr/avrdude_test/avrdude-7.0_bin64/avrdude.conf"

                         Using Port                    : COM12
                         Using Programmer              : jtag1
                         AVR Part                      : ATmega128A
                         Chip Erase delay              : 9000 us
                         PAGEL                         : PD7
                         BS2                           : PA0
                         RESET disposition             : dedicated
                         RETRY pulse                   : SCK
                         Serial program mode           : yes
                         Parallel program mode         : yes
                         Timeout                       : 200
                         StabDelay                     : 100
                         CmdexeDelay                   : 25
                         SyncLoops                     : 32
                         PollIndex                     : 3
                         PollValue                     : 0x53
                         Memory Detail                 :

                                                           Block Poll               Page                       Polled
                           Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
                           ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
                           eeprom                  4    12    64    0 no       4096    8      0  9000  9000 0xff 0xff
                           flash                  33     6   128    0 yes    131072  256    512  4500  4500 0xff 0xff
                           lfuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
                           hfuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
                           efuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
                           lock                    0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
                           calibration             0     0     0    0 no          4    1      0     0     0 0x00 0x00
                           signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00

                         Programmer Type : JTAGMKI
                         Description     : Atmel JTAG ICE (mkI)
                         ICE HW version: 0xc0
                         ICE FW version: 0x80
                         Vtarget       : 6.2 V
                         JTAG clock    : 1 MHz (1.0 us)

avrdude_issue1004v3.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude_issue1004v3.exe: Device signature = 0x1e9702 (probably m128a)
avrdude_issue1004v3.exe: reading input file "0xFF"
avrdude_issue1004v3.exe: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude_issue1004v3.exe: 1 bytes of lfuse written
avrdude_issue1004v3.exe: verifying lfuse memory against 0xFF:

Reading |                        | 0% 0.00savrdude_issue1004v3.exe: jtagmkI_read_byte(): 
timeout/error communicating with programmer (resp )
avr_read(): error reading address 0x0000
    read operation not supported for memory "lfuse"
avrdude_issue1004v3.exe: failed to read all of lfuse memory, rc=-2

avrdude_issue1004v3.exe done.  Thank you.

@MCUdude
Copy link
Collaborator

MCUdude commented Jul 9, 2022

Did you try to apply the patch?

Sadly, I don't own a JTAG1 programmer, so I'm not able to help out with actual testing.

@dl8dtl
Copy link
Contributor

dl8dtl commented Jul 9, 2022

A JTAG1 clone can be easily built, all you'd need is an ATmega16, e.g. in an STK500. ;-)

I once made a small PCB for it, but it didn't work at the first attempt, so I didn't really follow up on it. Could make another attempt on that.

@mcuee
Copy link
Collaborator

mcuee commented Jul 9, 2022

I am located in Singapore and I know Chinese so I usually buy stufff from Taobao (part of AliBaba group). I bought the JTAG ICE clone from Taobao for about US$7.64 (RMB 45 for the unit + 7% GST for Singapore + RMB 3 sea shipment = RMB 51.15 = about US$7.64 ). Sea shipment is cheaper but it will take me about 1 month to get the stuff.

So sometimes I use local online stores like Shopee or Lazada, which has faster shipment (sometimes the stock is already in Singapore, sometimes it is from China), but they may not have the items.

You can probably buy from AliExpress (part of Alibaba group) which offers global shipment. Or you can look at other places like Amazon.

@mcuee
Copy link
Collaborator

mcuee commented Jul 10, 2022

A JTAG1 clone can be easily built, all you'd need is an ATmega16, e.g. in an STK500. ;-)

I once made a small PCB for it, but it didn't work at the first attempt, so I didn't really follow up on it. Could make another attempt on that.

Indeed there are quite some clone schematics available. Now it is probably easier to use USB Serial to TTL converter plus the ATMega16A.
Ref: https://scienceprog.com/build-your-own-avr-jtagice-clone/
Ref: https://www.mikrocontroller.net/attachment/104319/avrjtag_schematic.pdf
Ref: https://github.com/vyivanov/AVR-JTAG-ICE-mkI (using FT232RL)

More sophisticated users can add the level shifter as mentioned in the Microchip documentation.
http://ww1.microchip.com/downloads/en/devicedoc/doc2475.pdf

@mcuee
Copy link
Collaborator

mcuee commented Jul 10, 2022

I just tried the patch and it seems to work. I cross-verified with usbasp as well.

PS C:\work\avr\avrdude_test\avrdude> git diff
diff --git a/src/jtagmkI.c b/src/jtagmkI.c
index 7a97217..19f874c 100644
--- a/src/jtagmkI.c
+++ b/src/jtagmkI.c
@@ -1058,7 +1058,7 @@ static int jtagmkI_write_byte(PROGRAMMER * pgm, AVRPART * p, AVRMEM * mem,
 {
   unsigned char cmd[6], datacmd[1 * 2 + 1];
   unsigned char resp[1], writedata;
-  int len, need_progmode = 1;
+  int len, need_progmode = 1, need_dummy_read = 0;

   avrdude_message(MSG_NOTICE2, "%s: jtagmkI_write_byte(.., %s, 0x%lx, ...)\n",
            progname, mem->desc, addr);
@@ -1075,17 +1075,22 @@ static int jtagmkI_write_byte(PROGRAMMER * pgm, AVRPART * p, AVRMEM * mem,
     PDATA(pgm)->eeprom_pageaddr = (unsigned long)-1L;
   } else if (strcmp(mem->desc, "lfuse") == 0) {
     cmd[1] = MTYPE_FUSE_BITS;
+       need_dummy_read = 1;
     addr = 0;
   } else if (strcmp(mem->desc, "hfuse") == 0) {
     cmd[1] = MTYPE_FUSE_BITS;
+       need_dummy_read = 1;
     addr = 1;
   } else if (strcmp(mem->desc, "efuse") == 0) {
     cmd[1] = MTYPE_FUSE_BITS;
+       need_dummy_read = 1;
     addr = 2;
   } else if (strcmp(mem->desc, "lock") == 0) {
     cmd[1] = MTYPE_LOCK_BITS;
+       need_dummy_read = 1;
   } else if (strcmp(mem->desc, "calibration") == 0) {
     cmd[1] = MTYPE_OSCCAL_BYTE;
+       need_dummy_read = 1;
   } else if (strcmp(mem->desc, "signature") == 0) {
     cmd[1] = MTYPE_SIGN_JTAG;
   }
@@ -1154,6 +1159,9 @@ static int jtagmkI_write_byte(PROGRAMMER * pgm, AVRPART * p, AVRMEM * mem,
       avrdude_message(MSG_NOTICE2, "OK\n");
   }

+  if(need_dummy_read)
+    jtagmkI_recv(pgm, resp, 1);
+
   return 0;
 }

PS C:\work\avr\avrdude_test\avrdude-7.0_bin64> .\avrdude_issue443.exe -c jtag1 -p m128a -P COM12 -U lfuse:w:0xFF:m

avrdude_issue443.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude_issue443.exe: Device signature = 0x1e9702 (probably m128a)
avrdude_issue443.exe: reading input file "0xFF"
avrdude_issue443.exe: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude_issue443.exe: 1 bytes of lfuse written
avrdude_issue443.exe: verifying lfuse memory against 0xFF:

Reading | ################################################## | 100% 0.01s

avrdude_issue443.exe: 1 bytes of lfuse verified

avrdude_issue443.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude-7.0_bin64> .\avrdude_issue443.exe -qqp m128a -c usbasp -U lfuse:r:-:h
0xff

PS C:\work\avr\avrdude_test\avrdude-7.0_bin64> .\avrdude_issue443.exe -c jtag1 -qqp m128a -P COM12 -U lfuse:w:0xBF:m

PS C:\work\avr\avrdude_test\avrdude-7.0_bin64> .\avrdude_issue443.exe -qqp m128a -c usbasp -U lfuse:r:-:h
0xbf

@mcuee
Copy link
Collaborator

mcuee commented Jul 17, 2022

@MCUdude
Do you want to create a pull request for this one? My git capability is really low...

@dl8dtl
Copy link
Contributor

dl8dtl commented Jul 18, 2022

Could make another attempt on that.

Works now 😃

@mcuee
Copy link
Collaborator

mcuee commented Jul 19, 2022

Could make another attempt on that.

Works now 😃

Nice. I am a hardware engineer at work so I try not to touch HW stuff at my spare time -- more on SW stuff.

So I tend to buy cheaper alternative when there is a clone for the official tool; or official tool when it is not too expensive (usually less than US$50).

@dl8dtl
Copy link
Contributor

dl8dtl commented Jul 19, 2022

In my case, it's just the opposite. :-) I'm a hardware engineer by passion, but got into software during all of my jobs, so I'm happy about any occasional small hardware project. The JTAG1 clone was such a tiny item, I mainly did it to have one ready for AVRDUDE testing. It consists of an ATmega16 and an FT232RL, not much more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants