AT89S51 and AT89S52 support for avrdude #1304

orbanp · 2023-02-07T19:22:28Z

Hello Everyone,

I am new here, so please advise if this is the wrong place to ask the following question.

I am trying to program an AT89S52 chip.
I am using avrdude 6.3 and an ebay programmer which is a version of the usbasp programmer.
The OS is Kubuntu 20.04 LTS.
I am getting the following error message:

$ avrdude -p usbasp -c 5082 -U flash:r:"test.bin":r
avrdude: error at /etc/avrdude.conf:336: programmer type must be written as "id_type"
avrdude: error reading system wide configuration file "/etc/avrdude.conf"

I updated the configuration file that has an entry for the AT89S52 chip, the programmer description is the same that came with the installation.
The suggestion that the programmer type should be written in the configuration file with double quotes did not make any difference.

Previously I installed avrdude 7.0 and got the same error.
avrdude 6.3 came from the Software Center of the OS.

Any help would be appreciated!
Thanks, Peter

The text was updated successfully, but these errors were encountered:

MCUdude · 2023-02-07T21:46:20Z

Hi!

First of all, Avrdude doesn't support programming of AT89 chips out of the box, but with a custom avrdude.conf file it might work.

First, can you share the part of your avrdude.conf where the AT89S52 chip is defined?

orbanp · 2023-02-07T22:16:36Z

Thanks for the reply!

The error message complains about the programmer type!

I did try the original installation as well, without the updated config file, with another programmer, and with another device that were in the original config file, and got the same error message about the programmer type.

Enclosing the config file section about the AT89S52.

Thanks, Peter

#------------------------------------------------------------
# AT89S52
#------------------------------------------------------------
part
    id               = "8052";
    desc             = "AT89S52";
    signature        = 0x1E 0x52 0x06;
    chip_erase_delay = 500000;
    pgm_enable       = "1 0 1 0  1 1 0 0    0 1 0 1  0 0 1 1",
                       "x x x x  x x x x    x x x x  x x x x";

    chip_erase       = "1 0 1 0  1 1 0 0    1 0 0 x  x x x x",
                       "x x x x  x x x x    x x x x  x x x x";

    timeout      = 200;
    stabdelay      = 100;
    cmdexedelay      = 25;
    synchloops      = 32;
    bytedelay      = 0;
    pollindex      = 3;
    pollvalue      = 0x53;
    predelay      = 1;
    postdelay      = 1;
    pollmethod      = 0;

    memory "flash"
        size            = 8192;
        paged           = no;
        min_write_delay = 4000;
        max_write_delay = 9000;
        readback_p1     = 0xff;
        readback_p2     = 0xff;
        read            = "  0   0   1   0    0   0   0   0",
                          "  x   x   x a12  a11 a10  a9  a8",
                          " a7  a6  a5  a4   a3  a2  a1  a0",
                          "  o   o   o   o    o   o   o   o";

        write           = "  0   1   0   0    0   0   0   0",
                          "  x   x   x a12  a11 a10  a9  a8",
                          " a7  a6  a5  a4   a3  a2  a1  a0",
                          "  i   i   i   i    i   i   i   i";
   mode      = 0x21;
   delay      = 12;
      ;

    memory "signature"
        size            = 3;
        read            = "0  0  1  0   1  0  0  0   x  x  x  0   0  0 a1 a0",
                          "0  0  0  0   0  0  0  0   o  o  o  o   o  o  o  o";
      ;
  ;

MCUdude · 2023-02-07T22:21:13Z

It might be something else that's wrong with your avrdude.conf. I'm using the latest 7.1 version, and I'm able to get Avrdude to run even though there are a few warnings. Try building Avrddue yourself, and add the AT89S52 target to the avrdude.conf file that was created by the build.

$ ./avrdude -cusbasp -p8052
avrdude warning: a1 would normally be expected to be a9 [/Users/hans/Downloads/avrdude/src/avrdude.conf:16243]
avrdude warning: a0 would normally be expected to be a8 [/Users/hans/Downloads/avrdude/src/avrdude.conf:16243]
avrdude warning: mcuid -1 for AT89S52 is out of range [0..2039], use a free number >= 372 [/Users/hans/Downloads/avrdude/src/avrdude.conf:16245]

avrdude error: program enable: target does not answer (0x01)
avrdude error: initialization failed, rc=-1
        - double check the connections and try again
        - use -B to set lower ISP clock frequency, e.g. -B 125kHz
        - use -F to override this check


avrdude done.  Thank you.

mcuee · 2023-02-08T11:19:06Z

Since this is not supported by avrdude, I will close this issue.

The command line mentioned in the first post is totally wrong. It should be avrdude -cusbasp -p8052 ....

llinjupt · 2023-03-04T03:17:02Z

Since this is not supported by avrdude, I will close this issue.

The command line mentioned in the first post is totally wrong. It should be avrdude -cusbasp -p8052 ....

Even though avrdude doesn't support AT89S series, for coherence, the 7.1 should behaviour the same as 7.0 which works well.

$ ./avrdude.exe -P COM180 -c avrisp -p 8052 -U flash:r:flash.bin:r

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

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x1e5206 (probably 89s52)
avrdude.exe: reading flash memory:

Reading | ################################################## | 100% 3.51s

avrdude.exe: writing output file "flash.bin"

avrdude.exe done.  Thank you.

It seems that 7.1 couldn't analyse the old avrdude.conf well, and throwed out the error:

$ ./avrdude.exe -P COM180 -c avrisp -p 8052 -U flash:r:flash.bin:r
avrdude warning: a1 would normally be expected to be a9 [F:\avrdude7.1\win64\avrdude.conf:49]
avrdude warning: a0 would normally be expected to be a8 [F:\avrdude7.1\win64\avrdude.conf:49]
avrdude warning: mcuid -1 for AT89S52 is out of range [0..2039], use a free number >= 372 [F:\avrdude7.1\win64\avrdude.conf:51]

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0xffffff (probably .xmega) (retrying)
avrdude: device signature = 0xffffff (probably .xmega) (retrying)
avrdude: device signature = 0xffffff (probably .xmega)
avrdude error: Yikes!  Invalid device signature.
avrdude error: expected signature for AT89S52 is 1E 52 06
        Double check connections and try again, or use -F to override
        this check.


avrdude done.  Thank you.

Anyway, for convenience I strongly recommand to keep the coherence with 7.0.

llinjupt · 2023-03-04T03:27:49Z

BTW, I have tried to update the avrdude.conf as below to fit 7.1:

