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 www.mmccoo.com/electronics/usbasp.2012-07-20_89s52.tgz has my changes.

I also have it here untar’ed: www.mmccoo.com/electronics/usbasp.2012-07-20_89s52

This is my avrdude.conf file: www.mmccoo.com/electronics/avrdude.conf

 

What did I do?

I started with the information here: www.8051projects.info/content/8051-tools/14-usb-8051-avr-programmer.html. 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.

 

 

 

 

 

Updating the firmware of a usbasp

 

This post is mostly for my personal reference and my "regular" readers will probably not care.

I want to program a 89s52 microcontroller. I could buy a specialty programmer, but I already have a usbasp. The issue is that the usbasp that I have came with the original firmware. There’s a newer version that supports 89s52 chips. To update it, I need another programmer. I could buy a second usbasp but I don’t want to wait for it to arrive from the usual chinese ebay sellers. (cost is not the issue since they cost $3.77 delivered)

Instead, I’ll use my Arduino.

So here is the sequence of steps:

  1. open arduino SDK and load the ArduinoISP sketch from file->examples
  2.  compile and upload
  3. The comment section of the ISP sketch describes which pin is which.
  4. you need to connect the J2 jumper. In my case, I don’t have header, so I just used a piece of wire.
  5.  I found that it wasn’t obvious which pin of the ribbon cable connects to what on the usbasp
    1. If you’re looking at the ribbon connector, the tab is up and the ribbon goes left. Going from away from you to nearer, the connections are Miso, sclk, reset, unconnected, Mosi. The pin beneath the far pin Miso, is gnd and the pin beneath the close pin is pwr.
  6. To test, I first read the existing code:
    1. avrdude -c avrisp -P com3 -p atmega8 -b 19200 -U flash:r:abc2.hex:i
  7. To write:
    1. avrdude -c avrisp -P com3 -p atmega8 -b 19200 -U flash:w:usbasp.atmega8.2011-05-28.hex

This is the output I got:
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.09s

avrdude: Device signature = 0x1e9307
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 "usbasp.atmega8.2011-05-28.hex"
avrdude: input file usbasp.atmega8.2011-05-28.hex auto detected as Intel Hex
avrdude: writing flash (4700 bytes):

Writing | ################################################## | 100% 8.32s

avrdude: 4700 bytes of flash written
avrdude: verifying flash memory against usbasp.atmega8.2011-05-28.hex:
avrdude: load data flash data from input file usbasp.atmega8.2011-05-28.hex:
avrdude: input file usbasp.atmega8.2011-05-28.hex auto detected as Intel Hex
avrdude: input file usbasp.atmega8.2011-05-28.hex contains 4700 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 5.78s

avrdude: verifying …
avrdude: 4700 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.