Gen7 1.5 Bootloader issues

Hi,

I just finished building up my Gen7 1.5 board. Flashing the 1284p with an external ISP programmer and the latest Teacup firmware from Traumflug's git repo worked just fine.

Next, I tried flashing the Gen7 bootloader. While I think it went successfully, a firmware uploaded via usb just doesn't work.

$ make -f Makefile-AVR program 
avrdude -c stk500v2 -b 115200 -p atmega1284p -P /dev/ttyACM0 -U flash:w:teacup.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9705
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 "teacup.hex"
avrdude: input file teacup.hex auto detected as Intel Hex
avrdude: writing flash (16386 bytes):

Writing | ################################################## | 100% 2.15s

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

Reading | ################################################## | 100% 1.62s

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

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Pronterface just won't connect to the printer. If I re-flash the micro with an external ISP adapter again, pronterface works fine, but the bootloader seems gone. I can communicate with the printer, but I can't flash a new firmware via USB.

$ avrdude -c stk500v1 -b 115200 -p atmega1284p -P /dev/ttyUSB0 -U flash:w:teacup.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9705
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 "teacup.hex"
avrdude: input file teacup.hex auto detected as Intel Hex
avrdude: writing flash (16386 bytes):

Writing | ################################################## | 100% 45.68s

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

Reading | ################################################## | 100% 44.78s

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

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

While I can certainly live with 'just' a working printer, a working bootloader on top would be great. Pointers, anyone?

Kind regards, Walter

I've just installed the setup test firmware from Traumflug's git repo and it works well. So I assume, that the bootloader is actually fine. The remaining question is, why can't pronterface communicate with the printer? This is how I flashed the teacup firmware:

$ cp ThermistorTable.double.h ThermistorTable.h
$ cp config.gen7-v1.4.h config.h
$ make -f Makefile-AVR program 
  CC        build/usb_serial.o
  CC        build/copier.o
  CC        build/home.o
  CC        build/dda_queue.o
  CC        build/crc.o
  CC        build/sermsg.o
  CC        build/serial.o
serial.c: In function '__vector_20':
serial.c:120:11: warning: variable 'trash' set but not used [-Wunused-but-set-variable]
  CC        build/intercom.o
  CC        build/pinio.o
  CC        build/clock.o
  CC        build/heater.o
  CC        build/mendel.o
  CC        build/gcode_process.o
  CC        build/analog.o
  CC        build/delay.o
  CC        build/debug.o
  CC        build/temp.o
  CC        build/gcode_parse.o
  CC        build/watchdog.o
  CC        build/graycode.o
  CC        build/sersendf.o
  CC        build/dda.o
  CC        build/timer.o
  CC        build/dda_maths.o
  CC        build/sd.o
  LINK      build/teacup.elf
  OBJCOPY   teacup.hex
avrdude -c stk500v2 -b 115200 -p atmega1284p -P /dev/ttyACM0 -U flash:w:teacup.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9705
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 "teacup.hex"
avrdude: input file teacup.hex auto detected as Intel Hex
avrdude: writing flash (16386 bytes):

Writing | ################################################## | 100% 2.15s

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

Reading | ################################################## | 100% 1.62s

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

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

I get the same result, when I try uploading the included pde with the arduino IDE.

Edited 1 time(s). Last edit at 06/16/2013 06:23PM by waltersteinlein.

Ok, after further investigation, it seems like the firmware is actually flashed to the device. A serial monitor throws "start ok" at me when I connect to it at 115.2kbaud.

Now comes the odd stuff: If I keep the serial monitor opened and start up pronterface or pronsole and close the serial monitor, I can connect to the printer. Everyting works as expected, LEDs are turning on and off, Motors are rotating. When I disconnect and try to reconnect, it fails.

I first suspected the ripple from the switch mode psu being too high, but I see the same behaviour with an external linear bench supply. A broken bypass cap is possible, but highly unlikely, since I'm seeing the exact same behaviour on a second Gen7 board. Disabled brountout detection makes no difference.

The damn thing works fine if I flash the firmware via an external ISP progammer without the bootloader. Again, any pointers are greatly appreciated.

All the listings above look perfectly fine. This seems to be an issue with Pronterface or Pronterfaces' setup.

Are you sure you select the right device in Pronterface (drop down menu in the upper left corner)?

A bit more in depth: Looking at line 148 of printcore.py [github.com] , the timeout was reduced from 5 seconds to just 0.25 seconds, compared to the older Printrun version I use myself. No idea what's the point of that, but in case "connect" means to read something from the serial line, 0.25s is too short to wait for the bootloader to hand over operations to the regular firmware. Gen7 bootloaders wait about 3 seconds after a reset for incoming programming connections.

