Thanks to MCS Electronics!

For all those who had started programming Atmel AVR microcontrollers using BASCOM-AVR, you must have made your own home-brewed Sample Electronics cable programmer - as it is called. Same was the case with me. I soldered the connections. Surely, I didn't expect it to identify the target chip in the first run.. eh?! I checked and rechecked the hardware.. After a few corrections, it did identify the chip and loaded the HEX file ultimately. But, after some hours I concluded that it's not completely reliable... Sometimes (even if everything seemed to be okay) during the verification process, I got a message box stating that there is a difference in the hex codes of the actual file and the loaded file; along with the address of the difference. I thought and thought and thought.. Couldn't come to think any other drawbacks other than lack of buffering and impedance matching. I asked my seniors and mentors.. Everyone agreed that it was a bit unpredictable but no-one knew the true reason for it. I searched the net, but didn't find any relevant explanations. So, I remained ignorant until now :D.

Initially, I was using the demo version avilable on the MCS Electronics website. After some experience, my code size often went above 4 KB and that won't compile in the demo version. One fine day, I got the full version crack and installed it on my PC. Then, it was another very fine day (:)) when I was showing the same connections to a friend of mine (Note: now I was using the help section of the full version which was a bit updated), BINGO! I came across this italicized text which almost explained the thing I wanted to know for so long!

I have been having spurious success with the simple cable programmer from Sample Electronics for the AVR series.

After resorting to hooking up the CRO I have figured it out (I think). When trying to identify the chip, no response on the MISO pin indicates that the Programming Enable command has not been correctly received by the target.

The SCK line Mark/Space times were okay but it looked a bit sad with a slow rise time but a rapid fall time. So I initially tried to improve the rise time with a pull-up. No change ie still could not identify chip. I was about to add some buffers when I came across an Atmel app note for their serial programmer "During this first phase of the programming cycle, keeping the SCK line free from pulses is critical, as pulses will cause the target AVR to loose synchronization with the programmer. When synchronization is lost, the only means of regaining synchronization is to release the RESET line for more than 100ms."

I have added a 100pF cap from SCK to GND and works first time every time now. The SCK rise time is still sad but there must have been enough noise to corrupt the initial command despite using a 600mm shielded cable.

Although I'm using Kanda Systems' STK200+/300 as of now, this one explained to me the reason of the old weird problem. My sincere thanks to whoever updated that help section and to the research guy too!!

Note: Although the loading is done via the parallel port, the communication is done in serial mode as stated in the app note.