part
    id               = "89s52";
    desc             = "AT89S52";
    stk500_devcode   = 0xE1;
    mcuid            = 372;
    signature        = 0x1e 0x52 0x06;
    chip_erase_delay = 500000;
    reset            = dedicated;
    pgm_enable       = "1010.1100--0101.0011--xxxx.xxxx--xxxx.xxxx";
    chip_erase       = "1010.1100--100x.xxxx--xxxx.xxxx--xxxx.xxxx";

    memory "flash"
        size            = 8192 ;             # bytes
        read            = "0010.0000--xxxa.aaaa--aaaa.aaaa--oooo.oooo";
        write           = "0100.0000--xxxa.aaaa--aaaa.aaaa--iiii.iiii";
        ;
    memory "signature"
        size            = 3;
        read            = "0010.1000--0000.00aa--0000.0000--oooo.oooo";
        ;
  ;

part parent "89s52"
    id = "89s51";
    desc = "AT89S51";
    signature = 0x1e 0x51 0x06;
    mcuid     = 373;
    memory "flash"
        size            = 4096 ;             # bytes
        read            = "0010.0000--xxxx.aaaa--aaaa.aaaa--oooo.oooo";
        write           = "0100.0000--xxxx.aaaa--aaaa.aaaa--iiii.iiii";
      ;
;

And I got another error. Since I know nothing about the a1 bit, any advice?

$ ./avrdude.exe -P COM180 -c avrisp -p AT89S52 -U flash:r:flash.bin:r
avrdude warning: AT89S52's signature read misses a necessary address bit a1 [F:\avrdude7.1\win64\avrdude.conf:20]

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e1e1e
avrdude error: expected signature for AT89S52 is 1E 52 06
        double check chip or use -F to override this check

avrdude done.  Thank you.

mcuee · 2023-03-04T03:47:08Z

Anyway, for convenience I strongly recommand to keep the coherence with 7.0.

No, the warnings will be there if you use old-style avrdude.conf file. And to me it is not worth the effort to support AT89S52 in avrdude.

mcuee · 2023-03-04T03:53:39Z

That being said, maybe @MCUdude or @stefanrueger will be able to see if they can help you here or not.

mcuee · 2023-03-04T03:59:20Z

Hmm, it seems to be that PlatformIO seems to support AT89S51/AT89S52 using avrdude. So maybe there are valid use case here. I will leave this to other admins to decide.
https://docs.platformio.org/en/latest/boards/intel_mcs51/AT89S51.html
https://docs.platformio.org/en/latest/boards/intel_mcs51/AT89S52.html

Therefore I have re-opened the issue and changed the issue titile and the issue label to "enhancement".

stefanrueger · 2023-03-04T11:58:53Z

Try the following entries [edit: added prog_modes]

#------------------------------------------------------------
# AT89S52
#------------------------------------------------------------

part
    desc                   = "AT89S52";
    id                     = "8052";
    prog_modes             = PM_ISP | PM_HVPP;
    mcuid                  = 373;
    chip_erase_delay       = 500000;
    signature              = 0x1e 0x52 0x06;
    timeout                = 200;
    stabdelay              = 100;
    cmdexedelay            = 25;
    synchloops             = 32;
    pollindex              = 3;
    pollvalue              = 0x53;
    predelay               = 1;
    postdelay              = 1;
    chip_erase             = "1010.1100--100x.xxxx--xxxx.xxxx--xxxx.xxxx";
    pgm_enable             = "1010.1100--0101.0011--xxxx.xxxx--xxxx.xxxx";

    memory "flash"
        size               = 8192;
        min_write_delay    = 4000;
        max_write_delay    = 9000;
        readback           = 0xff 0xff;
        mode               = 0x21;
        delay              = 12;
        read               = "0010.0000--xxxa.aaaa--aaaa.aaaa--oooo.oooo";
        write              = "0100.0000--xxxa.aaaa--aaaa.aaaa--iiii.iiii";
    ;

    memory "signature"
        size               = 3;
        read               = "0 0 1 0 1 0 0 0  x x x 0 0 0 a1 a0  0 0 0 0 0 0 0 0  o o o o o o o o";
    ;
;

#------------------------------------------------------------
# AT89S51
#------------------------------------------------------------

part parent "AT89S52"
    desc                   = "AT89S51";
    id                     = "89s51";
    mcuid                  = 372;
    signature              = 0x1e 0x51 0x06;

    memory "flash"
        size               = 4096;
        read               = "0010.0000--xxxx.aaaa--aaaa.aaaa--oooo.oooo";
        write              = "0100.0000--xxxx.aaaa--aaaa.aaaa--iiii.iiii";
    ;
;

One problem with this part is the odd documentation for the read-signature command (see below); it claims to utilise A7..A12, but that cannot be because signatures have 3 bytes, so only A0 and A1 should be relevant. I suspect the documentation is wrong, and that A0 and A1 need to be set. I looks like this part has A0 and A1 not in their standard position (end of Byte 3) but instead at end of Byte 2. All other parts known to AVRDUDE have the address bits in byte2 and byte3 in a systematic way, which has allowed a new shorter syntax for the command. So the read signature command for AT90S51/52 must use the old-style notation.

Fun fact: It used to be that contributors could not cope with the old-style notation to the effect that some 25% of the avrdude.conf entries had bits in the wrong position. This is why the warning message has been introduced. It can be ignored in this case (assuming A0/A1 have to be at the unsystematic position for these parts).

stefanrueger · 2023-03-04T13:48:40Z

@orbanp: The avrdude command mixed up the -p part and -c programmer flags. It should be -c usbasp -p 5082, not the other way round.

I am getting the following error message:

$ avrdude -p usbasp -c 5082 -U flash:r:"test.bin":r
avrdude: error at /etc/avrdude.conf:336: programmer type must be written as "id_type"
avrdude: error reading system wide configuration file "/etc/avrdude.conf"

Please try again and report back.

llinjupt · 2023-03-04T15:18:06Z

@stefanrueger, THX. I have tried your new avrdude.conf, but unluckly it didn't work:

$ ./avrdude.exe -P COM180 -c avrisp -p AT89S52 -U flash:r:flash.bin:r
avrdude warning: a1 would normally be expected to be a9 [F:\BiTForest\avrdude7.1\win64\avrdude.conf:36]
avrdude warning: a0 would normally be expected to be a8 [F:\BiTForest\avrdude7.1\win64\avrdude.conf:36]

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0xffffff (probably .xmega) (retrying)
avrdude: device signature = 0xffffff (probably .xmega) (retrying)
avrdude: device signature = 0xffffff (probably .xmega)
avrdude error: Yikes!  Invalid device signature.
avrdude error: expected signature for AT89S52 is 1E 52 06
        Double check connections and try again, or use -F to override
        this check.


avrdude done.  Thank you.

BTW, in the same environment, V7.0 with this old avrdude.conf works well:

