FREE ISP programmer
Author: Simonetta ( )
Date:   Jan 2 04, 18:47

When I was in the same situation last year (after my 386-based AVR
programmer wouldn't work with a 1Gig Duron due to hard-wired
internal timing loops in the code) I switched to the SP12 programmer
with 'Ken's Dongle' (a 74hc126 buffer). Despite the dense and
somewhat hard-to-read documentation (at least it is solid accurate
documentation), the programmer does work both for Win98 and
Win2000Pro. It does include source and it is configurable for the
full range of AVRs.

We have to admit that the complaint above is justified,
to some extend. Sp12's documentation could be improved.
On the other hand, users don't always read what is provided,
even if docs are written very well...

The questions below are quoted from user's email. Some cases
are a matter of (not) reading the docs, but others are not and
some relate to things which sp12 and/or AVR uCs just happen to
do in their own quirky ways. We'll be adding to this page when
time permits.


par port mode problem?

This was said by someone who has been using sp12 for 7 years
(mail dated October 2006):

> First of all want to say that I am very grateful for this awesome and so
> reliable piece of software!
> (Thanks to your coworkers, too, very well done!)

Of course we love to hear that :)
But he also had a complaint:

> Sp12 did not work on my machine if you set the parallel port to
> bidirectional mode (...it was probably in input mode by chance).
> I looked over the sourcecode and saw that this is never checked 
> (..i.e., sp12 doesn't seem to check if Bit 5 of the parport
> control register is set).

True. At some point, I tried various bios options on various PCs,
bidirectional included, and all worked fine. One of my laptops (an
old OmniBook) is running its parallel port in bidirectional right
now, and sp12 doesn't mind at all. So there didn't seem to be a
reason for making sp12 refuse that mode.

> Maybe this could be changed or some of the readme files could say
> that one should try simple mode if things don't work...

While this problem remains elusive, It does indeed belong in the
FAQ. Usually, sp12 simply works as advertised, even with very simple
programming cables and various parallelport settings. But if your PC
happens to be an exception, try the bios setting which seems closest
to the original port spec, and include Ken Huntington's `dongle' in
your programming cable.


SP12 dangerous?

Quoted by an anxious Linux user:

> SP12 is an dangerouse and host specific binary, because it uses the  
> systemcall ioperm() to get access to parallel ports. So you can run
> SP12 only on x86 host systems and need root privilegs. Be warned, SP12
> can damage your running system!

Sp12 is indeed limited to x86 systems, and the program (not its
user) does require root permissions. The documentation says:

Note: To run sp12 you must have i/o permission on your system, so
run as root (not a good idea) or set sp12 permissions and ownership
like this:

-r-sr-xr-x 1 root root 53208 Jan 17 16:35 /usr/local/bin/sp12*

Which can be achieved by becoming root and using these commands:

chown root.root sp12
chmod 4555 sp12

Note that sp12 drops root permissions before accessing the file system,
so it should be secure enough for general use.

The latter is done right at the start of main():

    * Take control of LPT I/O ports
   if (ioperm(0x278,3,1)) {perror("ioperm error at 0x278");exit(1);}
   if (ioperm(0x378,3,1)) {perror("ioperm error at 0x378");exit(1);}
   if (ioperm(0x3BC,3,1)) {perror("ioperm error at 0x3BC");exit(1);}
    * Revoke setuid/setguid-root status

So I fail to see how sp12 can "damage your running system." It
certainly hasn't done any damage whatsoever to my LinuxBox, in many
years of frequent use...


Winzip and sp12 package

> Tried downloading sp12 for windows. Got an error from winzip
> telling me that there were 0 entries.
> Can you tell me what's going on here?

I answered:
As I don't use MSW, questions related to that OS can be hard to
answer. Perhaps winzip doesn't quite understand a gzipped tar. You
might try renaming the file:


Before giving it to winzip. Also, there is freeware called 7-Zip
which does understand .tgz, and no doubt there is also a gunzip
utility for MSW, to first undo the compression before giving the
.tar to winzip.

