While compiling the bootloader I get this error:

miniMac:bootloader328p Me$ make
avrdude -c avr109 -p m328p -F -b 115200 -P /dev/cu.PL2303-0000101D -U lock:w:0x2f:m

Connecting to programmer: .
Found programmer: Id = "FDL v02"; type = S
    Software Version = 0.2; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x35

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: reading input file "0x2f"
avrdude: writing lock (1 bytes):

Writing |                                                    
| 0% 0.00savrdude: error: programmer did not respond to command: write byte
make: *** [fuses] Error 1
miniMac:bootloader328p Me$

Any idea what might cause this?

Thanks,

Ralph

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

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

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

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.

Rick

Rick's most excellent bootloader instructions.

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:

Found programmer: Id = "½ ("; type = ⌡
    Software Version =  . ; Hardware Version =  .
avrdude: error: buffered memory access not supported. Maybe it isn't
a butterfly/AVR109 but a AVR910 device?
make: *** [tempsensor-upload] Error 1

The infamous "butterfly" error. So chalk up another reason for the butterfly error no bootloader.

The fuse settings on (1) are:

Lock:     0xFF
Extended: 0xFF
High:     0xD9
Low:      0x62

On another ATmega328p (2) the fuse settings are:

Lock:     0xFF
Extended: 0xFD
High      0xD2
Low       0xF7

The fuse settings from the bootloader328P Makefile are:

Lock:     0x2F     101111
Extended: 0x05
High:     0xD2
Low:      0xF7

I will definitely try to load the bootloader following Rick's great instructions.

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.

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!!

The new Nerdkit ATmega328P:    The bootloader ATmega328 fuse settings:
Lock:     0xEF                  Lock:       0x2F
Extended: 0xFD                  Extended:   0x05
High:     0xD2                  High:       0xD2
Low:      0xF7                  Low:        0xF7

The new Nerdkit ATmega168:      The bootloader ATmega168 fuse settings:
Lock:     0xEF                   Lock:       0x2F
Extended: 0xF8                   Extended:   0x00
High:     0xD5                   High:       0xD5
Low:      0xF7                   Low:        0xF7

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

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

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

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

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.

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.

Between your instructions and Rick's that would make a nice package.

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

Ralph

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

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.

// GET_AVR_ID.c

#include <stdio.h>
#include <math.h>
#include <string.h>
#include <avr/io.h> 
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <inttypes.h>

#include "../libnerdkits/lcd.h"

#ifndef PB0 
#   include "../libnerdkits/io_328p.h"
#endif

//------------------------------------------------------------------------
// _ms timer variables
volatile uint16_t wait_count;

// initialize timer
void _wait_ms_init(){
    // set up timer for 1 ms interrupt
    //8000000/64/125 = 1khz
    //20000000/256/78
    OCR0A=78; // match value
    TCCR0B = (1<<CS02) ; //256
    TCCR0A = (1<<WGM01); // CTC mode
    TIMSK0 = (1<<OCIE0A); // interrupt on OCR0A match
//  
//  be sure interrupts are enabled - sei(); 
}

// set ms timer value
void _wait_ms(uint16_t ms){
    wait_count=ms;
    while(wait_count>0);
    }

SIGNAL(TIMER0_COMPA_vect){
    if(wait_count>0){
        wait_count--;
    }
}

FILE lcd_stream;

// PIN Def's
//
// PB1 -- reset pin on target ATmega
// PB3 -- serial input (MOSI)
// PB4 -- serial output (MSIO)
// PB5 -- serial clock (SCK)
//
#define P_MOSI PB3
#define P_MSIO PB4
#define P_SCK PB5

#define set_AVR_1_output DDRB |= (1<<PB2)
#define clear_AVR_1_output DDRB &= ~(1<<PB2)
#define AVR_1_on PORTB |= (1<<PB2)
#define AVR_1_off PORTB &= ~(1<<PB2)

#define uchar unsigned char
#define SPI_CMD_LEN 4

uchar SPI_Cmd[5];
uchar SPI_Reply[5];
uchar AVR_Signature[4];

void SPI_Init(void){
    // set MOSI, SCK, SS as output
    DDRB |= (1<<P_MOSI) | (1<<P_SCK);
    // set MSIO as input
    DDRB &= ~(1<P_MSIO);
    /* Enable SPI, Master, set clock rate fck/128 */
    SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR1)|(1<<SPR0);
    // initialize reset pin
    set_AVR_1_output;
}

uchar SPI_SendRcv(uchar cData){
    /* Start transmission */
    SPDR = cData;
    /* Wait for transmission complete */
    while(!(SPSR & (1<<SPIF)));
    return(SPDR);
}

void do_spi_cmd(){
    uint8_t i;
    i=0;
    while(i<SPI_CMD_LEN){
        SPI_Reply[i]=SPI_SendRcv(SPI_Cmd[i]);
        i++;
    }
}

void enter_programming_mode(){
    SPI_Reply[2]=0x00;
    int tries;
    tries=5;
    while((SPI_Reply[2]!=0x53)&&(tries>0)) {
        AVR_1_on;
        _wait_ms(25);
        AVR_1_off;
        memcpy_P(SPI_Cmd,PSTR("\xAC\x53\x00\x00"),4);
        do_spi_cmd();
        tries--;
    }
    if(tries==0){
        SPI_Reply[2]='*';
    }
}

void read_ARV_Signature(){
    memcpy_P(SPI_Cmd,PSTR("\x30\x00\x00\x00"),4);
    do_spi_cmd();
    AVR_Signature[0]=SPI_Reply[3];
    memcpy_P(SPI_Cmd,PSTR("\x30\x00\x01\x00"),4);
    do_spi_cmd();
    AVR_Signature[1]=SPI_Reply[3];
    memcpy_P(SPI_Cmd,PSTR("\x30\x00\x02\x00"),4);
    do_spi_cmd();
    AVR_Signature[2]=SPI_Reply[3];
}

void release_AVR(void){
    // raise signal on reset pin
    AVR_1_on;
    // turn off the spi too in case the avr pins have other uses
    SPCR = 0;
    DDRB &= ~((1<<P_MOSI) | (1<<P_SCK));
}

int main() {
    _wait_ms_init();
    SPI_Init();
    lcd_init();
    fdev_setup_stream(&lcd_stream, lcd_putchar, 0, _FDEV_SETUP_WRITE); 
    sei();

    enter_programming_mode();
    read_ARV_Signature();
    release_AVR();

    lcd_clear_and_home();
    fprintf_P(&lcd_stream, PSTR("0x%02x 0x%02x 0x%02x"), AVR_Signature[0], AVR_Signature[1], AVR_Signature[2]);

    while(1);
}

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

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. ;-)

Gee, this is looking just like a BETA SIP loader I had.

Wonder why nothing was ever done with that?

It worked fine once I figured out the syntax of the AVRDUDE line.

It referenced the dapa programmer.

Ralph