Welcome! Log In Create A New Profile

Advanced

Bootloader doesn't burn out. Help!!

Posted by sirbj 
Bootloader doesn't burn out. Help!!
July 26, 2012 06:51AM
Hey

I am having trouble whit burning the bootloader to my Extruder 2.2 board.
This is the error message i get:

avrdude: verification error, first mismatch at byte 0x381a
0x51 != 0x00
avrdude: verification error; content mismatch

I am using this to upload whit:
Arduino 18
Win 7 64bit
TinyUSBisp form ladyada.net

and the main chip is mark:
ATMEGA168
20AU 1118

when I traid to burned the bootloader, chose I the board:
Arduino Diecimila, Duemilanove, or Nano w/ ATmega168

and then burn bootloader w/ USBtinyISP.
Re: Bootloader doesn't burn out. Help!!
July 27, 2012 06:32AM
Arduino IDE is too intransparent for doing tricky stuff like bootloader upload. If it works, it's fine, but if it doesn't, you can't debug it. Use avrdude directly.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Bootloader doesn't burn out. Help!!
July 28, 2012 07:28AM
hey

thanks for the reply.

I dit as you said and used avrdude directly, I generated the .hex file whit ardruino 18 holding down the shift key while compiling, and fund it in windows temp, called extruder.cpp.hex.

And this is what happend:

c:\>avrdude -c usbtiny -p m168 -U flash:w:extruder.cpp.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9406
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed

To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "extruder.cpp.hex"
avrdude: input file extruder.cpp.hex auto detected as Intel Hex
avrdude: writing flash (4744 bytes):

Writing | ################################################## | 100% 3.03s



avrdude: 4744 bytes of flash written
avrdude: verifying flash memory against extruder.cpp.hex:
avrdude: load data flash data from input file extruder.cpp.hex:
avrdude: input file extruder.cpp.hex auto detected as Intel Hex
avrdude: input file extruder.cpp.hex contains 4744 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 2.70s



avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x038f
0x91 != 0x00
avrdude: verification error; content mismatch

avrdude: safemode: lfuse changed! Was ff, and is now 0
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: hfuse changed! Was dd, and is now 0
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK

avrdude done. Thank you.

dit not know what the last questions means, so just said no.

dont know if this is succe or not?
Re: Bootloader doesn't burn out. Help!!
July 29, 2012 06:56AM
4744 bytes is way to big for a bootloader, so you apparently write beyond the end of flash memory. With the usual fuse settings, the bootloader can be 2048 bytes maximum and accordingly starts at flash end minus 2048 bytes.

For comparison, with some luck you can compile the Gen7 bootloader to 1024 bytes and optiboot even claims to fit into 512 bytes (with a reduced feature set).

Are you sure you compile a bootloader there? If you have a programmer, uploading the firmware without bootloader is also fine.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Bootloader doesn't burn out. Help!!
July 29, 2012 12:38PM
hey

thanks for the reply.

I did try to upload the firmware directly to the chip, so the size is the one of the firmware and not of the bootloader.

I have the TinyUSBisp form ladyada.net which I have used as programmer, dont know if this works or not?


Now I have treid to burned a bootloader I used this guide from this page:

http://blog.spitzenpfeil.org/wordpress/2009/04/03/flashing-the-bootloader-with-usbtinyispavrdude/

and I got the same result as in the guide:


avrdude -p m168 -c usbtiny -e -u -U lock:w:0x3f:m -U efuse:w:0x00:m -U hfuse:w:0xDD:m -U lfuse:w:0xFF:m
 
avrdude: AVR device initialized and ready to accept instructions
 
Reading | ################################################## | 100% 0.01s
 
avrdude: Device signature = 0x1e9406
avrdude: erasing chip
avrdude: reading input file "0x3f"
avrdude: writing lock (1 bytes):
 
Writing | ################################################## | 100% 0.00s
 
avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3f:
avrdude: load data lock data from input file 0x3f:
avrdude: input file 0x3f contains 1 bytes
avrdude: reading on-chip lock data:
 
Reading | ################################################## | 100% 0.00s
 
avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "0x00"
avrdude: writing efuse (1 bytes):
 
Writing | ################################################## | 100% 0.02s
 
avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0x00:
avrdude: load data efuse data from input file 0x00:
avrdude: input file 0x00 contains 1 bytes
avrdude: reading on-chip efuse data:
 
Reading | ################################################## | 100% 0.00s
 
avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0xDD"
avrdude: writing hfuse (1 bytes):
 