part
    id               = "89s52";
    desc             = "AT89S52";
    stk500_devcode   = 0xE1;
    signature        = 0x1e 0x52 0x06;
    chip_erase_delay = 500000;
    reset            = dedicated;
    pgm_enable       = "1 0 1 0  1 1 0 0    0 1 0 1  0 0 1 1",
                       "x x x x  x x x x    x x x x  x x x x";

    chip_erase       = "1 0 1 0  1 1 0 0    1 0 0 x  x x x x",
                       "x x x x  x x x x    x x x x  x x x x";

    memory "flash"
        size            = 8192 ;             # bytes
        read            = "0 0 1 0 0 0 0 0  x x x a12 a11 a10 a9 a8",
                          "a7 a6 a5 a4 a3 a2 a1 a0 o o o o o o o o";
        write           = "0 1 0 0 0 0 0 0 x x x a12 a11 a10 a9 a8",
                          "a7 a6 a5 a4 a3 a2 a1 a0 i i i i i i i i";
        ;
    memory "signature"
        size            = 3;
        read            = "0 0 1 0 1 0 0 0  0 0 0 0 0 0 a1 a0",
                          "0 0 0 0 0 0 0 0  o o o o o o  o  o";
        ;
  ;
part parent "89s52"
    id = "89s51";
    desc = "AT89S51";
    signature = 0x1e 0x51 0x06;
    memory "flash"
        size            = 4096 ;             # bytes
        read            = "0 0 1 0 0 0 0 0  x x x x a11 a10 a9 a8",
                          "a7 a6 a5 a4 a3 a2 a1 a0 o o o o o o o o";
        write           = "0 1 0 0 0 0 0 0 x x x x a11 a10 a9 a8",
                          "a7 a6 a5 a4 a3 a2 a1 a0 i i i i i i i i";
      ;
;

stefanrueger · 2023-03-04T15:35:52Z

@llinjupt Thanks for sharing a working 7.0 entry. My guess was based on @orbanp's entry.

It might have been the missing stk500_devcode entry. Try in v7.1 the following (based on your entry)

#------------------------------------------------------------
# AT89S52
#------------------------------------------------------------

part
    desc                   = "AT89S52";
    id                     = "89s52";
    prog_modes             = PM_ISP | PM_HVPP;
    mcuid                  = 373;
    stk500_devcode         = 0xe1;
    chip_erase_delay       = 500000;
    signature              = 0x1e 0x52 0x06;
    chip_erase             = "1010.1100--100x.xxxx--xxxx.xxxx--xxxx.xxxx";
    pgm_enable             = "1010.1100--0101.0011--xxxx.xxxx--xxxx.xxxx";

    memory "flash"
        size               = 8192;
        read               = "0010.0000--xxxa.aaaa--aaaa.aaaa--oooo.oooo";
        write              = "0100.0000--xxxa.aaaa--aaaa.aaaa--iiii.iiii";
    ;

    memory "signature"
        size               = 3;
        read               = "0 0 1 0 1 0 0 0  0 0 0 0 0 0 a1 a0  0 0 0 0 0 0 0 0  o o o o o o o o";
    ;
;

#------------------------------------------------------------
# AT89S51
#------------------------------------------------------------

part parent "89s52"
    desc                   = "AT89S51";
    id                     = "89s51";
    mcuid                  = 372;
    signature              = 0x1e 0x51 0x06;

    memory "flash"
        size               = 4096;
        read               = "0010.0000--xxxx.aaaa--aaaa.aaaa--oooo.oooo";
        write              = "0100.0000--xxxx.aaaa--aaaa.aaaa--iiii.iiii";
    ;
;

llinjupt · 2023-03-04T15:49:07Z

@stefanrueger Good news it works and bad news with warninings:

$ ./avrdude.exe -P COM180 -c avrisp -p AT89S52 -U flash:r:flash.bin:r
avrdude warning: a1 would normally be expected to be a9 [F:\BiTForest\avrdude7.1\win64\avrdude.conf:24]
avrdude warning: a0 would normally be expected to be a8 [F:\BiTForest\vrdude7.1\win64\avrdude.conf:24]

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e5206 (probably 89s52)
avrdude: reading flash memory ...

Reading | ################################################## | 100% 3.54s

avrdude: writing output file flash.bin

avrdude done.  Thank you.

stefanrueger · 2023-03-04T16:01:33Z

This is the first time the project has come across an AVR where the address bits do not conform to their usual positions. When we create a PR to support AT89S51/52, we can try to suppress the warning for these (odd) parts.

Before I do a PR, please also try to write flash and verify. If you have the AT89S51, please also try that part.

BTW, in order to migrate a part entry from an older avrdude version, you can normally put that into avrdude.conf, add new parameters needed for the new version (here, prog_modes and mcuid, though neither would have been needed I guess) and then run the new avrdude with

$ avrdude -pAT89S5[12]/s

This outputs migrated, canonical entries suitable for the new version.

I also noted that the flash r/w commands have one address bit too many: it's word addresses, not byte addresses for flash. This should be better [edit - also updated stk500_devcode for the AT89S51]:

#------------------------------------------------------------
# AT89S52
#------------------------------------------------------------

part
    desc                   = "AT89S52";
    id                     = "89s52";
    prog_modes             = PM_ISP | PM_HVPP;
    mcuid                  = 373;
    stk500_devcode         = 0xe1;
    chip_erase_delay       = 500000;
    signature              = 0x1e 0x52 0x06;
    chip_erase             = "1010.1100--100x.xxxx--xxxx.xxxx--xxxx.xxxx";
    pgm_enable             = "1010.1100--0101.0011--xxxx.xxxx--xxxx.xxxx";

    memory "flash"
        size               = 8192;
        read               = "0010.0000--xxxx.aaaa--aaaa.aaaa--oooo.oooo";
        write              = "0100.0000--xxxx.aaaa--aaaa.aaaa--iiii.iiii";
    ;

    memory "signature"
        size               = 3;
        read               = "0 0 1 0 1 0 0 0  0 0 0 0 0 0 a1 a0  0 0 0 0 0 0 0 0  o o o o o o o o";
    ;
;

#------------------------------------------------------------
# AT89S51
#------------------------------------------------------------

part parent "89s52"
    desc                   = "AT89S51";
    id                     = "89s51";
    mcuid                  = 372;
    stk500_devcode         = 0xe0;
    signature              = 0x1e 0x51 0x06;

    memory "flash"
        size               = 4096;
        read               = "0010.0000--xxxx.xaaa--aaaa.aaaa--oooo.oooo";
        write              = "0100.0000--xxxx.xaaa--aaaa.aaaa--iiii.iiii";
    ;
;

stefanrueger · 2023-03-04T17:51:29Z

@llinjupt ... and I suspect that the AT89S51 needs a different stk500_devcode = 0xe0; (not the inherited 0xe1):

avrdude/src/avrdude.conf.in

Lines 344 to 345 in 4019edf

    
           #define AT89S51     0xE0 
        
           #define AT89S52     0xE1

llinjupt · 2023-03-05T03:01:12Z

@llinjupt ... and I suspect that the AT89S51 needs a different stk500_devcode = 0xe0; (not the inherited 0xe1):

avrdude/src/avrdude.conf.in

Lines 344 to 345 in 4019edf

#define AT89S51 0xE0

#define AT89S52 0xE1

