Solutions to problems with STK200/300-programming dongles

Last post
53 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is the old thread: go to http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=36591 for the latest information (or go to http://www.aplomb.nl/TechStuff/PPPD/PPPD%20English.html)

EDITED March 4th 2006: additional info furtheron in this thread; please check it out; there are necessary modifications to the schematics

EDITED May 11th 2006: An abstract of this topic has been placed in the Tutorial Section: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=36591

Solutions to problems with STK200/300-programming dongles and alikes.

This time not a Question, just Answers

In the past there have been quite some articles about programming-problems with these dongles and other dongles with a simular design. I am talking about the AVR-programmers with a 74HC244 buffer, on the printer- (or parallel) port of the PC.

Two types of problems:
1 from: "does not recognize chip", ID="some rubbish",
to: it does not work, pls help ....
2 from: It damaged the printerport on my PC
to: it works on one printerport but not on an another

Good suggestions so far:
- Increase the programming-delay
- In BIOS: set printerport to EPP or ECP
- Use a shielded printercable
and other suggestions:
- Buy yourself a better programmer ... it is unreliable
- and some confusing suggestions ... that really do not help.

The story:

A few months ago, I purchased a STK200 with Kanda (UK). The board came with this programming dongle and it worked fine. Until the parallel port on the motherboard of my PC was damaged by the dongle.... Luckily I could fall back on a PCI-card which gave me another parallel port. But I was worried ..., and not pleased ...

For a new project with two Atmel uC's, I needed a second programmer. So I built one. The famous design with the 74HC244. And to suit my needs, I made it with another type of connector for the target-board. IT DID NOT WORK ! Why? Did I make a mistake? No, I did not ...

Hmmm.

In order to program the new targetboard (with the new connector), I made an adapter for the existing and working STK200-programming dongle. And with the new connector it DID NOT WORK EITHER !! Can a connector make the difference?

I was confused .... for a moment. I started searching on the Forums and discovered that I was not the only one ... But suggestions for a solution did not do the trick so far ... I do use a shielded cable, the BIOS-settings are OK, I increased the programming-dalay, etc

I decided to sort this out. And dig it out, .... to the bottom !

To start: I like the design with the HC244. It looks good. Well done, designer! The 74HC244 buffers the signals between PC and targetboard, and isolates the two when the programming is done.
Many people use this interface as it is cheap and easy to build. And is comfortable to use in combination with Bascom AVR.
Note: although some Forum-members claim that it is not supported in AVR-Studio-4 (the beautiful programming-environment from Atmel): sorry guys, that is not true! Kanda supplies a plug-in for AVR-Studio with the STK200 and it works fine! And comfortable.

Back to business:

Q. What makes this dongle unreliable?
A. LONG LINES, my friends!
Fourier, La Place, thank you for the insight. And thanks to my teachers! Although that's some time ago ...
The combination of short rise- and falltimes (high slewrate) on the signals and the (relative) long lines for these frequency-domains (using Fourier and La Place), that is what's making these dongles unreliable.

What I did:
I hooked up an oscilloscope to the SCK-line on the targetboard and it was obvious: RINGING, i.e. oscillations right after a fast transition of the SCK-line.

Q. What happens during programming in the original design?
A. The uC on the targetboard looses synchronization with the programmer. It sees more than one SCK-edge due to the ringing. And that's what I read some time before ... an Application Note from Atmel. AHA. Now things fall in place. The puzzle is complete, and the picture well visible.

I needed to get rid of the high-frequency-components generated by the edges. The trick: a small RC-filter of 0.1 us, made up with a resistor of 1 Kohm and 100 pF capacitor. That's all it takes: one small filter in the SCK-line. I built it into the STK200-dongle and ran some tests: problem solved. No longer dependant of connector/cable.
Built it into the second programming-dongle: works.
Hooked them up to another PC: works.

Let's go to the second problem:
Q. Why did the dongle blow the printerport on the motherboard?
A. I was not carefull enough.

Some explanation is needed here. The dongle is connected to targetboard and PC. Suppose both are powered down. When the targetboard is switched on, and the PC is not, the dongle will force current into the printerport's /Ack-line.
Q. Can that do any harm?
A. Yes!
To understand this, some historical facts about the printerport.
In the original IBM-design, the printerport was made up with a 74LS374 and a 74LS244. To blow that port you really needed to use brute-force. Hook it up to 24 VDC f.i. ;-) It was a very rugged design.
Nowadays, the printerport on a motherboard is built-in an ASIC, which has far more functions, but is not as rugged as the original design. The 74HC244 in the dongle can supply 25 mA (guaranteed) on an output-pin, and I am afraid that was too much for the ASIC. The good news is that the rest of the printerport still works OK. But it can no longer be used for this dongle.