Writing | ################################################## | 100% 0.02s
 
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xDD:
avrdude: load data hfuse data from input file 0xDD:
avrdude: input file 0xDD contains 1 bytes
avrdude: reading on-chip hfuse data:
 
Reading | ################################################## | 100% 0.00s
 
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xFF"
avrdude: writing lfuse (1 bytes):
 
Writing | ################################################## | 100% 0.02s
 
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xFF:
avrdude: load data lfuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip lfuse data:
 
Reading | ################################################## | 100% 0.00s
 
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
 
avrdude done.  Thank you.


avrdude -p m168 -c usbtiny -U flash:w:ATmegaBOOT_168_diecimila.hex -U lock:w:0x0f:m
 
avrdude: AVR device initialized and ready to accept instructions
 
Reading | ################################################## | 100% 0.02s
 
avrdude: Device signature = 0x1e9406
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "ATmegaBOOT_168_diecimila.hex"
avrdude: input file ATmegaBOOT_168_diecimila.hex auto detected as Intel Hex
avrdude: writing flash (16294 bytes):
 
Writing | ################################################## | 100% 51.78s
 
avrdude: 16294 bytes of flash written
avrdude: verifying flash memory against ATmegaBOOT_168_diecimila.hex:
avrdude: load data flash data from input file ATmegaBOOT_168_diecimila.hex:
avrdude: input file ATmegaBOOT_168_diecimila.hex auto detected as Intel Hex
avrdude: input file ATmegaBOOT_168_diecimila.hex contains 16294 bytes
avrdude: reading on-chip flash data:
 
Reading | ################################################## | 100% 29.46s
 
avrdude: verifying ...
avrdude: 16294 bytes of flash verified
avrdude: reading input file "0x0f"
avrdude: writing lock (1 bytes):
 
Writing | ################################################## | 100% 0.02s
 
avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x0f:
avrdude: load data lock data from input file 0x0f:
avrdude: input file 0x0f contains 1 bytes
avrdude: reading on-chip lock data:
 
Reading | ################################################## | 100% 0.00s
 
avrdude: verifying ...
avrdude: 1 bytes of lock verified
 
avrdude: safemode: Fuses OK
 
avrdude done.  Thank you.


this is the same command I used to upload the firmware from last time, it work fine this time.

c:\>avrdude -c usbtiny -p m168 -U flash:w:extruder.cpp.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9406
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed

         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "extruder.cpp.hex"
avrdude: input file extruder.cpp.hex auto detected as Intel Hex
avrdude: writing flash (4744 bytes):

Writing | ################################################## | 100% 3.06s



avrdude: 4744 bytes of flash written
avrdude: verifying flash memory against extruder.cpp.hex:
avrdude: load data flash data from input file extruder.cpp.hex:
avrdude: input file extruder.cpp.hex auto detected as Intel Hex
avrdude: input file extruder.cpp.hex contains 4744 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 2.71s



avrdude: verifying ...
avrdude: 4744 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

The problem I am having, is that I have put it back together and I dont think that it is working. When I open the Repetier-Host software (it is working all the axes move)

but the temperatur is not reading and I cant control the extruder motor.

sorry it is so long just want to provide all the info.
Re: Bootloader doesn't burn out. Help!!
July 29, 2012 08:07PM
Quote

but the temperatur is not reading and I cant control the extruder motor.

It's a firmware configuration issue now. Since when does Repetier support external extruder boards? AFAIK, only FiveD and Teacup do.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Bootloader doesn't burn out. Help!!
July 31, 2012 01:26PM
Hey

Thanks it almost works.

I have chance my host software to printrun by Kliment (http://reprap.org/wiki/Printrun),
and that gave me temperature control and reading.

only the motor is not moving, it is at stepper motor.
Is there a problem using a stepper motor whit 3 gen electronics and teacup firmware.

I am using Allegro A3949 as driver chips as specified in the build.
Re: Bootloader doesn't burn out. Help!!
August 01, 2012 06:43AM
Quote

Is there a problem using a stepper motor whit 3 gen electronics and teacup firmware.

No. Just configure STEP and DIR pins properly, like you did for the other steppers.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Bootloader doesn't burn out. Help!!
August 09, 2012 08:36AM
Hey

I have done that and triple checked, it all match up.

Is there some where I need to tell it that I use a stepper motor.

I cant be 100% sure because I don't own an oscilloscope, but the STEP is not pulsing.

any Ideas?
Sorry, only registered users may post in this forum.

Click here to login