What programmer are you using... I'm assuming some sort of ISP programmer since it looks like you were trying to program fuses.

Are you trying to upload a bootloader to a new chip? Or an existing one with a bootloader installed already?

On a different subject, any luck with the files I emailed you?

Rick

February 18, 2011
by Ralphxyz

Hi Rick, so far no luck with the DS3232. I just received some EEPROM (I2C) so I am going to try Peter Fluery's test program to see if I can get the communications working. I also loaded the Nunchuck code and got that to work.

I was thinking that possible the reason I am having problems is because all of the chips I am using were new chips I got from mouser that did not have the bootloader installed. I had just copied the bootloader.hex to the device using my Dragon programmer.

I had never set the fuses and could not read/understand the fuse setting files from the bootloader foders. I am using Atmel's AVR Studio when using the Dragon. Using AVR Studio it is rather convoluted to set the fuses and you do not have the full range of settings available.

I have no idea what I am doing so I thought I'd just try to load the bootloader just using the Nerdkit breadboard and that is how I got the error.

I can try loading the bootloader project in AVR Studio and programing the mcu from there. In hindsight that would make more sense. I'll try that tomorrow.

Ralph

February 19, 2011
by Ralphxyz

I guess you need a parallel dapa (lpt1) programmer to compile the bootloader foodloader code.

Oh well, I've ordered some new mcus from the NerdKit Store so I'll use them.

On another note: Can one just copy the foodloader.hex to a mcu and expect it to work? What about fuse settings?

I had just loaded the foodloader.hex as that was all I was told to do with a beta ISP programmer. Should I have also set the fuses? It appeared to work just loading the .hex but I have had problems running code that I did not originate like Ricks's DS3232 RTC code, which I really will need.

Ralph

February 19, 2011
by Rick_S

Ralph, did you read the thread I just posted a couple hours ago in the support forum? I typed up an instruction for the bootloader installation. I thought it might help you out as well as some others.

As far as compilation goes, you don't need any programmer to compile. You only need a programmer to send the compiled file over to the micro-controller. You also don't have to have a parallel port programmer (dapa). I use a USBASP programmer. You AVRDragon will also work fine.

The fuses will only effect code running if certain things have been played with. (Or not) For instance, if you bought a new chip from Mouser (like you stated) but did not program the fuses, the chip will be using it's own internal RC oscillator instead of the crystal. It will also have the CKDIV8 fuse programmed which will make the clock run at 1/8 speed or 1Mhz on a stock chip. Even if the fuses were set to use an external clock, if the CKDIV8 fuse is still set, the clock would be 1/8 the crystal speed.

This would definately throw all timing out of whack and could prevent the LCD from working right, Any timing critical serial communications like I2C could be out of whack etc...

Let me know exactly what problem you are having. I'm sure we can get through this and we may be on the right track.

Read my bootloader post though, it may help a bit. Also, make sure you have a good clean set of bootloader files from the download section.

re: timing, that is one of the reasons I was questioning my method of just loading the bootloader (foodloader.hex).

I have had a number of ATmega mcus some purchased from the Nerdkits Store and others from Mouser or other suppliers from the web. I have no way of knowing which is which.

I believe I have a blank ATmega328p (1) purchased online without a boot loader.
When I power up I get two black bars on the LCD in run mode and in program mode I get two black bars.
I tried to load a program using the command line on (1) which I believe does not have a bootloader and it eventually times out with:

Another problem I have had which might be related is that I have not been able to load any programs using ISP. This is on a ISP breakout board I had made up, using my Dragon (I use PP/HVSP) or on my STK600 (a very expensive but poorly supported programmer from ATmel).

I never had a problem with the LCD but I am having problems with I2C so I will follow Rick's instructions to see if I get the bootloader installed. I know I can always load the foodloader.hex directly and now I see how to set the fuses using the Makefile. Using AVRstudio to set the fuses is very convoluted as I have said and getting some settings like the Lock setting from the bootloader folder is really hard. Using the Makefile should get the settings desired.

Wow, this sure is interesting.

Ralph

ps Rick your instructions do not address compiling the bootloader/foodloader. I believe you have changed the bootloader so you must have compiled it. "We" could also use (and appreciate) instructions on changing the bootloader. Especially changing the bootloader to run on other ATmel mcus. I have a ATmega32 that came with the Dragon that I will eventually like to use so that would be neat to have the bootloader though since I have a programmer it is not critical to have.

February 19, 2011
by Ralphxyz

Now this is a little strange, I have no idea what it means or especially "WHY". But I just received my new ATmega168 and ATmega328P microprocessors from the Nerdkits Store.

