I had a working version of Noter’s ISP programmer loaded on a Atmega 168. I would like to add the capability of selecting the target chip that I intend to program on a SPI bus. This should be easily achieved by controlling the reset pins on all of the chips on that buss. I made a few changes to the AVR ISP programmer code that Noter had posted.

My version of Noter’s ISP programmer will compile but I have not had any luck getting it to load onto a chip. Without the resource of the Nerdkits library and Noter’s step by step detailed instructions I have no doubt neglected to do something important in this process. When I was unable to load the AVR_ISP code I decided to try the Initialload code to test the hardware setup. I was able to load the initialload code with no problem. In doing that I lost my original ISP programmer. I then decide to try and reload Noter’s original AVR_ISP programmer code from the same location that I had done it before , I was not successful in doing that.

At this point I cannot seam to load ether Noter’s original code or my modified code. I get a very similar error message. I suspect the problem is resulting from something I am doing incorrectly with regards to the make files.

I realy have no idea why I was able to load the AVR_ISP code before but cannot now.

That's a strange error. The only reference I can find on the web is related to an old version of winavr running on vista - http://www.madwizard.org/electronics/articles/winavrvista. Are you running windows vista?

Probably the best bet is to upgrade to the latest tool-chain/winavr from ATMEL and go from there. Otherwise maybe delete the object files to force a fresh compile and try again. Or get rid of the objdump command from you make file if you never look at the disassembled listing anyway. I always try to stay current with the compiler and other tools posted on the ATMEL web site although sometimes I forget to check regularly and may fall a little behind. But all the tools linked from the nerdkits site are several years out of date thus missing important patches and enhancements.

Noter

Yes the computer I was using for that upload is running vista. It was a few months ago that I originally uploaded your AVR_ISP code to a chip, I think it may have been from a different machine on my home LAN. I am going to attempt the upload from that computer and also take your advice about the upgrade to the vista machine and others. I will let you know how I make out.

thanks

Noter

I seam to be way out of my league here. I don’t think I ever made any changes to your code as it was posted in the Nerdkits library. I did make a copy of the code and made some changes to the copy, yet I cannot seam to reproduce the same results I was getting a few months ago.

I downloaded and installed the latest version of the Tool-chain for windows from the ATMEL web site as you suggested. I also tried using a deferent computer to accomplish the download to the chip. Nether of these approaches resulted in success. I am now getting a completely different set of error mssages on the visa machine and the other machine. When I attempted to remove the objdump command I get a different error set.

I suppose it may be possible that I inadvertently caused some changes in ether the make file or the ISP programmer code but I don’t think so. Since the original code that you posted in the library is not available and your code posted on the forum has a few changes it is difficult for me to verify what may have changed.

In any event here is the latest error message I get when running the make file for your original ISP programer.

I don’t understand much about the make file or the errors that appear to be now in the ISP code. Any help is greatly appreciated.

I don't remember exactly when that changed but one of the new versions of avr-gcc required that PROGMEM variables be declared as CONST. I've had to make those changes to most of my older programs when I compile them again.

The fix is to put the keyword const in front of the avr_info declaration. And again in the function prototype and declaration of uart_write_PSTR().

