Using usbasp and avrdude to program 89s52


I’m working on a project that requires the use of an 89s52. Well, it requires a 8051 footprint compatible part but I want In-System-Programability (ISP). So I need to be able to program the 89s52.

The cheap options for programming 89s52 parts are not that well documented on the web. More important, I already have a usbasp. Google’ing hints that it should be possible to program these guys with a usbasp, but there is lots of conflicting information.


Well, it is possible, but it requires some adjustments to the usbasp firmware and some additions to avrdude’s conf. The setup I’m describing is this post is one I’ve used to successfully program an 89s52 and an ATMega328p. Hopefully, no existing functionality is lost.

The firmware here has my changes.

I also have it here untar’ed:

This is my avrdude.conf file:


What did I do?

I started with the information here: In particular, it contains a link to a version of usbasp firmare that should work, but I wasn’t able to get it to work. I can’t really say I tried super hard. The issue I had was the it seemed incompatible with recent avrdude versions. Given my new familiarity with the firmware quoted, it should work.

Anyway, the modified firmware was done on top of the original 2005 firmware. I took that diff and applied it to the most recent 2011 version. This process was pretty educational. There are a bunch of statements out there that are misleading, so I’ll try to dispell some of the. To be clear, I take no credit for any of the changes. I just merged to latest and tweaked a wee bit. The main point is that the version posted here works for me using avrdude 5.10 and a cheap ebay usbasp on 89s52 and ATMega328p. This the command I used:

 avrdude -c usbasp  -p 8052 -b 200 -U flash:w:blink.hex:i

It’s just the reset signal. One common statement that’s made is about how the 89s52 (and all other 8051 parts) reset signal is active high whereas most modern microcontrollers are active low. While this is true, it’s not enough to invert reset. There are several other ways that the usbasp assumes it’s dealing with normal AVR parts that also have to be addressed.

Is anyone out there? The most important trick that these modifications add is a stronger dependency on calling out to the part: "are you an AVR part?" Silence. Ok are you an 89s part? These calls are referred to as "Program Enable" in the datasheets and they are done differently between the two familes. In particular, AVR parts respond on the third byte. 89S parts respond on the 4th. Also, the responses are different. Again, the usbasp knows what it’s calling out to and it’s expecting a certain response. No amount of inverting changes that. It’s a neat trick though. Flash reset, try AVR call/response. Try flashing reset again (this time active high) and try 89S. I could imagine extending this trick further for other products that support serial programming

Change programming assumptions. Once this call/response process matches a product family, the usbasp will know what it’s dealing with and apply the proper assumptions; ones that are appropriate to that part. All of that can be taken into account.

  • Read and write are a bit different. The address component of a read/write instruction is shifted over one. sort of.
  • AVR parts can be programmed using the hardware serial support. usbasp can communicate with this or it has a software implementation. The 89S52 I tried it with didn’t seem to like the hardware way, but software works well.


usbasps can be purchased off of ebay for less than $4 delivered to American doors. You really can’t beat that. I suggest getting more than one. You can use one to program the other, but more interesting, you could reprogram them to do non-flash programming functions. Two or three AA batteries and you have a 4 I/O microcontroller. I haven’t tried this yet, but $4 is certainly less than Arduinos cost. Puts them in "Jelly Bean Part" territory.

I think this is potentially one of my more useful blog posts. If you find it helpful, please do comment and let me know. I’d be curious to hear what projects folks are working on.






6 thoughts on “Using usbasp and avrdude to program 89s52”

  1. It’s an intriguing looking board but but at $199, it seems expensive.

    I’ve worked with the old serial cable based mindstorms and it’s very nice. I would guess that the NX update is a great buy. That’s the direction I would go.

  2. thanks dude,,,,,,,for this post,,,,,really helpful…i also visited the same post & has same problems………now its done ……..thanks ………

  3. I tried your firmware hoping that since it could program the 89S52 it could also program the 89S4051. The firmware caused the LED’s to quit working on the USBASP programmer (bought on email, very common (LC Soft Technology).

    Reprogrammed with the “standard” hex file and programmers were revived (except for one, which I think is more a failure at the uC level than any firmware).

    Thanks for your efforts and maybe one day I can find the magical hex file that will allow me to program the 89S4051.

  4. I know this post is from 5 years ago but I’m hoping you might have an answer as I’ve search and searched. As you said there is a lot of conflicting information. I’m trying to use an USBASP with AVRDUDE to program a AT89S8252. From my understanding it’s an odd ball. A 8051 based chip with eeprom and ISP. My main issue is trying to access the eeprom. I’m pretty sure it’s an issue with the AVRDUDE config file but I haven’t figured it out. Any help would be much appreciated!

    1. Hi Jon,
      looking at the datasheets, I see some similarities between your part and the one I used (89s52). Our parts both want RST to be high. I believe that’s controlled in the function (of usbasp) ispConnect. The 328p used in many arduinos wants low. My part and the 328p have 4 byte programming codes but return a 0x53, mine on the 4th byte, 328 on the third (though you have to read the text to know that “the second byte (0x53), will echo back when issuing the third byte of the Programming Enable”. Your datasheet has no mention of 0x53 though is does mention that you should use the 89s53 but sadly, its programming interface is the 4 byte one, also with no mention of 0x53. Not all hope is lost, however, the important part of usbasp code is isp.c which weighs in at only 335 lines. Note that in order to update firmware on usbasp, you need a second one, or an arduino. Pretty simple though. Just connect the two with the ribbon and set the jumper of the one being programmed.
      Hope that helps, and thanks for commenting. It’s good to know that folks out there read my blog.

Leave a Reply

Your email address will not be published. Required fields are marked *