@stefanrueger , Yes, you are right that AT89S51 has its own devcode. And I have checked how it is used. Actually, in avrisp, it's only used to detemine the rst polarity, and that's why the old avrdude.conf is accidentally ok for AT89S51:

rst_active_high = (param.devicecode >= 0xe0);

Reading back the flash and fill it up to the full falsh size:
truncate.exe -s 8192 flash.bin

Wrting failed with your lastest avrdude.conf and check the datasheet there is really an A12 which seems can be ignored:

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e5206 (probably 89s52)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file flash.bin for flash
         with 8192 bytes in 1 section within [0, 0x1fff]
avrdude: writing 8192 bytes flash ...

Writing | #################################################- | 99% 7.02s

 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
avrdude: 8192 bytes of flash written
avrdude: verifying flash memory against flash.bin

Reading | ################################################## | 100% 3.50s

avrdude warning: verification mismatch
        device 0x00 != input 0x11 at addr 0x0040 (error)
avrdude error: verification mismatch

avrdude done.  Thank you.

There is no AT89S51 on hand, so I have ordered some chips already. Maybe two or three days the feedback will be ready.

Another subtle problem is that I have noticed the lock bits in the datasheet as well as the picture you pasted above. For reading there are 3 bits LB3/2/1 and for writing there are 2 bits B1/B2. Isn't it a bit confusing? Would you like to config it too for both 51/52 in avrdude.conf? And I could verify at the same time.

stefanrueger · 2023-03-05T14:26:35Z

Wrting failed

Thanks for testing. I suspect for writing to work the flash memory should specify the correct page_size > 1.

Maybe try, 2, 4, 8, 16, ...

It is a pity there does not seem to be an .atdf file (or .xml file as they were called in the early days) containing the necessary write delay etc parameters that need to go into the .conf file. The data sheet is very terse, too.

In order for HVPP programming to work, other parameters would need to be specified, too, in avrdude.conf. Maybe try setting the other parameters like in @orbanp 's entry? Or copying parameters from "similar" other parts in avrdude.conf for this entry? You could try a few settings.

I suspect AVRDUDE will be able to read the lock bits but won't be able to write them: The .conf file can set pretty much any SPI command (the old notation has a very versatile syntax!), but apparently the footnote in the data sheet says that one needs several writes of different SPI-commands to effect certain lock levels... That procedure isn't in the code base (and is probably not worth our while implementing!)

stefanrueger · 2023-03-05T14:35:19Z

check the datasheet there is really an A12

Ooops that's right. And the data sheet says "byte mode" for flash r/w. So, page size 1 would appear correct for flash. And one would need a12 in the flash read/write commands (as it's a byte address not a word address).

So, this makes me wonder. Has your .conf file also worked for writing in AVRDUDE v7.0 or any earlier AVRDUDE? If so let us know.

stefanrueger · 2023-03-05T18:01:59Z

Here another one to try with some sensible other values set

#------------------------------------------------------------
# AT89S51
#------------------------------------------------------------

part
    desc                   = "AT89S51";
    id                     = "89S51";
    prog_modes             = PM_ISP | PM_HVPP;
    mcuid                  = 372;
    stk500_devcode         = 0xe0;
    chip_erase_delay       = 250000;
    signature              = 0x1e 0x51 0x06;
    timeout                = 200;
    stabdelay              = 100;
    cmdexedelay            = 25;
    synchloops             = 32;
    pollindex              = 4;
    pollvalue              = 0x69;
    predelay               = 1;
    postdelay              = 1;
    chiperasepulsewidth    = 15;
    programfusepulsewidth  = 2;
    programlockpolltimeout = 1;
    chip_erase             = "1010.1100--100x.xxxx--xxxx.xxxx--xxxx.xxxx";
    pgm_enable             = "1010.1100--0101.0011--xxxx.xxxx--xxxx.xxxx";

    memory "flash"
        size               = 4096;
        min_write_delay    = 4500;
        max_write_delay    = 4500;
        readback           = 0xff 0xff;
        mode               = 0x02;
        delay              = 10;
        blocksize          = 256;
        read               = "0010.0000--xxxa.aaaa--aaaa.aaaa--oooo.oooo";
        write              = "0100.0000--xxxa.aaaa--aaaa.aaaa--iiii.iiii";
        # Page mode is available in the device, but not implemented here.
    ;

    memory "signature"
        size               = 3;
        read               = "0 0 1 0 1 0 0 0  x x x x x x a1 a0  x x x x x x x 0  o o o o o o o o";
    ;
    # Lock bits are available in the device but not implemented here
;

#------------------------------------------------------------
# AT89S52
#------------------------------------------------------------

part parent "89S51"
    desc                   = "AT89S52";
    id                     = "89S52";
    mcuid                  = 373;
    stk500_devcode         = 0xe1;
    signature              = 0x1e 0x52 0x06;

    memory "flash"
        size               = 8192;
        # Page mode is available in the device but not implemented here
    ;
  # Lock bits are available in the device but not implemented here
;

llinjupt · 2023-03-06T00:38:29Z

@stefanrueger

That procedure isn't in the code base (and is probably not worth our while implementing!)

I see. If the code base don't suppport, it's reasonable and acceptable.

Has your .conf file also worked for writing in AVRDUDE v7.0 or any earlier AVRDUDE? If so let us know.

Yes. I have tried 6.3 and it worked well.

With your newest avrdude.conf, both reading and writing are passed for 89S52. And as soon as 89S51 is arrived I will give feedback.

$ ./avrdude.exe -c avrisp -P COM245 -p AT89S52 -U flash:w:AT89S52.bin:r
avrdude warning: a1 would normally be expected to be a9 [F:\BiTForest\ATMEL\TEST_BINs\avrdude.conf:42]
avrdude warning: a0 would normally be expected to be a8 [F:\BiTForest\ATMEL\TEST_BINs\avrdude.conf:42]

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e5206 (probably 89S52)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file AT89S52.bin for flash
         with 8192 bytes in 1 section within [0, 0x1fff]
avrdude: writing 8192 bytes flash ...

Writing | ################################################## | 100% 24.57s

avrdude: 8192 bytes of flash written
avrdude: verifying flash memory against AT89S52.bin

Reading | ################################################## | 100% 8.19s

avrdude: 8192 bytes of flash verified

avrdude done.  Thank you.

llinjupt · 2023-03-06T01:45:33Z

