logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Programming AT89S5x chips with USBasp

Mlody_Zdolny 8028 15
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
Listen:
  • Programming AT89S5x chips with USBasp
    In older electronic equipment that has been withdrawn from use, you can find interesting elements, including various types of microcontrollers.
    Although nowadays 32-bit microcontrollers with high computing power and network interfaces are easily available for a small amount of money, sometimes an older 8-bit chip, obtained, for example, from a device intended for disposal, may be enough to implement the project.
    Particularly interesting are the 89S5x chips from Atmel. These are devices belonging to the 8051 family, equipped with an ISP interface (the letter S in the designation), which today is nothing unusual and even a norm, however, it should be remembered that other devices from this family could only be programmed in parallel (e.g. AT89C51 , not to mention non-flash versions).

    I was starting to design a DCF77 clock with a programmable controller function and I was looking for a suitable processor.
    Since I have several 89S52 systems from disassembly in my collection, I decided to use them for this purpose. In order for the development process to run in accordance with current standards, of course I wanted to use ISP for programming. It turned out, however, that all AVR programmers that I have are not able to communicate with the 89S52 in a serial way.

    Programming AT89S5x chips with USBasp

    A short web search led me to the USBasp project: https://www.fischl.de/usbasp. Within a few hours, a prototype with ATmega8 was created, mounted on a universal board. The launch went without a problem, the avrdude program detected the programmer.
    Unfortunately, when trying to read the content of 89S52, I got the following message:
    Code: Bash
    Log in, to see the code

    Something was wrong with the communication on the USBasp - AT89S52 line.
    Debugging with an oscilloscope and searching the web yielded the answer. The problem was that USBasp had a hardcoded procedure for setting the RESET pin on the ISP interface. The AVR chips have a negated RESET input, while the 89S5x chips have a non-negated input. In other words, the RESET active state for AVR is low, for 89S5x it is high.

    The author of USBasp has placed sources on his website where you can find the reason for this state of affairs:
    [syntax=c]void ispConnect() {

    /* all ISP pins are inputs before */
    /* now set output pins */
    ISP_DDR |= (1
    Attachments:
    • asbasp-89s52.zip (5.2 KB) You must be logged in to download this attachment.

    Cool? Ranking DIY
    About Author
    Mlody_Zdolny
    Level 31  
    Offline 
    Mlody_Zdolny wrote 1439 posts with rating 644, helped 109 times. Been with us since 2022 year.
  • ADVERTISEMENT
  • #2 20541300
    Zubiik
    Level 15  
    Posts: 168
    Help: 1
    Rate: 52
    Thanks to you, I can finally revive my procs, thanks!
  • #3 20541429
    pawlik118
    Level 34  
    Posts: 2432
    Help: 202
    Rate: 610
    Hi, can the 89LP2052 also be programmed with this modified USBasp? Is there a list of compatible chips somewhere?

  • avrdude lacks support for 89LP2052 programming

    #4 20541514
    Mlody_Zdolny
    Level 31  
    Posts: 1439
    Help: 109
    Rate: 644
    pawlik118 wrote:
    Hi, can the 89LP2052 also be programmed with this modified USBasp? Is there a list of compatible chips anywhere?

    Hi
    I use avrdude version 6.3-20171130 to operate the programmer.
    Unfortunately, the list of supported microcontrollers does not include the one you are asking about.
    In general, the case looks dull, because this list contains only one type from the 89x family
    Code: text Expand Select all Copy to clipboard
    Valid parts are:
  uc3a0512 = AT32UC3A0512
  8052     = AT89S52
  c128     = AT90CAN128
  c32      = AT90CAN32 (...)

    Newer versions of avrdude, including the latest 7.1, no longer support any of the older CPUs from what I can see.

    The programmer itself would probably be able to program it, but you would have to add such functionality to avrdude.
    Perhaps other software is able to program, but I do not know one.
  • ADVERTISEMENT
  • #5 20541544
    gulson
    System Administrator  
    Posts: 29533
    Help: 150
    Rate: 6128
    Great, write to me for a small gift.
  • #6 20541669
    ArturAVS
    Moderator  
    Posts: 26435
    Help: 2303
    Rate: 7852
    A few years ago I managed in a simpler way (as for me), I added a single 74HC1G14 gate and a jumper that switches the RESET signal (typical or negated depending on the programmed uC).
  • ADVERTISEMENT

  • USBasp firmware supports AT89S51 and AT89S52

    #7 20541930
    Mamut
    Level 19  
    Posts: 308
    Help: 22
    Rate: 48
    erm... Some time ago I made this firmware:
    https://github.com/mamut-tme/UsbAsp-flash_89S52

    Support for s51 and s52 works in it without any problems.

    Patch speeding up sck (it's more for AVR, s51/52 doesn't work with such a fast clock) for avrdude has been merged into the main repo in the meantime. It was a project I made during covid self-isolation, unfortunately my only target at89s52 died at the end, so I didn't have time to optimize everything.

  • Original Eclipse project does not compile

    #8 20546436
    Wirnick
    Level 30  
    Posts: 1774
    Help: 72
    Rate: 240
    @Mlody_Zdolny I downloaded your sources and put together the project with the original files, but it doesn't compile in Eclipse.
    Even the original projects don't compile - something is missing (and I'm definitely low on oil).
    Screenshot of a compilation error in Eclipse for an AVR project.
    I'll add more points for your project's binary to resuscitate some old CPUs.
    I will be grateful if you share the results of your work.
  • #9 20546567
    Mlody_Zdolny
    Level 31  
    Posts: 1439
    Help: 109
    Rate: 644
    @Wirnick I am compiling in my linux environment (Mint Vera 21.1) using the latest versions of tools around gcc and avr. I use Makefile to compile by running the following command in the firmware directory:

    Code: Bash
    Log in, to see the code
  • #10 20546627
    Wirnick
    Level 30  
    Posts: 1774
    Help: 72
    Rate: 240
    @Mlody_Zdolny thank you very much for your response, but the .hex file is independent of the development environment. I am currently programming in MPLAB (after the acquisition of Atmel by Microchip). I'm going into the new without forgetting about the history of e-waste. In our case, the hexe is determined by avrdude.
  • ADVERTISEMENT
  • #11 20546667
    Mlody_Zdolny
    Level 31  
    Posts: 1439
    Help: 109
    Rate: 644
    Wirnick wrote:
    but the .hex file is development environment independent

    Yes, but the tools with which hex is created depend on the environment. There are versions for Linux and Windows, so I gave a short description of my configuration. MplabX can use xc8, but so can gcc. Avrdude, on the other hand, is a program that supports the USBasp programmer using USB control commands.
  • #12 20546779
    Wirnick
    Level 30  
    Posts: 1774
    Help: 72
    Rate: 240
    As usual, I turned around. I was thinking AVR Toolchain and wrote avrdude. Am I to understand that you will no longer share the fruits of your labor?

  • Adding const to usbdrv files fixes compilation

    #13 20546838
    Mlody_Zdolny
    Level 31  
    Posts: 1439
    Help: 109
    Rate: 644
    Wirnick wrote:
    Am I to understand that you will no longer share the fruits of your labor?

    I can share the hex, but in general I think that the sources carry more value, because everyone can change something according to their needs. I'll send something tonight.

    Perhaps the compilation problem is in the usbdrv.* files where you just need to add 'const', for example:
    PROGMEM const char usbDescriptorString0[].
    I attach files with this modification and hexa.
    Attachments:
    • usbdrv.h (30.22 KB) You must be logged in to download this attachment.
    • usbdrv.c (24.1 KB) You must be logged in to download this attachment.
    • main.hex (12.67 KB) You must be logged in to download this attachment.

  • Automatic AVR and AT89S5x detection in USBasp firmware

    #14 20547726
    Mamut
    Level 19  
    Posts: 308
    Help: 22
    Rate: 48
    hex to my firmware variant (link above). It does not require any modification of the original USBasp schema.
    Detecting whether it is s5x or avr is automatic. Target initialization tries AVR first, then s5x. Comments in the code may look strange, but it's a combination of two different solutions, there is also i2c and spi (and microwire?) support for serial memory (there is software on the repo, but to be honest, I haven't checked it).
    Attachments:
    • main.hex (17.61 KB) You must be logged in to download this attachment.

  • Include path fix and F_CPU change enabled programming

    #15 20548000
    Wirnick
    Level 30  
    Posts: 1774
    Help: 72
    Rate: 240
    @Mlody_Zdolny thank you very much and you are my Friend!
    I have achieved success as shown in the attached picture. I made a correction in the #include paths in the file main.ci usbdrv.h and in the file clock.h I changed to //#define F_CPU 12000000L /* 12MHz */ . At the same time, the file.eep is created, which also needs to be uploaded to AT8 (I think).

    Programming AT89S5x chips with USBasp

    I am building a programmer.
    Regards
    Wirnick

    @Mamut I am also interested in your project due to the ability to read and program very many circuits. I am programming in Delphi 10.1 Berlin. Is it possible to transfer your program project to my platform?

  • USBasp code uses mixed sources and custom SCK modes

    #16 20548804
    Mamut
    Level 19  
    Posts: 308
    Help: 22
    Rate: 48
    Wirnick wrote:
    @Mamut I am also interested in your project due to the ability to read and program very many circuits. I am programming in Delphi 10.1 Berlin. Is it possible to transfer your program project to my platform?

    Unfortunately, I can't help much with that. As it says in the github repo description, my code is a combination of a solution from some nofeletru (from Moscow) and Miles McCoo (from a defunct site, but you can still access it via archive.org). I modified many parts of the code from Miles, because the s5x support was quite slow and that's what I mainly worked on - I added paged mode reading (checked) and paged mode (unchecked) and a few other improvements based on the analysis of documentation from AT89S51/52. However, from the code from nofeletru I "gave" 3 MHz SCK for AVR (original USBasp does not have it) and added my own 6 MHz, but it will only work with 20 MHz quartz chips, and after changes in procs, as they were still Atmela, I do not know if some others can work with this frequency (once I think ATTiny2313 could, there were others, but I don't remember). I haven't touched the serial memory part, it's unchanged.
    As I wrote, it was a "covid" project for me, I had some elements at home and I made use of them. Then the only S52 died, I went back to work and the project went into a drawer.
Reply Cool? Ranking DIY | New topic
Notify about new articles
Listen:
Report a violation of the law

Topic summary

LABEL_AI_GENERATED
The discussion revolves around programming AT89S5x microcontrollers from Atmel using a USBasp programmer. Users share experiences and solutions for reviving older microcontrollers, particularly focusing on the compatibility of various chips with the USBasp and avrdude software. One user inquires about programming the 89LP2052 chip, but it is noted that avrdude's support for older microcontrollers is limited. Several users contribute by sharing firmware modifications and compilation tips, including a GitHub repository for USBasp firmware that supports AT89S52. The conversation highlights the challenges of compiling code in different environments and the importance of source code for customization. Users express gratitude for shared resources and successful programming outcomes.
AI summary based on the discussion. May contain errors.

FAQ LABEL_AI_GENERATED

TL;DR: For AT89S5x programming, 1 RESET polarity difference is decisive: “RESET active state for AVR is low, for 89S5x it is high.” This FAQ helps USBasp users fix AT89S52/AT89S51 ISP failures, choose firmware or inverter methods, and understand avrdude limits. [#20541080] Why it matters: One wrong RESET level can make a working USBasp report a dead AT89S52.

Approach Hardware change Firmware/software change Best use
Modified USBasp firmware No extra gate mentioned Yes, change RESET handling Dedicated AT89S5x work
74HC1G14 inverter with jumper 1 gate plus jumper No USBasp schema change required Switching between AVR and AT89S5x
Mamut firmware variant No original USBasp schematic change Yes, alternate firmware Automatic AVR then S5x target initialization

Key insight: USBasp can talk to AT89S5x devices only when target initialization drives RESET correctly. The thread’s core fix is not wiring complexity, but matching the active-high RESET used by AT89S51/52.

Quick Facts

  • AT89S5x devices are 8051-family microcontrollers with an ISP interface; the “S” in the designation marks serial programmability in this discussion. [#20541080]
  • The tested programmer used an ATmega8-based USBasp prototype, detected by avrdude within a few hours of assembly. [#20541080]
  • The confirmed failure message was program enable: target doesn't answer and initialization failed, rc=-1 during AT89S52 reading. [#20541080]
  • avrdude 6.3-20171130 listed 8052 = AT89S52, while avrdude 7.1 no longer showed older CPU support in the user’s check. [#20541514]
  • The Linux build environment named in the thread was Mint Vera 21.1, using make main.hex inside the firmware directory. [#20546567]

How do you program an AT89S52 or AT89S51 microcontroller using a USBasp programmer?

Use USBasp with firmware that handles AT89S5x active-high RESET. 1. Flash the modified USBasp firmware to the ATmega8 programmer. 2. Connect ISP lines to the AT89S52 or AT89S51 target. 3. Use avrdude 6.3 with the supported 8052 part entry for AT89S52. "ISP programming is a serial in-system programming method that writes a microcontroller without parallel programming, using target pins while the chip stays in its circuit." [#20541514]

Why does avrdude show “program enable: target doesn’t answer” when programming an AT89S52 with USBasp?

avrdude shows that error because the target AT89S52 does not enter serial programming mode. The thread identified the cause as USBasp firmware driving RESET like an AVR. AVR RESET is active-low, but AT89S5x RESET is active-high. The observed failure text included program enable: target doesn't answer and initialization failed, rc=-1. [#20541080]

What is the RESET signal difference between AVR chips and Atmel AT89S5x chips when using ISP programming?

AVR chips use active-low RESET, while AT89S5x chips use active-high RESET. The thread states this as the central electrical difference. USBasp originally assumed the AVR convention in its ISP connection routine. That hardcoded behavior blocks AT89S52 initialization unless firmware or hardware inverts the signal. [#20541080]

How can the USBasp firmware be modified to support AT89S5x microcontrollers with active-high RESET?

Modify USBasp firmware so its ISP connection routine drives RESET high for AT89S5x targets. The thread points to the USBasp source routine ispConnect() as the reason. The fix changes RESET handling rather than the SPI data lines. A posted variant also tries AVR initialization first, then S5x initialization automatically. [#20547726]

What is ISP programming and why is it useful for older 8051-family chips like the AT89S52?

ISP lets older AT89S52 chips be programmed serially without parallel programming hardware. "ISP programming is a serial in-system programming method that writes a microcontroller without parallel programming, using target pins while the chip stays in its circuit." The thread contrasts AT89S5x parts with AT89C51, which required parallel programming. That makes recovered 8-bit chips practical for small projects. [#20541080]

Which avrdude versions support the AT89S52, and why do newer versions like avrdude 7.1 cause problems?

avrdude 6.3-20171130 supports AT89S52 through the 8052 part entry. The thread user checked avrdude 7.1 and saw no support for older CPUs. That creates a software-side failure even if USBasp hardware can generate the needed signals. Use the older supported version when targeting AT89S52. [#20541514]

What AT89-family chips are supported by avrdude 6.3 when using USBasp?

avrdude 6.3-20171130 lists only one AT89-family entry in the thread: 8052 = AT89S52. The visible valid-parts list also includes unrelated entries such as uc3a0512, c128, and c32. No AT89LP2052 entry appeared in that checked version. [#20541514]

How would support for an AT89LP2052 need to be added to USBasp or avrdude?

AT89LP2052 support would need a new device definition and programming implementation in avrdude. The thread says the USBasp programmer itself could program it electrically. The missing part is software support, because avrdude 6.3 listed AT89S52 only. No working AT89LP2052 method appears in the discussion. [#20541514]

USBasp firmware modification vs 74HC1G14 RESET inverter — which approach is better for programming both AVR and AT89S5x chips?

A 74HC1G14 inverter plus jumper is better when one programmer must switch between AVR and AT89S5x. It adds 1 logic gate and selects normal or negated RESET. Firmware modification avoids extra hardware, but it targets the RESET behavior in code. The hardware jumper gives a visible, reversible mode choice. [#20541669]

How do you compile modified USBasp firmware with avr-gcc and Makefile on Linux Mint?

Compile it from the firmware directory with make main.hex. The named environment was Linux Mint Vera 21.1 with current gcc and AVR tools. The author used a Makefile instead of Eclipse. The output file main.hex then becomes the firmware image for the ATmega8-based USBasp. [#20546567]

What causes Eclipse or AVR Toolchain compilation errors in USBasp firmware sources, and how can adding const to PROGMEM descriptors help?

Compilation errors can come from toolchain expectations around USB descriptor declarations. The thread suggests adding const to PROGMEM arrays, for example PROGMEM const char usbDescriptorString0[]. One user also fixed include paths in main.c and usbdrv.h. These changes allowed a successful build shown on 2023-04-20. [#20546838]

What is the role of the main.hex and .eep files when flashing firmware to an ATmega8-based USBasp programmer?

main.hex stores the compiled program flash image for the ATmega8 USBasp. The .eep file stores EEPROM data generated during the same build. One user believed the .eep also needed uploading to the ATmega8. The thread does not prove every firmware variant requires EEPROM flashing. [#20548000]

How does Mamut’s UsbAsp-flash_89S52 firmware automatically detect whether the target is an AVR or AT89S5x chip?

It initializes the target as AVR first, then tries S5x if AVR initialization fails. The firmware variant supports S51 and S52, according to its author. It does not require modifying the original USBasp schematic. The code also includes serial memory support, but that part was not checked in the thread. [#20547726]

What SCK clock speeds are safe for programming AT89S51, AT89S52, and AVR chips with USBasp?

AT89S51 and AT89S52 should not use the very fast SCK modes discussed for AVR. The firmware author said S51/S52 do not work with such a fast clock. For AVR, his code added 3 MHz SCK and 6 MHz SCK. The 6 MHz mode requires chips with a 20 MHz quartz. [#20548804]

How difficult is it to port USBasp-related programming software or serial memory support code to Delphi 10.1 Berlin?

Porting to Delphi 10.1 Berlin is nontrivial because the author could not help with that platform. His code combined work from two earlier projects and added AT89S51/52 optimizations. He changed S5x read speed, added checked paged reads, and added unchecked paged programming. The serial memory part remained unchanged and unverified. [#20548804]
AI summary based on the discussion. May contain errors.
ADVERTISEMENT