The person asking the question came back with:

> Actually I found it was a problem with Windows not Winzip.
> Here's a quick and easy fix for the problem to keep it out of XP/SP2's hands:
> - pull up the properties of the sp12
>   (currently http://www.xs4all.nl/~sbolt/Packages/sp12v2_1_0-Win32.tgz)
>   and copy it to the clipboard
> - open winzip and do the file open
> - copy the clipboard into the file name and hit enter.
>   That will get you the file un-tar'd.
>   Double clicking on the file will unzip it.
>   Hope this helps. It's a little bit hookie but better than
>   depending on other software.

My Tiny2313 doesn't work!

> I cannot program a ATTiny2313 with dongle STK200.
> the report is "Readback ERROR after 4 write retries."
> 11000100 are the high fuse bits read from an ATtiny2313
> 0xxxxxxx - debugWire enabled
> x0xxxxxx - EEPROM preserved in chip erase
> xx0xxxxx - serial programming enabled
> xxx0xxxx - WDT always on (page 41)
> xxxxBODx - BODLEVEL (page 34)
> xxxxxxx1 - reset-pin enabled (page 52)
> 11111111 are the fuse bits read from an ATtiny2313
> 0xxxxxxx - CKDIV8 - divide clock by 8 (page 22)
> x0xxxxxx - CKOUT output clock on pin D2
> xxSUxxxx - start-up time (datasheet page 24)
> xxxxCKSE - CKSEL (datasheet page 22-24)

Your fuse settings look odd. The BOD-setting appears to be 010,
which is `reserved', according to the datasheet. Even more strange,
RSTDISBL seems to be zero, which would prevent sp12 from accessing
the chip; it wouldn't even be able to read the fuses.

My guess is that these readings are wrong. I suspect it is a fresh
uC, not used before. In which case CKDIV8 is set, and the device is
running on an internal Clock of just 500KHz.
By default, sp12 expects its target to run on at least 700KHz (as
shown in _sp12rc) which is slow enough for most AVR factory defaults
at 5V. The Tiny2313 is an exception; but of course most of us look
up the clock and other fuse settings in the datasheet, before
touching a device, don't we :)

I suggest you try reading the fuses with the command:

sp12 -M0.1 -rF -rH -rX

If CKDIV8 now looks 0, you should write it to 1 - again with the
-M0.1 speed setting - and then once more attempt to upload your hex
file, with a speed setting appropriate for your target hardware.


XP timing problem solved, but not resolved

> Hello,
> Earlier I've used sp12 successfully to program an AT()S1200 using the 
> parallel-port dongle. 
> I'm now trying to program an ATtiny25 using sp12 in an XP Dosbox, 
> but sadly I've had no luck so far. The sequence:
> del _sp12rc
> sp12 -i    results in the attached _sp12rc.
> After uploading a program pwm.gen:
> C:\PROGRA~1\Atmel\SP12V2_1.1>*sp12 -pwf pwm.gen*
> SP12 version 2.1.1 performing init...
> Path to _sp12rc and _sp12dev: Local directory
> Running in SP12 cable/dongle compatible mode.
> Enabling AVR serial reading/programming...
> The device code bytes 0,1,2: 0x1e, 0x91, 0x8 were read
> from parallel port 0x3bc and indicate the following:
> You have connected an ATtiny25
> The device was made by Atmel
> Performing chip erase...
> Writing content of pwm.gen into program area.
> ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
> Readback ERROR after 3 write retries.
> Writing 0000 (0, B00000000) to the parallel port data bits.
> Sp12 was active for 2.09 seconds.
> downloading the flash gives me dump.gen, both attached.
> The XP version is 5.1.2600, the Dosbox priority-setting is
> "normal" and the pc is a 1200MHz AMD Athlon, with parallel-port
> set as SPP.

This looks very much like a timing error, and an sp12 -t run
seems to confirm that:

> C:\Program Files\Atmel\SP12V2_1.1>sp12 -t
> SP12 version 2.1.1 performing init...
> Path to _sp12rc and _sp12dev: Local directory
> Running in SP12 cable/dongle compatible mode.
> (-t)iming check, about 10 seconds
> oooooooooooooooooooooooooooooooooooooooooooooooooo STOP
> Writing 0000 (0, B00000000) to the parallel port data bits.
> *Sp12 was active for 12.20 seconds.

By this time - a few hours later - the user had resorted to compiling sp12
in the Cygwin environment:

> In desperation I recompiled sp12 in Cygwin. (You first have to
> compile and install the Cygwin package ioperm from source, and must 
> also add  -lioperm to the linker command for sp12.)
> Guess what: the new sp12 worked right away!!

The ioperm package does what giveio would do otherwise, giving
sp12 access to the parallel port. An sp12 -t run returned 10.56
seconds, which is sufficiently accurate.

So why did our sp12-package fail in this unremarkable XP machine?
I've no idea. It's so much easier when using Linux...


The strange case of the Tiny12

> When using sp12 for my software running on a Tiny12L
> I noticed a problem that is still valid for 2.1.0:
> as soon as my hex file has more than 255 contiguous
> bytes (starting at address 0, I didn't check for other
> configurations), I get the message:
> ooooooooooooooooooooooooooooooo!!..............................
> Readback ERROR after 3 write retries.
> I use as workaround the
> .ORG 0x100
> statement to enforce a gap in the hex-file.
> Then I'm able to program the device.

This is an odd one. I've used the Tiny12 occasionally and never
noticed anything amiss. But a fairly thorough test of one taken
randomly from a pipe reveals that it is reluctant to erase the
flash 16-bit word address 0x00ff. Unless the power supply is
switched off for a few seconds (long enough to drop Vcc close to
zero) before attempting erasure, that particular location retains
its value. For instance:

sp12 -M1.2 -wpf foo.hex
The device code bytes 0,1,2: 0x1e, 0x90, 0x5 were read
from parallel port 0x3bc and indicate the following:
You have connected an ATtiny12
The device was made by Atmel

Sck timing set for 1.1 MHz or higher.
Performing chip erase...
Writing content of foo.hex into program area.
foo.hex written and verified.
write retries: 0

Read the flash:

sp12 -M1.2 -rph | less
0000f8 bf 9c bf bf bf bf 01 01 01 01 01 01 00 01 01 01 ................

Attempt to erase without switching off the power supply:
(Sp12 slightly modified to show the offending location and its content)

sp12 -M1.2 -EB
Performing chip erase...
Performing blank check...
address 0x00ff, word 0x01ff
The program area is NOT blank.

Again read the flash:

sp12 -M1.2 -rph | less
0000f8 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 01 ff ................

More than one erase command makes no difference.
Now switch off the power supply, back on again, then erase:

sp12 -M1.2 -EB
Performing chip erase...
Performing blank check...
The program and eeprom area's are blank.

The test was done at Vcc = 4.5V, with BOD on at level 2.7V.
There is an erratum warning against operation at the 1.8V level,
but nothing regarding this programming malfunction. However, sp12
can't be blamed, as its erase command does nothing

> What do you think about the hint to
> - erase the chip
> - program 0xff to address 0x00
> - erase the chip once more
> as described on page 51 ?
> I tried it but that didn't solve the problem.

Missed that; so much for me advising other people to read the
datasheet. It indicates that the problem is known and not considered
to be a serious issue.
As to the failing remedy, sp12 -E -wpa 0:0xff -E didn't work for me
either, but switching off the power (and making sure that Vcc goes
all the way down) before erasing the flash does work, so there is a
reliable workaround.


_sp12dev for W98?

> Can the _SP12DEV file from the WIN2000 distribution
> be used with the WIN98 version of SP12.exe?

_sp12dev does not care about the operating system.
You'll find the same device file in all `official' sp12 packages.


Errors in _sp12dev

> There are few lines in the mega16 part of the file having the
> command different from the datasheet.
> So when programming the device, sp12 tells "READ_LOCK" command
> corrupted.
> FLASHSIZE = 16384
> Should be  8192 (in word)
> READ_LOCK = lhlh hlll llll llll xxxx lxxx hhii iiii
> In datasheet: lhlh hlll llll llll xxxx xxxx xxoo oooo
> WRITE_LOCK = hlhl hhll hhhh h21h xxxx xxxx xxoo oooo 
> In datasheet: hlhl hhll hhhx xxxx xxxx xxxx hhii iiii
> WRITE_FUSES = hlhl hhll hlhl llll xxxx xxxx oooo oooo 
> In datasheet: hlhl hhll hlhl llll xxxx xxxx iiii iiii
> READ_FUSES = lhlh llll llll llll xxxx xxxx iiii iiii
> In datasheet: lhlh llll llll llll xxxx xxxx oooo oooo

Actually, those errors were not found in the `official' _sp12dev
on sp12's home page. But such cut 'n paste mistakes and in particular
the byte/word confusion are quite common in the entries sent to us by
users. So there must be many invalid _sp12devs out there, which are
shared with others before being properly checked.
Not that bugs can't hide in our stuff, of course. Corrections are
certainly welcome.


Fuse commands

> I am occupying the program sp12 (win98), to program the ATmega16, I can 
> program it, but I cannot change the High fuse bits. I write the following
> command to change the high fuse bits:  
> Sp12 -wH11011001  
> and get "Wrong number of fuse bits." but the  data sheet of the atmega16  
> says that they are 8 bit (pag 260)  

If you check its _sp12dev entry, you'll see that the msb has been
set high:

WRITE_HIGH_FUSES = hlhl hhll hlhl hlll xxxx xxxx hili iiii

To disable OCD, see note 4 on page 260 of the datasheet.
As described in sp12dev.txt (part of the documentation in your
package), taking away bit-7 causes sp12 to expect a -wH string
which is seven bits long, for instance

sp12 -wH1011001

resulting in:

 1011001 are the high fuse bits written into an ATmega16
1xxxxxxx - Disable OCD (See note 4 p.260)
x0xxxxxx - Enable JTAG
xx0xxxxx - serial programming enabled
xxx0xxxx - CKOPT max, datasheet p27
xxxx0xxx - eeprom not erased
xxxxxBZx - boot size, datasheet p252
xxxxxxx0 - reset at boot loader, p255

Readback error

> sp12 -wpf IREIN.HEX
> The device code bytes 0,1,2: 0x1e, 0x91, 0x6 were read
> from parallel port 0x378 and indicate the following:
> You have connected an Tiny22L
> Performing chip erase...
> Writing content of IREIN.HEX into program area.
> !!.............................................................
> Readback ERROR after 3 write retries.

> what does this readback-error mean??

You are the second user in a few days who encounters trouble with
a Tiny22 and attempts to put IREIN.HEX into it. Not that the .hex
file has anything to do with it, but it's nevertheless an odd
coincidence. I'll assume that you are also using your parallel port
to provide Vcc for your target.

In that case, assuming your pcb is correct for the Tiny22, I suspect
that you are asking sp12 to program at default speed. That would be
fine if the Tiny22's clock actually ran at 1MHz. But modern parallel
ports supply only about 3V, which makes it run much slower - about
350KHz at Vcc=3V.

I suggest you try the command:

sp12 -M0.3 -wpf IREIN.HEX

And assuming that helps, you can adjust the default speed in _sp12rc,
if you like:

   # Set clockSpdDefault to a suitable value in MHz.

Do you plan to support...

> Do you plans to add ATMEGA8515 on SP12 programmer?

That was recently done by Christian Spahn. Please check


To make sure that you are referring to the latest _sp12dev.

As to other uCs; we're not using all of them ourselves. That is
why _sp12dev is a user-supported file, to which you can easily add
entries for uCs no one else got around to yet. When you write an
entry and mail me the result, I'll check your work and add it
to the _sp12dev offered on the page mentioned above.

Best regards,