And the data sheet says "byte mode" for flash r/w. So, page size 1 would appear correct for flash. And one would need a12 in the flash read/write commands (as it's a byte address not a word address).

Yes, the address space is exactly the same as the flash size. And I have noticed AT89S51/2 all support page mode read/write. Is it possible to support it? If so, it would be great for speed consideration.

orbanp · 2023-03-06T20:12:11Z

Hello Everyone,

I appreciate the continuing help and discussions!

To reiterate, I have avrdude version 3.6 on my machine, ubuntu 20.04 with KDE frontend.

I have two hardware interfaces for programming. One of them is a pair of usbasp dongles. The usbasp interfces do work, I did upgrade the firmware in them, programming one with the other. It was a couple of years ago when I obtained them on ebay, not sure about the firmware version.

The other interface is a simplified version of the STK200 dongle, a cable from the parallel port of the PC, with four simple wires for the reset, in and out data, and clock signals, plus ground.
The cable works. I could read/write (program) the AT89S52 flash with it using an old program under W10, the IspPgm30a, a program that has been long abandoned and has some issues.

Looking at the signals with a scope, using the usbasp interface, that hardware does not handle the reset signal. The AT89S52 has an active high reset, and it needs to be set to high to initiate ISP programming and the usbasp interface does not do that.

"My STK200" dongle shows some life when trying to program.
It initiates contact with the processor, however the signature and data returned is invalid.
I defined a new programmer in the config file, same features as that of the STK200, with the reset signal inverted.
Using that hardware description the reset signal is raised high and I can see the clock signal and the input data signal changing, however the data is not what I would expect when forcing the flash read operation.
There is a correct program in the processor, it runs as it is supposed to, but the data received is a simple counter, the values increasing to 00x to FFx.
The processor is running at 12MHz, the ISP programming max speed could be 1/16-the of that clock speed, that is 750kHz.
The scope shows that the ISP clock speed is 500kHz.

Again, here is the processor description in the config file that I have been using with avrdude 6.3:

#------------------------------------------------------------
# AT89S52
#------------------------------------------------------------
part
    id               = "8052";
    desc             = "AT89S52";
    signature        = 0x1E 0x52 0x06;
    chip_erase_delay = 500000;
    pgm_enable       = "1 0 1 0  1 1 0 0    0 1 0 1  0 0 1 1",
                       "x x x x  x x x x    x x x x  x x x x";

    chip_erase       = "1 0 1 0  1 1 0 0    1 0 0 x  x x x x",
                       "x x x x  x x x x    x x x x  x x x x";

    timeout      = 200;
    stabdelay      = 100;
    cmdexedelay      = 25;
    synchloops      = 32;
    bytedelay      = 0;
    pollindex      = 3;
    pollvalue      = 0x53;
    predelay      = 1;
    postdelay      = 1;
    pollmethod      = 0;

    memory "flash"
        size            = 8192;
        paged           = no;
        min_write_delay = 4000;
        max_write_delay = 9000;
        readback_p1     = 0xff;
        readback_p2     = 0xff;
        read            = "  0   0   1   0    0   0   0   0",
                          "  x   x   x a12  a11 a10  a9  a8",
                          " a7  a6  a5  a4   a3  a2  a1  a0",
                          "  o   o   o   o    o   o   o   o";

        write           = "  0   1   0   0    0   0   0   0",
                          "  x   x   x a12  a11 a10  a9  a8",
                          " a7  a6  a5  a4   a3  a2  a1  a0",
                          "  i   i   i   i    i   i   i   i";
   mode      = 0x21;
   delay      = 12;
      ;

    memory "signature"
        size            = 3;
        read            = "0  0  1  0   1  0  0  0   x  x  x  0   0  0 a1 a0",
                          "0  0  0  0   0  0  0  0   o  o  o  o   o  o  o  o";
      ;
  ;

Also enclose the STK200 description with the inverted reset:

# Parallel cable programmer with inverted RESET signal
# It is suitable, among others, for the AT89S52

programmer
  id    = "stk200_I_R";
  desc  = "STK200 with inverted Reset";
  type  = "par";
  connection_type = parallel;
  buff  = 4, 5;
  sck   = 6;
  mosi  = 7;
  reset = ~9;
  miso  = 10;
;

Thanks, Peter

llinjupt · 2023-03-30T02:53:28Z

@orbanp @mcuee
After glancing over those souce codes of USBasp firmware which claimed to support AT89S5x, I realize that none of them could support avrdude natively.

Spending some time doing hacking, I found it's easy to make the official USBasp version to support avrdude:

$ ./avrdude.exe -P usb -c usbasp -p AT89S52 -U flash:w:AT89S52.bin:r

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e5206 (probably 89S52)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file AT89S52.bin for flash
         with 8192 bytes in 1 section within [0, 0x1fff]
avrdude: writing 8192 bytes flash ...

Writing | ################################################## | 100% 9.76s

avrdude: 8192 bytes of flash written
avrdude: verifying flash memory against AT89S52.bin

Reading | ################################################## | 100% 3.19s

avrdude: 8192 bytes of flash verified

avrdude done.  Thank you.

Keep in mind that you only need to do 2 things:

Rst polarity of AT89S5x is opposite of AVR.
probe AT89S5x, the fourth byte will get 0x69

Since I didn't hack it on a AVR MCU, so I paste alike hacked code below for you to refer:

uchar ispEnterProgrammingMode() {
	uchar check;
	uchar count = 32;

       ISP_OUT |= (1 << ISP_RST); 
	while (count--) {
		ispTransmit(0xAC);
		ispTransmit(0x53);
		ispTransmit(0);
		check = ispTransmit(0);

		if (check == 0x69) {
			return 0;
		}

		spiHWdisable();

		/* pulse RST */
		ispDelay();
		ISP_OUT &= ~(1 << ISP_RST); /* RST low */
		ispDelay();
		ISP_OUT |= (1 << ISP_RST); /* RST high */
                ispDelay();

		if (ispTransmit == ispTransmit_hw) {
			spiHWenable();
		}
	}

	return 1; /* error: device dosn't answer */
}

mcuee · 2023-03-30T03:01:13Z

@llinjupt

Thanks a lot for looking at usbasp firmware. This is much better for avrdude project. It is always better to support open firmware and not some unknown firmware.

I will try your modification once I get the AT89S52 chip.

@dioannidis
Just wonder if you are willing to add the support in your usbasp firmware. You need to update the following code as per the suggestion from @llinjupt
https://github.com/dioannidis/usbasp/blob/master/firmware/isp.c

dioannidis · 2023-03-30T07:23:57Z

Hi,

@mcuee , @llinjupt

Just wonder if you are willing to add the support in your usbasp firmware. You need to update the following code as per the suggestion from @llinjupt
https://github.com/dioannidis/usbasp/blob/master/firmware/isp.c

OK I'll order those parts and after testing I'll add it

mcuee · 2023-03-31T00:20:50Z

Keep in mind that you only need to do 2 things:

Rst polarity of AT89S5x is opposite of AVR.
probe AT89S5x, the fourth byte will get 0x69

@llinjupt and @stefanrueger

In this case, it is possible to just change avrdude (to change usbasp.c and avrdude.conf.in, create a variant of usbasp, say, usbasp_at89s) without changing the usbasp open source firmware?

I have also re-opened this issue to see if there is a way to support these two AT89S chips with other programmers, at least for a few more popular ones. I am guessing STK500v2 based programmers may already work. I am not so sure about USBtinyISP.

Edit: adding a reference here: reset pin polarity handling can be done by HW as well.
https://www.avrfreaks.net/s/topic/a5C3l000000UKhJEAW/t093355?page=2

llinjupt · 2023-03-31T00:59:26Z

@mcuee
IMHO, if the programmer doesn't support setting reset polarity, that's impossible to do so. And there are more other strange chips like S2051/AT89S8252/AT89S8253 that behave pretty differently, see below probe function which comes from one variant of USBasp.

uchar ispEnterProgrammingMode() {
	uchar check, check89 = 0;				//.kbv
	uchar count = 4;
	int i;
	// this is crap.   We need to do a proper RESET pulse before the start sequence.
	// we never want to insert false SCK pulses.
	for (i = 0; i < 256; i++) AT89buf[i] = 0xFF;
	while (count--) {
		reset_active_high = 0;			// all AVRs are active-low
		SS_inp();
		AT89mode = 0;
		spimode_1 = 0;
		ispReset();				// .kbv put into ISP mode for another go
		ispTransmit(0xAC);
		ispTransmit(0x53);
		check = ispTransmit(0xAA);
		check89 = ispTransmit(0x33);		// NOP on a S8252
		if (check == 0x53 && check89 == 0xAA) {	// AVR
			return 0;
		}
		reset_active_high = 1;			// AT89 are active-high
		SS_out();
		if (((PINC & (1<<PC2)) == 0) || (eeprom_read_byte(&AT89reset_low) == 0x55))
			reset_active_high = 0;		// SLOW jumper overrules
		AT89mode = 0;
		spimode_1 = 0;
		ispReset();				// .kbv put into ISP mode for another go
		SS_low();
		ispTransmit(0xAC);
		ispTransmit(0x53);
		check = ispTransmit(0xAA);
		check89 = ispTransmit(0x33);
		if (check == 0x53 && check89 == 0xAA) {			// AVR or S2051
			if (reset_active_high == 0) {
				SS_inp();
				return 0;		// AVR
			}
			AT89mode = 1;			// S2051
			AT89page_size = 32;
			return 0;
		}
		if (check89 == 0x69) {
			AT89mode = 4;			// AT89S52
			AT89page_size = 256;
			return 0;
		}
		check = ispTransmit(0x55);
		check89 = ispTransmit(0);
		if (check == 0x33 && check89 == 0x55) {	// AT89S8252
			AT89mode = 2;
			AT89page_size = 0;
			return 0;
		}

		spimode_1 = 1;				// only 8253 uses SPI mode #1
		ispReset();				// .kbv put into ISP mode for another go
		SS_low();
		ispTransmit(0xAC);
		ispTransmit(0x53);
		check = ispTransmit(0xAA);
		check89 = ispTransmit(0);
		if (check == 0x53 && check89 == 0xAA) {	// AT89S8253
			AT89mode = 5;
			AT89page_size = 64;
			return 0;
		}

		spimode_1 = 0;
		ispReset();				// .kbv put into ISP mode for another go
		SS_low();
		ispTransmit(0xAA);
		ispTransmit(0xAC);
		ispTransmit(0x53);
		check = ispTransmit(0);
		check89 = ispTransmit(0);
		SS_high();
		if (check == 0x53) {
			AT89mode = 3;			// AT89LP4052
			AT89page_size = 32;
			return 0;
		}

		spimode_1 = 0;
		ispReset();				// .kbv put into ISP mode for another go
		SS_low();
		ispTransmit(0xAA);
		ispTransmit(0x55);
		ispTransmit(0xAC);
		ispTransmit(0x53);
		check = ispTransmit(0);
		check89 = ispTransmit(0);
		SS_high();
		if (check == 0x53) {
			AT89mode = 6;			// AT89LP51RD2, AT89LP6440 etc
			AT89page_size = 64;
			return 0;
		}
	}

	SS_high();
	SS_inp();
	reset_active_high = 0; // all AVRs are active-low
	return 1; /* error: device dosn't answer */
}

stefanrueger · 2023-04-02T17:57:22Z

I agree with @llinjupt: this is probably nothing AVRDUDE can do about it if the programmer cannot cope with different reset polarity. I suggest closing the issue again.

mcuee · 2023-04-02T23:51:55Z

Okay, close for now.

dioannidis · 2023-04-21T13:40:42Z

@mcuee, @llinjupt

The AT89S51 and AT89S52 ICs just arrived :) . Do I need a patched avrdude and conf file or the version from here https://github.com/mcuee/avrdude/releases/tag/v7.1 supports them ?