So: limit the current in the /Ack-line by inserting a 1 kOhm resistor. The other lines are all inputs on the 74HC244 and therefor , basically, need no limiters. However, I do think it's better to insert current-limiters there as well. Why?
Of course we all know that the parallel port and RS232-port are not hot-pluggable .... ;-) , but most of the time I treat them as such. I know, ... bad habbit.
By taking some extra measures, the dongle can be made such, that it will not do any harm to plug it in while the PC and/or the target-board are powered.

Some FAQ's

Q. Is it necessary to add the filter to MISO and MOSI as well?
A. No. The data on these lines are set-up before the SCK-edge occurs. So even if there is ringing on these lines (and there is !!), it has no effect on the transmission. But: it's a good idea to filter these lines as well.

Q. Is this the ultimate solution?
A. Depends how you look at it. Adding a filter (an analog circuit) to a digital clock-line is something I preferably do not do, .... usually.
But in this case it's the best I could think of, ... in getting a simple solution.
The good thing is that it is not acting as a delay for the clock-pulse: that's a designer's nightmare. All it does is reducing the slewrate of the clock-signal. The best solution .... I'll give it some thought

Q. Could this apply to other programmers as well?
A. I think it does.
- Looking at the design of f.i. the AVR-ISP: the 90S1200 connects to the targetboard with no slewrate limiters at all. And if the cable between programmer and target is short, that will work fine. But Atmel's uC's are PDQ-things and have very short rise- and fall-times on their I/O-pins. So if you're using a longer cable, the same problem might occur.
- Looking at the serial programmer (SI-PROG) from PonyProg: here the problem will NOT occur as in the RS232-specification provisions were made for slewrate-limiting. Clever guys at that time, huh?
- The programmer ZL2PRG on the MCS-site: it looks like it is lacking this filter as well.

Quite some text huh?

As attachments you'll find an ImprovedVersion and an EvenBetter version, in case you're gonna build a new one.

I hope this solves many problems ... in my case it did. Have fun and happy computing .... eh, programming.

Plons

Attachment(s): 

Dragon broken ? Or problems with the Parallel Port Programmer ? Scroll down on my projects-page http://www.aplomb.nl/TechStuff/TechStuff.html for tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Plons,

I'm just getting started with AVR with the STK200 so thanks for the suggestions. I've seen similar problems in the past where lengths of cables, shielding etc can alter the ringing and yes I hate adding analog circuitry to the digital lines. Sometimes series R and/or termination helps too, but you're probably right that the R/C filter is the more robust solution.

I've been having problems with another parallel port PROM/PAL programmer - only works on an old laptop so I think I'll investigate any ringing. I must admit I hadn't thought of ringing on the lines - getting old I guess!

Thanks again for sharing the solution!

--Nick--

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

Well done, very intensive coverage on solving the problem & thanks for sharing it.

I have read somewhere about a month ago that someone suggested connecting 2 x 100K resistors to inputs of pin1(GA) to +5V & pin 19(GB) to +5V.
This will put the 74HC244 output to become tri-state mode (high impedance).
If memory serve me correct, then if STK200 is power up before you plug it into the printer port then your AVR chip will not be affected.

Correct me if I am wrong.

Having a hard time reading tonight as I somehow got soap or hair shampoo in one of my eye.
Pretty painfull, manage to flush it out with plenty of water.

Ken

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nick, good luck with your PromProg ... I hope you can sort it out