The Nerdkit ATmega328p's and ATmega168's fuse settings do not match the fuse settings in the bootloader Makefile!!

Like I said I have no idea what this means, eventually I'll go through the specsheets and determine what the different hex values mean but for now I will just standardize on the Nerdkit fuse settings as that works and should be what everyone is using unless they follow Rick's instructions and Make the fuses according to the bootloader Makefile. Of course the bootloader Makefile could be modified to match the Nerdkits Store devices fuse settings.

Just the Lock and Extended fuse settings do not match.

The fuses_mike.txt file agrees with the bootloader Makefile

Geesch, this could get confusing.

Ralph

February 19, 2011
by Rick_S

They are the same. Both the lock and efuse bits only use part of the byte the rest remain at 1 (unprogrammed) If you convert the hex values you read to binary and compare that with the numbers in the bootloader fuse settings, you'll see the same bits are programmed (0). Depending on what you read the chip with the un-used bits may be reported which is what you are seeing.

Rick

February 19, 2011
by Rick_S

328/168 lock only bits 0 thru 5 are used

0xEF = 0b11101111
0x2F = 0b 101111

328/168 efuse only uses bits 0 thru 2

0xFD = 0b11111101
0x05 = 0b 101
0xF8 = 0b11111000
0x00 = 0b 000

Rick

February 19, 2011
by Ralphxyz

Like I said this can get confusing. I was going to go to the specsheet to see what the settings meant but once again thanks.

Ralph

February 19, 2011
by Noter

I just looked at Ricks "How to install the NK bootloader" and want to give credit to Rick for a job well done - That is a great tutorial!

However, you don't absolutely have to buy one ... you can build your own usb/isp programmer using the nerdkit. The bootloader source that comes with the nerdkit can be modified to use the spi programming commands to load your new chips. It is probably only worthwhile for the educational aspects because it will take a lot of time and effort but then you would have a custom programmer that you could change/fix as desired and gain good expertise on avrdude, memory programming, fuses, and spi in the process.

February 20, 2011
by Ralphxyz

Ok Noter, how? We need a schematic and the bootloader source change and a outline of exactly what is going on "educational aspects".

I have programmers but also I tried to build one (which didn't work). So if you show me how I will makeup another.

Then maybe someone will publish a Eagle PCB board and we could really be off to the races.

Ralph

February 20, 2011
by Rick_S

The only issue I would see with that would be two fold. One, if you modify the bootloader, you would have to have a way to re-load it. If you change the bootloader to be a regular program loaded in via the normal NK method, it could possibly work... but would definately require a programming effort and would not really be a USB programmer, it would be a serial programmer.

A true USB programmer can be done but most I've seen require a 12Mhz crystal. A notable one is the USBASP firmware I have on my programmer. That firmware shows it being loaded on a smaller mega8 or mega 48 but I see no reason why a mega168 wouldn't work. The firmware for the device can be found here. I have built one of these in the past using a mega8. The only part I would have to check is whether or not the standard NK fuse settings would work with the USBASP.

I kind of like the original idea though because it would require no additional hardware. I might have to look at this. It would be pretty cool and for my part it would be a MAJOR programming accomplishment.

If I got it going, an eagle PCB would be no biggie. However, it most likely could just be breadboarded.

Dang... another project to occupy my time :D

Rick

February 20, 2011
by Noter

Yes, that is what I meant - make the bootloader (start with foodloader.c) into a regular program that accepts the same bootloader commands from avrdude and translates them into serial programming commands for a mcu attached via the spi. A good place to start is to become familiar with serial programming - Section 27.8 of the mcu datasheet explains how to program the mcu via the serial interface.

Is that a working program? If so, that was quick. I'll admit I haven't looked much at programmer development though since I have a couple ISP programmers as it is. This would be a nice step forward for the community.
Rick

February 20, 2011
by Noter

It works on my nerdkit so it should work on yours too. Much of that code I already had and just consolidated it into the example. I was hoping to provide a nice schematic for Ralph but I've a long way to go with the Eagle design package. So in the mean time I hope you don't mind my hand drawn version:

Please note that in the code in my last post, PB2 in the define statements will need to be changed to PB1 to match drawing exactly or just use PB2 to connect to the reset pin of the target ATmega. The spi pins are straight across, 17 to 17, 18 to 18, and 19 to 19. As you can see, the hookup is pretty simple.

The next steps are to get each one of the serial programming instructions coded into a subroutine and tested - see table 27-19 on page 310 of the datasheet. After that, it's a matter of pulling in the UART code to communicate with AVRdude on the PC to call the appropriate function (as in the foodloader.c program) and we will have a nerdkit DIY serial programmer. ;-)