I'll try to find time next week to test the llinjupt's code and if all is ok then I'll release the 1.11 version .

mcuee · 2023-04-21T13:49:26Z

@dioannidis

I think the idea is not to patch avrdude, but rather patch usbasp FW.

You can use the latest github action mingw-64 build of avrdude main.
https://github.com/avrdudes/avrdude/suites/12376320894/artifacts/657514449

mcuee · 2023-04-21T14:02:14Z

@dioannidis

You can also use my mingw64 build if you prefer.
https://github.com/mcuee/avrdude/releases/tag/snapshot_21Apr2023

dioannidis · 2023-04-21T14:04:35Z

@mcuee

I'll try both ;) ... Thx !

dioannidis · 2023-04-25T13:28:41Z

@mcuee

Both avrdude mingw64 builds ( yours and avrdude main ) are working fine with the composite firmware ! Thx !

mcuee · 2023-04-25T13:36:37Z

@mcuee

Both avrdude mingw64 builds ( yours and avrdude main ) are working fine with the composite firmware ! Thx !

Wondeful.

I will try your modified FW once I get the AT89S52 chip.

dioannidis · 2023-04-25T13:38:09Z

@llinjupt

@mcuee IMHO, if the programmer doesn't support setting reset polarity, that's impossible to do so. And there are more other strange chips like S2051/AT89S8252/AT89S8253 that behave pretty differently,

< snip >

Fortunately for the USBasp improved firmware to support the AT89S51/2 ICs only the following lines has to be added to ispEnterProgrammingMode() :

           ...
           ...

            /* AT89* Probe */
            
            ISP_OUT |= (1 << ISP_RST);      /* RST high */
            clockWait(5);                   /* 1.6 ms */
            
            spiTx(0xAC);
            spiTx(0x53);
            spiTx(0);
            check = spiTx(0);

            if (check == 0x69) 
                return 0;
            
        } while (--tries);

       ...
       ...

dioannidis · 2023-04-25T13:52:32Z

@llinjupt, @orbanp

@mcuee

< snip >

I will try your modified FW once I get the AT89S52 chip.

As I don't use MCS-51 MCUs, I adapted a basic blink assembly program and used the Microchip's c51asm assembler to produce a 27 bytes binary .

Please if it's possible test it with a bigger binary to see if there is a problem .

dioannidis · 2023-05-06T20:51:23Z

@mcuee

I will try your modified FW once I get the AT89S52 chip.

That file will be deleted . Please use the firmware binaries from the 1.11 pre release from today !

I re uploaded them, because they were corrupted :( See Corrupted firmware binaries in 1.11 pre Release assets

mcuee · 2023-05-07T01:24:16Z

@dioannidis

Thanks. I just got AT89S51 chip. The first test shows it works well.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p at89s51
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e5106 (probably 89S51)

avrdude done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p at89s51 -U .\entest.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e5106 (probably 89S51)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file .\entest.hex for flash
         with 512 bytes in 1 section within [0, 0x1ff]
avrdude: writing 512 bytes flash ...
Writing | ################################################## | 100% 1.32 s
avrdude: 512 bytes of flash written
avrdude: verifying flash memory against .\entest.hex
Reading | ################################################## | 100% 0.61 s
avrdude: 512 bytes of flash verified

avrdude done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p at89s51 -t
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e5106 (probably 89S51)
avrdude> dump flash
Reading | ################################################## | 100% 0.45 s
0000  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
0010  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
0020  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
0030  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
0040  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
0050  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
0060  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
0070  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
0080  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
0090  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|
00a0  65 72 20 74 68 65 20 6c  61 7a 79 20 64 6f 67 0a  |er the lazy dog |
00b0  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
00c0  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
00d0  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
00e0  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
00f0  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
avrdude> dump flash
Reading | ################################################## | 100% 0.45 s
0100  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
0110  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
0120  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
0130  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
0140  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|
0150  65 72 20 74 68 65 20 6c  61 7a 79 20 64 6f 67 0a  |er the lazy dog |
0160  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
0170  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
0180  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
0190  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
01a0  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
01b0  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
01c0  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
01d0  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
01e0  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
01f0  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|
avrdude> quit

avrdude done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p at89s51 -t
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e5106 (probably 89S51)
avrdude> part
AVR Part                      : AT89S51
Chip Erase delay              : 250000 us
RESET disposition             : dedicated
RETRY pulse                   : SCK
Serial program mode           : yes
Parallel program mode         : yes
Timeout                       : 200
StabDelay                     : 100
CmdexeDelay                   : 25
SyncLoops                     : 32
PollIndex                     : 4
PollValue                     : 0x69
Memory Detail                 :

                                  Block Poll               Page                       Polled
  Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
  ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
  flash                   2    10   256    0 no       4096    1      0  4500  4500 0xff 0xff
  lock                    0     0     0    0 no          1    1      0     0     0 0x00 0x00
  signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00
avrdude> dump lock
Reading | ################################################## | 100% 0.00 s
0000  00                                                |.               |
avrdude> dump signature
Reading | ################################################## | 100% 0.01 s
0000  1e 51 06                                          |.Q.             |
avrdude> quit

avrdude done.  Thank you.

mcuee · 2023-05-07T01:26:46Z

@orbanp

Please give the FW from @dioannidis a try. It seems to work pretty well. I am using latest avrdude git main (built using MSYS2 mingw64).

mcuee · 2023-05-07T01:42:10Z

No issues with AT89S52 as well.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p at89s52 -U .\entest.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e5206 (probably 89S52)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file .\entest.hex for flash
         with 512 bytes in 1 section within [0, 0x1ff]
avrdude: writing 512 bytes flash ...
Writing | ################################################## | 100% 1.30 s
avrdude: 512 bytes of flash written
avrdude: verifying flash memory against .\entest.hex
Reading | ################################################## | 100% 0.64 s
avrdude: 512 bytes of flash verified

avrdude done.  Thank you.

orbanp · 2023-06-03T16:58:29Z

Sorry for the late reply, I was away travelling.
Also thanks for the continuing efforts regarding AT89S52 programming!

Writing the AT89S52 chip is working now, however, reading back the code from the chip I get something different!
I updated my usbasp programmer with the "usbasp improved" firmware from dioannidis.
I used avrdude version 7.1-20230306 (6c8f7e1) on ubuntu 22.04.

As mentioned reading back the written code from the chip results in something different, writing it back again the processor does not work as it is supposed.
The code that works was produced by the MCU 8051 IDE programming environment.
I am wondering if the hex file formats are different, ihx vs. hex, I have not really looked into this yet.

Thanks, Peter

dioannidis · 2023-06-03T20:06:22Z

@orbanp

Could you please test with the -B x option ( i.e. -B9 or -B11 ) ?

1      /* 500 Hz */
2      /*   1 kHz */
3      /*   2 kHz */
4      /*   4 kHz */
5      /*   8 kHz */
6      /*  16 kHz */
7      /*  32 kHz */
8      /*  93.75 kHz */
9      /* 187.5  kHz */
10    /* 375 kHz   */
11    /* 750 kHz   */
12    /* 1.5 MHz   */

There is a bug that I couldn't find time to tackle yet .... Error in read after entering PE with slow clocks

orbanp · 2023-06-04T14:45:07Z

The chip runs at 12MHz.Reading the chip with the -B9 or -B11 option the read files are identical, though they are different from the one read without the -B option.Writing back the "-B11" read file the code works. (Did not test with the "-B9" file.) So it looks like for the correct reading the speed option is required. Thanks, Peter On Saturday, June 3, 2023 at 04:06:33 p.m. EDT, dioannidis ***@***.***> wrote: @orbanp Could you please test with the -B x option ( i.e. -B9 or -B11 ) ? 1 /* 500 Hz */ 2 /* 1 kHz */ 3 /* 2 kHz */ 4 /* 4 kHz */ 5 /* 8 kHz */ 6 /* 16 kHz */ 7 /* 32 kHz */ 8 /* 93.75 kHz */ 9 /* 187.5 kHz */ 10 /* 375 kHz */ 11 /* 750 kHz */ 12 /* 1.5 MHz */ There is a bug that I couldn't find time to tackle yet .... Error in read after entering PE with slow clocks — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

dioannidis · 2023-06-04T22:55:09Z

@orbanp, @mcuee

Can you test with this fw ~~https://github.com/dioannidis/usbasp/releases/download/v1.11/Firmware_ATMega8_12MHz_TPI_HIDUART_SNWRITE_FIX_LOW_SPEED.zip ?~~

( Tested with an atmega8 with hfuse 0xD9 and lfuse 0xE1 )

regards

dioannidis · 2023-06-05T09:02:51Z

@orbanp , @mcuee

The v1.11 is released

regards,

orbanp · 2023-06-05T11:14:20Z

It is working! I installed v1.11 into the usbasp.I changed in the Makefile the line from "ISP=snap_isp" to "ISP=usbasp". The read function initiates the SCK frequency to 32kHz.The read of the flash and writing it back works OK. Interestingly, the verification (read) part of the flash writing is a lot faster than the single flash read function. I would like to thank everyone to make the AT89S52 programming with avrdude and usbasp working! Regards, Peter

dioannidis · 2023-06-05T11:40:27Z

@orbanp, @mcuee

The read function initiates the SCK frequency to 32kHz.

How do you know that it starts with a 32kHz sck frequency ? You used the avrdude's -B option ? If you did please test without it .

The USBasp's probe function should start with a SCK frequency of 1.5 MHz, trying 3 times ( for both AVR and AT89S* , so it's a little bit slower ), going lower if it didn't get a valid response .

It is working!

I'm glad that it worked !

PS: ( If your USBasp device exposes the RxD/TxD signals to the connector, you can test the HID UART functionality of the firmware using the USBaspHIDUART utility. See also UART HID protocol ) .

regards,

orbanp · 2023-06-05T16:20:57Z

Leaving out the speed option the reading and writing still works OK!You are correct, I accidentally left in the speed option from yesterday, I have saved the avrdude commands for testing in a text file. According to the documentation usbasp does have the RXD/TXD signals at the ISP connector, however the board (a kit) with the AT89S52 chip does not have those signals connected. I guess I could put those in if I wanted... The kit originally came with a Chinese STC clone processor, that uses a different programming protocol from Atmel's using the RXD/TXD signals. I replaced the STC chip with the Atmel processor. I guess I could test the USBaspHIDUART utility with that STC chip too.Programming the STC chips there is also the stcgal tool for that (I have not used it). Regards, Peter On Monday, June 5, 2023 at 07:40:38 a.m. EDT, dioannidis ***@***.***> wrote: @orbanp, @mcuee The read function initiates the SCK frequency to 32kHz. How do you know that it starts with a 32kHz sck frequency ? You used the avrdude's -B option ? If you did please test without it . The USBasp's probe function should start with a SCK frequency of 1.5 MHz, trying 3 times ( for both AVR and AT89S* , so it's a little bit slower ), going lower if it didn't get a valid response . It is working! I'm glad that it worked ! PS: ( If your USBasp device exposes the RxD/TxD signals to the connector, you can test the HID UART functionality of the firmware using the USBaspHIDUART utility. See also UART HID protocol . regards, — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

mcuee added the question Further information is requested label Feb 7, 2023

mcuee closed this as completed Feb 8, 2023

mcuee reopened this Mar 4, 2023

mcuee changed the title ~~Programmer type?~~ AT89S52 support for avrdude Mar 4, 2023

mcuee added enhancement New feature or request and removed question Further information is requested labels Mar 4, 2023

mcuee changed the title ~~AT89S52 support for avrdude~~ AT89S51 and AT89S52 support for avrdude Mar 4, 2023

dioannidis mentioned this issue Mar 30, 2023

AT89S51 and AT89S52 support dioannidis/usbasp#18

Closed

mcuee reopened this Mar 31, 2023

mcuee closed this as completed Apr 2, 2023

AT89S51 and AT89S52 support for avrdude #1304

AT89S51 and AT89S52 support for avrdude #1304

Comments

orbanp commented Feb 7, 2023 • edited by mcuee Loading

MCUdude commented Feb 7, 2023

orbanp commented Feb 7, 2023

MCUdude commented Feb 7, 2023

mcuee commented Feb 8, 2023

llinjupt commented Mar 4, 2023

llinjupt commented Mar 4, 2023

mcuee commented Mar 4, 2023 • edited Loading

mcuee commented Mar 4, 2023

mcuee commented Mar 4, 2023 • edited Loading

stefanrueger commented Mar 4, 2023 • edited Loading

stefanrueger commented Mar 4, 2023

llinjupt commented Mar 4, 2023 • edited Loading

stefanrueger commented Mar 4, 2023

llinjupt commented Mar 4, 2023

stefanrueger commented Mar 4, 2023 • edited Loading

stefanrueger commented Mar 4, 2023 • edited Loading

llinjupt commented Mar 5, 2023 • edited Loading

stefanrueger commented Mar 5, 2023 • edited Loading

stefanrueger commented Mar 5, 2023

stefanrueger commented Mar 5, 2023

llinjupt commented Mar 6, 2023

llinjupt commented Mar 6, 2023

orbanp commented Mar 6, 2023 • edited Loading

llinjupt commented Mar 30, 2023 • edited Loading

mcuee commented Mar 30, 2023

dioannidis commented Mar 30, 2023 • edited Loading

mcuee commented Mar 31, 2023 • edited Loading

llinjupt commented Mar 31, 2023

stefanrueger commented Apr 2, 2023

mcuee commented Apr 2, 2023

dioannidis commented Apr 21, 2023 • edited Loading

mcuee commented Apr 21, 2023

mcuee commented Apr 21, 2023

dioannidis commented Apr 21, 2023

dioannidis commented Apr 25, 2023 • edited Loading

mcuee commented Apr 25, 2023 • edited Loading

dioannidis commented Apr 25, 2023 • edited Loading

dioannidis commented Apr 25, 2023 • edited Loading

dioannidis commented May 6, 2023 • edited Loading

mcuee commented May 7, 2023 • edited Loading

mcuee commented May 7, 2023

mcuee commented May 7, 2023

orbanp commented Jun 3, 2023

dioannidis commented Jun 3, 2023

orbanp commented Jun 4, 2023 via email

dioannidis commented Jun 4, 2023 • edited Loading

dioannidis commented Jun 5, 2023

orbanp commented Jun 5, 2023 via email • edited by mcuee Loading

dioannidis commented Jun 5, 2023 • edited Loading

orbanp commented Jun 5, 2023 via email

orbanp commented Feb 7, 2023 •

edited by mcuee

Loading

mcuee commented Mar 4, 2023 •

edited

Loading

mcuee commented Mar 4, 2023 •

edited

Loading

stefanrueger commented Mar 4, 2023 •

edited

Loading

llinjupt commented Mar 4, 2023 •

edited

Loading

stefanrueger commented Mar 4, 2023 •

edited

Loading

stefanrueger commented Mar 4, 2023 •

edited

Loading

llinjupt commented Mar 5, 2023 •

edited

Loading

stefanrueger commented Mar 5, 2023 •

edited

Loading

orbanp commented Mar 6, 2023 •

edited

Loading

llinjupt commented Mar 30, 2023 •

edited

Loading

dioannidis commented Mar 30, 2023 •

edited

Loading

mcuee commented Mar 31, 2023 •

edited

Loading

dioannidis commented Apr 21, 2023 •

edited

Loading

dioannidis commented Apr 25, 2023 •

edited

Loading

mcuee commented Apr 25, 2023 •

edited

Loading

dioannidis commented Apr 25, 2023 •

edited

Loading

dioannidis commented Apr 25, 2023 •

edited

Loading

dioannidis commented May 6, 2023 •

edited

Loading

mcuee commented May 7, 2023 •

edited

Loading

dioannidis commented Jun 4, 2023 •

edited

Loading

orbanp commented Jun 5, 2023 via email •

edited by mcuee

Loading

dioannidis commented Jun 5, 2023 •

edited

Loading