My Pronterface was checked out Aug 25, 2012, commit 7e38278c7ded9d7c80b9256b920d9ac2ed535f2c (never change a running system!).

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hey Traumflug! Thanks a lot for your reply.

I checkout the older printrun version and indeed, it works! I guess, the Gen7 bootloader is the recommended one for the Gen7 board (obviously, d'oh), but could you point me to the line of code, where the bootloader waits for 3 seconds. I'd really like to change that so that I can use my Gen7 board with the printrun version my distribution provides.

Oh and btw, shouldn't the bootloader address be specified in the makek script? Something like:

--- make.sh.orig	2013-06-17 14:01:55.835730588 +0200
+++ make.sh	2013-06-17 14:03:52.133685890 +0200
@@ -20,27 +20,27 @@
 cp -r "Gen7-dist"/* "${IDE_DIR}"
 
 # Build all required variants of bootloaders.
-(cd "${FLEURY_DIR}" && make MCU=atmega644 F_CPU=16000000)
+(cd "${FLEURY_DIR}" && make MCU=atmega644 F_CPU=16000000 BOOTLOADER_ADDRESS=F800)
 mv "${FLEURY_DIR}/stk500boot.hex" "${BOOTLOADERS_DIR}/bootloader-644-16MHz.hex"
 (cd "${FLEURY_DIR}" && make clean)
 
-(cd "${FLEURY_DIR}" && make MCU=atmega644 F_CPU=20000000)
+(cd "${FLEURY_DIR}" && make MCU=atmega644 F_CPU=20000000 BOOTLOADER_ADDRESS=F800)
 mv "${FLEURY_DIR}/stk500boot.hex" "${BOOTLOADERS_DIR}/bootloader-644-20MHz.hex"
 (cd "${FLEURY_DIR}" && make clean)
 
-(cd "${FLEURY_DIR}" && make MCU=atmega644p F_CPU=16000000)
+(cd "${FLEURY_DIR}" && make MCU=atmega644p F_CPU=16000000 BOOTLOADER_ADDRESS=F800)
 mv "${FLEURY_DIR}/stk500boot.hex" "${BOOTLOADERS_DIR}/bootloader-644P-16MHz.hex"
 (cd "${FLEURY_DIR}" && make clean)
 
-(cd "${FLEURY_DIR}" && make MCU=atmega644p F_CPU=20000000)
+(cd "${FLEURY_DIR}" && make MCU=atmega644p F_CPU=20000000 BOOTLOADER_ADDRESS=F800)
 mv "${FLEURY_DIR}/stk500boot.hex" "${BOOTLOADERS_DIR}/bootloader-644P-20MHz.hex"
 (cd "${FLEURY_DIR}" && make clean)
 
-(cd "${FLEURY_DIR}" && make MCU=atmega1284p F_CPU=16000000)
+(cd "${FLEURY_DIR}" && make MCU=atmega1284p F_CPU=16000000 BOOTLOADER_ADDRESS=1F800)
 mv "${FLEURY_DIR}/stk500boot.hex" "${BOOTLOADERS_DIR}/bootloader-1284P-16MHz.hex"
 (cd "${FLEURY_DIR}" && make clean)
 
-(cd "${FLEURY_DIR}" && make MCU=atmega1284p F_CPU=20000000)
+(cd "${FLEURY_DIR}" && make MCU=atmega1284p F_CPU=20000000 BOOTLOADER_ADDRESS=1F800)
 mv "${FLEURY_DIR}/stk500boot.hex" "${BOOTLOADERS_DIR}/bootloader-1284P-20MHz.hex"
 (cd "${FLEURY_DIR}" && make clean)

Quote

I checkout the older printrun version and indeed, it works!

Looks like it's time to file a bug in Printrun.

Quote

could you point me to the line of code, where the bootloader waits for 3 seconds

Line 359ff of stk500boot.c:

#ifdef ALWAYS_WAIT_FOR_PROGRAMMER
    // this factor 11. was found experimental
    uint32_t timeout = ( (uint32_t)((float)F_CPU * PROGRAMMER_WAIT_SECONDS / 11.) );
#endif

Quote

shouldn't the bootloader address be specified

It is. See line 58ff of the Makefile:

ifeq ($(MCU), atmega644)
  BOOTLOADER_ADDRESS =  F800
endif
ifeq ($(MCU), atmega644p)
  BOOTLOADER_ADDRESS =  F800
endif
ifeq ($(MCU), atmega1284p)
  BOOTLOADER_ADDRESS = 1F800
endif

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote

It is. See line 58ff of the Makefile:

Well, my makefile looks a little different:

# Bootloader
# Please adjust if using a different AVR
# Find the correct value in the "Boot Loader Parameters" section of the
# chip's data sheet. It's the lower value in the "Boot Loader Flash Section"
# and must be multiplied by 2, as the numbers in these tables are word sized.
# 0x0e00*2=0x1C00 for ATmega8  512 words Boot Size
# ATmega644(P),  512 words boot size: FC00
# ATmega644(P), 1024 words boot size: F800
BOOTLOADER_ADDRESS = F800

Hey Traumflug!

Do you want to push your makefile to the git repo? I can happily live with the binary zip version, but I've tried the ones I get along with the gerbers first and only started searching when I had some troubles. It might help other people. Changing the bootloader address seems obvious in retrospective but might be quite an obstacle for others.

Quote

Do you want to push your makefile to the git repo?

The problem was, about a year ago I removed all intermediate work from the public repo, resulting in two Gen7 repositories, one for development and one for the public. Too many people were building untested and half-done stuff instead of the latest release, complaining it wouldn't work.

To save work I made a script for doing these releases, copying all stuff over, then making and tagging a commit. Well, almost. A number of files were forgotten and obsolete files weren't removed. This should be fixed now: [github.com]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks a lot!

Hi all,

I've been building my Mendel for some time now, using Gen7 1.3 electronics purchased, assembled and had basic tests over a year ago.
I've just finished the wiring and am at the testing stage. I'm using Arduino 1.0.5, loaded Traumflugs mini test and happily the AT power supply switched on and the lights blinked. I went ahead and loaded up Teacup firmware, sent an M114 and got the expected response.

Downloaded Pronterface yesterday (Reprappro_printrun_slic3r.zip for Windoze) and unpacked it. I can't get it to connect to the printer. When I try to connect, I get 'Connecting...' and the Rx light flashes on the USB adapter (Sparkfun, with the Gen7 kit of parts) about every second. Just once, I saw 'M105' appear repeatedly in the console window but no response.

If I use the Arduino IDE, I can send G-code and the printer responds but when the move finishes, the motors sit 'grumbling' with both heater lights flickering. If I send an M105 from the IDE, the response I get is 'OK, T:874.25 B;872.75' I don't have either heater connected and I have resistors connected where the thermistors should live.

I've searched the forums (Fora?) to no avail. The closest hit was with the oscillating v1.5 so I bridged out the 100uh but no joy.

I apologise for the lengthy post but I'm at my wits end. Any suggestions?

Philip.

---

Philip Mac Cabe
Irish, Retired and loving it.

Quote

If I send an M105 from the IDE, the response I get is 'OK, T:874.25 B;872.75'

Obviously, both of your thermistors are shorted. A short gives very high temperature readings.

Regarding the trouble with the RepRapPro Software I can't help much. Generic Pronterface works fine: [github.com]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug,

Thanks for the very timely response.

Obviously I had already checked for shorts in the thermistor area and found none. I checked again this AM just to be sure age was not catching up on me (too fast).

I did mention Gen7 1.3 electronics. The M105 output I posted last evening was obviously when the power supply was not active. When the supply is activated, the temps are good. I remember reading about mods to have the thermistors read at standby and obviously I need to look at this again. Stupid me.

The grumbling motors are simply when the Pololus are in standby after a move, so that's also OK. Stupid me again.

Pronterface still refuses to converse.

I'm waiting for parts for the extruder and hot bed so I'll investigate further while working on that.

Thanks again.

---

Philip Mac Cabe
Irish, Retired and loving it.

Traumflug,

Picture me sitting here with a large red face!

I read the Gen7 1.3 build instructions RIGHT TO THE BOTTOM this time and found again the instructions for the standby thermistor mod.

Tracks cut and links added, temperature is now reported on standby.

Forums are great but instructions are better, when read fully ;-')

---

Philip Mac Cabe
Irish, Retired and loving it.

Traumflug,

Just to close off this conversation, I downloaded Pronterface from the link to Kliment you so kindly provided and success. Connected immediately and all works (even the temperature)

Should I replace the choke with a 10uh item?

Thanks again for all the effort you've put into Gen7. It's very much appreciated.

---

Philip Mac Cabe
Irish, Retired and loving it.

Quote

Forums are great but instructions are better, when read fully

Wise words!

Quote

Should I replace the choke with a 10uh item?

If your firmware works, there's no hurry to do this. The symptom it fixes is a firmware resetting right after startup, so you end in an endless reboot cycle.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY