Hi All,

I recently upgraded to the ATMega 328 from NK. I followed the Nano Guide to the letter (I think). My program compiles and loads. When I run it, the program seems to be working, but the display only displays anything on line one and the information being displayed are jumbled, not even what is supposed to be at line one. I am wondering if anyone can give me any ideas as to where to look for my problem?

Thanks

Devin

Hi Devin,

Its possible that your lcd libraries are still compiled for the old chip. Did you make sure to delete all .hex and .o files in your project folder and in your libnerdkits folder before you recompiled?

Humberto

Hi Humberto,

I went back and triple checked all of my folders for .hex and .o files and found none. There were no .hex files in the libnerdkits folder even after I recompiled. I don't really fully understand how this all works, so I hope that is right. I tried redeleting all of the .hex and .o files again running make again and still have the same problem. I must add that I am not using the nerdkit display. The display I am using is virtually the same, with the exception that it runs on 3.3 volts, since I am running my system on 3.3 volts. When I switched to this display using the 168nerdkit MCU it worked perfectly

without having to make any changes.

Hi,

There really shoudl be .hex and .o files in your libnerdkits folder after you compile. Did you remember to edit the Makefile in the libnerdkits folder and change the -mmcu declaration? You should also make sure that you didn't accidentally add any line breaks or anything weird to your makefile.

Humberto

Hi Humberto,

I checked my makefile in my project folder and my libnerdkit folder and they both appear to be right (at least to my untrained eye). I am sure it is something simple. I just can't see it. I will post my files. If you have time could you please glance at them and see if you can see where my problem is?

This is my project makefile:

GCCFLAGS=-g -Os -Wall -mmcu=atmega328p 
LINKFLAGS=-Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm
AVRDUDEFLAGS=-c avr109 -p m328p -b 115200 -P /COM3
LINKOBJECTS=../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o

all:    thermvalve-upload

thermvalve.hex: thermvalve.c
    make -C ../libnerdkits
    avr-gcc ${GCCFLAGS} ${LINKFLAGS} -o thermvalve.o thermvalve.c ${LINKOBJECTS}
    avr-objcopy -j .text -O ihex thermvalve.o thermvalve.hex

thermvalve.ass: thermvalve.hex
    avr-objdump -S -d thermvalve.o > thermvalve.ass

thermvalve-upload:  thermvalve.hex
    avrdude ${AVRDUDEFLAGS} -U flash:w:thermvalve.hex:a

This is my libnerdkits makefile in the same directory:

GCCFLAGS=-g -Os -Wall -mmcu=atmega328p

all: delay.o lcd.o uart.o

delay.o: delay.c
    avr-gcc ${GCCFLAGS} -o delay.o -c delay.c

lcd.o: lcd.c
    avr-gcc ${GCCFLAGS} -o lcd.o -c lcd.c

uart.o: uart.c
    avr-gcc ${GCCFLAGS} -o uart.o -c uart.c

Thanks,

Devin

Hi Devin,

Did you remember to download the io_328p.h file, put it in the libnerdkits folder, and add it as an include in your .c files?

Humberto

Hi Devin,

Did you remember to download the io_328p.h file, put it in the libnerdkits folder, and add it as an include in your .c files?

Humberto

Yes. I even opened opened it up and checked it to make sure it downloaded properly. While I don't know specificly what the code in that file is supposed to look like. There is code in my downloaded file, so I am assuming that it downloaded properly.

Thanks, Devin

A question occurs to me. How does the compiler find the right libnerdkit folder? Perhaps my file structure is not set up properly for the compiler to find the libnerdkit folder that is supposed to go with the program I am trying to load onto my MCU?

include "../libnerdkits/delay.h"

the lines that look like this give the compiler a relative location. ../ is up one directory. So essentially your libnerdkits folder must be parallel to your project folder, or you change these relative locations to point to the right one.

Also, the linker is passed this from the makefile:

LINKOBJECTS=../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o

Thanks treymd. I checked where I have my libnerdkit file and it seems to be in the right place. I really have no idea what I have done to cause my current problem. Now, even if I go back and try to write the stock Nerdkit tempsensor file, or any of the original nerdkits projects, from the original downloaded location (that worked perfectly fine before) onto a 168 MCU, I get the same thing. Only line one on the display shows anything, and it doesn't say anything that makes sense. Only a small piece of what the message is supposed to be. Further, the libnerdkit file within the same directory does not contain any .hex files before or after compiling. I double checked all of my wiring and it checked out. I am at a complete loss at this point. Any ideas would be great.

Thanks, Devin

Hi Devin,

Couple of things to try. Download the original unalatered Code folder to your your comptuer again, and using your Atmega168, try cd your way into that folder and upload a fresh initialload to your chip. If the files upload fine then it probably means there is something going on with either your LCD or your wiring to the LCD.

It might also make sense to load up something like the the LED blink code. This will let you know if your chip is running fine and the problem is on the LCD side.

Humberto

Hi Humberto,

This evening I have done exactly what you suggested. I also used a different display(the original that came with my original nerdkit). I also completely rewired it and checked all of the other wiring to the MCU. When I load the initialload program the display reads out what line four is supposed to say on line one and that is all it shows. This is the same thing the other display I was trying does. When I run the led_blink program it seems to work fine. Is it possible that my compiler, or something else within my computer has somehow become corrupted?

Thanks

Devin

I have an update. I intstalled WinAVR on my other computer and downloaded the nerdkit source code, then installed it onto my MCU from there and it worked. The display showed exactly what it was supposed to. So I tried uninstalling and reinstalling WinAVR on my laptop (the computer I usually use) and still have the problem.

So wouldn't that rule out a problem with the MCU, a problem with the wiring and a problem with the compiler? The question I have now is where do I look next?

Thanks

Devin

So wouldn't that rule out a problem with the MCU, a problem with the wiring and a problem with the compiler? The question I have now is where do I look next?

Thanks

Devin

Yes, that rules out the MCU.

I would look at drivers. They may be conflicting with Windows. There are some other threads on here regarding that.

BM

Hi Devin,

Just a thought, make sure you remove all the .hex and .o files after you reinstall WinAVR. Its possible you are still uploading files compiled with your old compiler because the .o and .hex files are all still there.

Humberto

clean: rm -f .o .ass *.hex

(make sure that's a tab and not spaces on the second line!)

Insert this into your Makefiles and run "Make Clean" before "Make". A little tidbit to make life easier.

eh code formatting issues..... attempt #2

clean:
        rm -f *.o *.ass *.hex

Hi Everybody,

Wow, Thanks a lot for all of the information. I truly appreciate it. Tonight I finally had a chance to try it out. I went back and reinstalled WinAVR, then made sure I removed all of the .o and .hex files. Then reloaded the stock tempsensor project and it now works. @ treymd, thanks for the piece of code. I will make sure to insert this into all of my future makefiles. Do I need to put this into the makefile in the libnerdkits folder also? I don't fully understand how a makefile works yet. But I do notice that the libnerdkits makefile has a slighly different format (I hope that is the right word for it) than the makefile we put in a project folder. @BobaMosfet, I did notice that windows updates installed a "critical" update around the same date that I noticed I had a problem. I haven't dug into it yet as I have not yet tried a 328 MCU yet (one thing at a time). But I wonder if the update was what created the problem and it was just a coincidence that I tried upgrading at the same time.

Thanks

Devin