Ken, thanks for the advice: indeed it's an idea to consider adding the 100k pull-up-resistors on pin 1 and 19. Although I never blew an AVR .... But I must say: I always put in the 1k resistors in SCK, MOSI, MISO and Reset (on the targetboard). So there is not much chance :wink:

Plons

Dragon broken ? Or problems with the Parallel Port Programmer ? Scroll down on my projects-page http://www.aplomb.nl/TechStuff/TechStuff.html for tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

I wonder why did you put the RC network after the HC244 buffer and not before, in his inputs?
Is the 1K resistor not too big?

thanks

Ori

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Plons, excellent analysis of the problem!

I've got a question about the /ACK line and the 1K resistor used to limit the current on this line
as used in the improvement above.

I've found that on my parallel port, there seems to be an internal pullup to +5V on this line. Using the
indicated 1k resistor to pull this line low results in the pin only going to +2.4V. This seems to indicate that
on this motherboard (its a Pentium 100-level board), there is roughly a 1k internal pullup on this line. This
means I'll need an 180R resistor in order to pull the line low enough to meet the Vil specification. Interestingly
enough, I repeated this experiment on another motherboard (Pentium 533 this time) and found that it too
has an internal pullup; in this case it looks to be about a 1k8 pullup resister.

Is it usual for the status lines of the printer port to have internal pullups? I've seen no references to the
status inputs definitively having pullups on them. Can someone comment if ALL parallel ports generally
have some sort of internal pullup? If so, are the internal pullups typically this low in value (1k to 2k).
And while we are no the topic of parallel ports, are there actually parallel ports that are run at 3.3v rather than
5v?

I've got a couple of other questions on the usage of the HC244 in the improved circuit above. Firstly, if
the programmer is connected to the target board but is not plugged into the computer parallel port, the
HC244 inputs will be left floating. Wouldn't it be a better idea to add pullup resisters to all of the HC244
inputs rather than just the 2 enable pins?

Secondly, aren't the 6 additional 1k series resistors connected to the HC244 inputs (used in 'Even Better
PPPD' but not in 'Improved PPPD') still mandatory? If the AVR target board is working at 3v (meaning the
HC244 will be running at about 2.3v due to the diode drop) and the parallel port is working at 5v, this would
forward bias the HC244 input protection diodes with no current limit.

