I have a blank Atmega168 I want to upload to. I am using a parallel port with the 'dapa' (Direct AVR Parallel Access cable) which there seems to be all sort of articles about on the web. People generally seem to have success with this method.

I am running XP (on an older HP laptop) and using avrdude. Cmd line:

avrdude -p m168 -c dapa -t
write flash diag.hex / write flash 1 2 3 4

or,

avrdude -p m168 -c dapa -U flash:w:diag.hex

What I get is:

1)avrdude initialises fine (good signature byte), lock and fuse bytes are all what you would expect the defaults to be. No problem reading them at all:

lock=0x3F, efuse=0xF9, hfuse=0xDF, lfuse=0x62

2)I cannot write any byte anywhere. Not to flash, eeprom, lock or fuse bytes. When writing to flash, it throws out an error at the verification stage, everything remain the default 0xFF. I get 'rc=-6'.

The fixes I've tried:

a)Changing Vcc from 3.3V to 5V. No change.

b)Reducing cable length from 1.5m to 70cm. No change.

c)Changing the BIOS so the printer port is EPP. No change.

d)Put a delay in (avrdude -i 5/10/20 miliseconds). No change.

Basically, the hardware seems fine, otherwise I wouldn't be able to retrieve data from the chip. Am I missing something really obvious?

Thanks,

Mujda

Hi Mujda,

My first thought is to make sure all your wires are connected to the right place. Successful reads and unsuccessful writes could mean your write wire is intermittent. There are a few customers who have successfully flashed the bootloader onto the chip using a parallel port and documented it in this thread.

Humberto

Thanks Humberto. To my astonishment, it finally all works. The problem was XP polling the parallel port, which was address by the registry fix described in the link you gave.

The other thing that was catching me out was the -u switch to set the fuses.

To my even greater surprise, the firmware works. I took,

SD card reader-writer

(all credit to the author), modified the code slightly for AtMega168, and it worked first time. Now I can read/write to an SD card, and the hyperterminal interface works fine. It even showed up a virus that had found its way onto the card.

One question though. If I dump the contents on the flash with

avrdude -p m168 -c dapa -u -U flash:r:file.hex:i

It automatically seems to know where the end of the application code is. Does it just hunt for default 0xFF bytes, and assumes the code ends there?

Mujda, please post your SD card 168 code, and also the steps to what exactly you did (components etc.).

SD interface with the 168 would be extremely interesting. I had searched the web numerous times but never found the SD card reader-writer link you reference.

Thank you,

Ralph

Hi Ralph,

Hmm, the link in your post works for me. The root of the address is www.dharmanitech.com

In terms of hardware, I used exactly what is shown in the link, except instead of the MAX232 I used the USB/UART cable I got with my nerdkits kit, connected in the same way it is used in their kit (pins 2 & 3).

It is running off the internal oscillator @ 8MHz, and Vcc=3.3V.

There is loads of code, too much to put within a post, but it only took a few changes. Is there a way to upload code to the forum, rather than insert it in the post? I'd be happy to email it to you if needed.

Mujda

Mujda, thanks rhulslander at gmail dot com.

There has been a lot of interest in SD support on the Nerdkits forums. One of the reported problems was FAT32 on the 168 with limited memory but if it is running on a ATmeg8 then that problem seems to be solved.

If can get my web DNS stable I will post your code there.

There is a pastebin setup for Nerdkit post at PasteBin.com but I have never used it nor even know how to use it. It would be great to have a NerdKit project post page.

Again, thank you so much I really need all of the help I can get.

Ralph

Mujda,

Please tell us what modifications you made to the code "modified the code slightly for AtMega168".

Thanks,
Joel

Hi Brockmjp

From what I can remember,

Start by changing the Makefile:

MCU = Atmaga168
Change the clock speed if necessary

Once you try and compile it, it'll start to throw out various errors, basically due to the registers being different on the Atmega168. I got the data sheets for the 168 & 8 up side-by-side and found the equivalent register to the 168. Fortunately, most of the changes simply involved inserting a '0' or '1' into the register names (for example the 168 has 2 UART's whereas the 8 has only 1). The only slightly more tricky one related to the interrupt mask, which involved a different register name.

If you don't want to go through the process above (I learnt lots from it), drop an email address to me I'll email you the code in its changed form.

Mujda

ooops, that was meant to be atmega168 not Atmaga168

Hi Mujda,

Believe me there is no shortage of things to learn here. I've been trying to get the SD card for PCM sound project working (posted by pbfy0). What I need right now is a baseline of code and makefile that are known to work (pbfy0's C code has not been tested). If I can do exactly what you did and get that to work, then I can try to modify the code in the other project to get it to work. If your modified code doesn't work for me, then its likely that I have a problem with my circuit since you got the code to work. Please do send me your makefile and modifications. I've done a few nerdkits projects, but that is the only experience I have with C programming (or any compiled language for that matter). Makefiles, bit manipulation and hexadecimals are still a bit difficult for me to understand. You can contact me at joelbrockman at yahoo dot com.

Thanks,
Joel