const AVR_DEVICE    avr_info[DEVICE_COUNT] PROGMEM =    {

void uart_write_PSTR(const char *x);

void uart_write_PSTR(const char *data){

Noter

Thanks! it is looking like I am getting closer to me, Still not working after making the changes you posted. Running the make file produces the .o and .hex files in the correct directory. But the make does not write to the chip. As far as I can see it does not report any error codes either it just stops running and return control to the Command Prompt window.

I don't know for sure what make file you are using but if it's one of mine then probably 'make' will just compile and 'make program' will compile and download or just download if the compile is current. Look at the make file to see what other targets are defined. Section 2.1 in GNU `make' gives a quick explanation of rules, targets, prerequisites, and recipes. Make can do a ton of stuff but if you learn about those 4 things you'll have the basics covered.

Thanks again Noter.

“make program” did the trick. I am able to program the chip with my slightly modified version of the code that you posted for the ISP programmer. The outcome from my changes to noter's original ASV_ISP programmer, are not doing what I expected.

Perhaps someone could explain where I am going wrong. I could repost the entire code as Noter has it on Noters code if that would be useful. For now I will try to explain my issue by only posting a couple of short additions I have made to that code.

I am displaying on the LCD which of the four chips on my SPI buss the ISP programmer will be communicating with. I have set up the hardware so that I can select the chip by setting the position of two switches. These two switches are connected to PC0 and PC1.

I made this function to display the current selection on the LCD. There is no doubt a better way to do this but I can’t understand why this is not working as expected.

       void show_target(void){
 lcd_clear_and_home();

switch(PINC & 3){
        case 0:
         fprintf_P(&lcd_stream, PSTR("Master chip AVR ISP"));
        break;

        case 1:
        fprintf_P(&lcd_stream, PSTR("Z Axis AVR ISP"));
        break;

        case 2:
        fprintf_P(&lcd_stream, PSTR("Y Axis AVR ISP"));
        break;

        case 3:
        fprintf_P(&lcd_stream, PSTR("X Axis AVR ISP"));

    }

    }

I call this function from inside the main loop, after the while(true){ statement.

 while(true){

// check target selectiion switches
show_target();

The chip selection display is working in the sense that it will show the correct display to indicate the positions of the selection switches when the program is rebooted or power up. What I don’t understand is why it will never change if the switches are altered after the chip is running the program. PC0 and PC1 are setup as input pins and changing the switch position will change the state of these pins. Each time the show_target function is executed the display should change to reflect the current sate of input pins. Since show_target is called each time the main loops why does the LCD never update as the switches are changed?

Your code looks ok but it doesn't run until a char is received over the serial line. At the top of the while loop is

    command=uart_read_q();

which doesn't return until a character is read from the queue. Probably you can insert your show_target call in the read queue function like so:

uint8_t uart_read_q(void){
    uint8_t data;
    show_target();
    while(qout==qin){
        show_target();
        }
    data=q_buff[qout++];
    if(qout==Q_SIZE) qout=0;
    return(data);
}

Run it once on entry and then continuously in the wait loop. I think that will work but I haven't tested it.

I was thinking that was probably the case, the main lop is not cycling waiting for a uart read character. Some how when I took a look at the uart_read_q function, I concluded that it would return with “null” data if there was no new characters in the uart read queue. I think I imagined a { after the while (qout==qin) statement, never really thought it through. Your approach makes perfect sense now

I like your idea of using a couple of switches to select the target. Simpler than what I have done in the past probably easier to use too because no changes to makefiles or anything else is needed for it.

Noter

I am still having some problems getting ISP programming to work. Again I suspect something in the make file tat I am not getting correct. I have my Nerdkit ISP programmer connected to the SPI bus. I have attempted to reprogram the master micro on the SPI bus with the initialload code but failed to get it to work.
Should I be able to use the original initialload make file to do ISP programming? When I try that I get

Avrdude: error: programmer did not respond to command: select device make: ***[initialload-upload] Error 1

The ISP programmer is dropping the level on the master reset pin which would indicate that the programmer code has gone at least as far as my code in the enter_programing_mode function .

 uint8_t enter_programming_mode(void){
   if(!in_programming_mode){
      in_programming_mode=true;
      flash_byte_count=0;
      eeprom_byte_count=0;
      lcd_goto_position(3,0);
      fprintf_P(&lcd_stream, PSTR(BLANK_LINE));

    switch(PINC & 3){
        case 0:
        CLEAR(Master_Reset);
        break;

        case 1:
        CLEAR(Z_axis_Reset);
        break;

        case 2:
        CLEAR(Y_axis_Reset);
        break;

        case 3:
        CLEAR(X_axis_Reset);

    }

    SPCR = SPCR_enable_mask;
    _delay_ms(21);
    memcpy_P(SPI_Cmd,PSTR("\xAC\x53\x00\x00"),CMD_LEN);
    spi_cmd(SPI_Cmd, SPI_Reply, CMD_LEN);
    if(SPI_Reply[2]==0x53)
        return(SPI_OK);
    // get out of programming mode if something went wrong.
    leave_programming_mode();
    return(SPI_ERROR);
  }
   return(SPI_OK);
  }

I also tried to use the makefile used to load the boatloder from your library tutorial on ISP programmer.

I changed

  # AVRBOOT Noter's 1k bootloader
    PROGRAM=AVRBOOT

To

    # AVRBOOT Noter's 1k bootloader
    PROGRAM=initialload

I put it in a directory with a copy of intialload.c. That makefie produce a series of undefined reference to the lcd commands in the initialload..c code. It will not compile.

Again any help or suggestions would be greatly appreciated.

That is an unusual place for avrdude to get stuck because there is nothing going on in the select device logic other than to send back a <CR> no matter what device code avrdude sends. Zip up you directory and email it to me and I'll see if I can spot the problem. - NerdkitNoter@gmail.com