Or, I could be missing something fundamental.... (if so, don't be shy to let me know).

Regards,
Harvey

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I wonder why did you put the RC network after the HC244 buffer and not before, in his inputs?

one half of the 244 is used as input, the other as output (seen from one side).

I added a filter to the SCK-line which goes from the 244 to the AVR-targetboard: for the simple reason that "ringing" on that line was causing the trouble.

Quote:
Is the 1K resistor not too big?

I think not. The SCK-line is an input of the AVR. So 1k is OK. If you prefer to use a lower value, you can give it a try.

These were Ori's questions

Over to Harvey

I blew the motherboard-parallel-port with the original programmer. My own fault, because "we" are not supposed to plug-and unplug the parallel port when the PC is on. As I wrote earlier.
I tried to come up with a solution to prevent another blow-out (of my plug-in xtra parallel port). I had no other reference than this board.
So .....
Apparently there are pull-ups on the statuslines.
Hmmm, that makes sense AND a difference.
You are right: if there is a 1k - 1k8 pull-up, the 1k series-resistor will cause a level-problem. Your choice for 180ohm, is a good value. In my case the (on the extra PCI-board) 1k worked fine.

About Vcc=3.3V (AVR).
Yes, you're right. Again :wink:
That is the "price" for the use of this low-cost programmer.
The ParallelPortProgrammingDongle is not the right programming-tool for low-voltage applications.
The way I solve that: during development I run the AVR on 5V.

About ParallelPorts in general: although IBM specified the original very well, current design's are no longer meeting these spec's. And in fact we are not using the ParPort as it was supposed to be used ..... agree?

I strongly recommend not to plug or unplug the PPPD when it's powered. Unless you have plenty motherboards, of course :P

As you can read in this forum, many members prefer another programmer. And me? I recently ordered another programmer as well (USB)

But if you are a student, or simply do not wish to spend a lot of money for other reasons, this is an easy to build and low-cost tool. Another possibility is to build the serial programmer of PonyProg.

Happy programming

Nard

Dragon broken ? Or problems with the Parallel Port Programmer ? Scroll down on my projects-page http://www.aplomb.nl/TechStuff/TechStuff.html for tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello folks

An update on the PPPD: the ParallelPortProgrammingDongle

Thanks to: hlee (Harvey) for discovering the /Ack-pullup and his suggestion to reduce the resistor between pin 10 of the 25 pole subD-connector and the 74HC244 from 1k to 180 Ohms

and pykedgew (Ken) for his suggestion to add 2 100kOhm on G2A and G2B of the 74HC244

I have implemented the modifications in the schematics, and you'll find these as attachments.

When you use this programmer, do not plug it in or unplug it when PC and/or your targetboard is powered on !!

Dinner is being served, I'll get back later

Nard

Attachment(s): 

Dragon broken ? Or problems with the Parallel Port Programmer ? Scroll down on my projects-page http://www.aplomb.nl/TechStuff/TechStuff.html for tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some suggestions and/or recommendations

0 Do not plug-in or unplug the PPPD from the PC when either PC or targetAVR are powered-on
1 For PPPD to work properly, Vcc of your targetAVR must be 5V
2 If you use the STK200 as target, 3.3V for the AVR is OK as the STK200 has some additionally circuitry to take care of the different levels
3 If you need to disconnect the programmer from your targetAVR, first turn AVR's power down
4 Leave the PPPD connected to the PC; there is no need to unplug it
5 If you're using a ParallelPort extension cable, make sure it's a shielded one, not longer than 1.8 mtr
6 Check your PC-BIOS for ParallelPort setting: EPP or ECP

If there are more, .... feel free to add.

Nard

Dragon broken ? Or problems with the Parallel Port Programmer ? Scroll down on my projects-page http://www.aplomb.nl/TechStuff/TechStuff.html for tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Nard,

Actually, I'm a bit uncomfortable with using just a 100R resistor on the
parallel port pin 10 /ACk input. Under the wrong conditions it can still
cause damage to the parallel port.

I know that PPPD and other programmers like it were meant to be simple in
design, so what I have to say may sound burdensome. Please bear with me...

I was hoping that someone more knowledgeable about parallel ports could
provide some input on the internal pullups on the status lines of the
parallel port. Since there hasn't been any new information, I'm going to
assume below that there are parallel ports with status lines that do not
have internal pullups.

I would suggest adding a schottky diode in series with the MISO output
towards the DB25 pin 10 as shown below. The 15k resistor is used as a
pullup for the /Ack input in case pin 10 does not have an internal
pullup. If the port already has an internal pullup, this resistor is
not needed. I chose a lower value resistor to use here to minimize any
time delay impacts on the AC characteristics (probably minimal at parallel
port data speeds). The 22R resistor is used mainly for ESD protection of
the PPPD - especially if the PPPD is out-of-circuit and is being handled.
It would be better to have a larger value here (for better ESD protection),
but then it still needs to be low enough to sink the approximately 6 mA
of internal pullup and pin 10 base current.
With this configuration, the HC244 output only sinks current from the /Ack
line when MISO is low. When MISO is high, it is decoupled from the
/Ack line and the pullup resistor (internal and/or external) is used to
pull /Ack high.
The worst-case noise margin is decreased by about .4V by this design,
though.

+V
|
|
|
\
/
\ 15K
/
\
|
|
22R | Schottky
|
input to /Ack -----/\/\/\----------------!>|------------ output from MISO
DB25 pin 10 HC244 pin 9

In the other direction, I still feel uncomfortable about not having
any ESD protection, current protection nor pullups on the 6 inputs to
the HC244. If anyone is still with me, I'd like suggest the circuit
below. On output high, the DB25 outputs are decoupled from the PPPD
which gets its pull-up power not from the DB25 but from its own
supply.

+V
|
|
|
\
/
\ 15K
/
\
|
|
220R Schottky |
|
DB25 outputs -----/\/\/\------|