Crash during upload if FEATURE_CONTROLLER 2 is set
Hi @all,
this one really got me stumped
Working setup: Atmega 2560, RAMPS 1.4 with a RepRap Discount Full Graphic Smart Controller; last FW-modification 2016-12-something, working like a charm.
Today I wanted to change the display to a (known woking on a second atmega 2560 + RAMPS 1.4) smaller one, namely "Smartcontroller from RepRapDiscount on a RAMPS or RUMBA board" because I want to use the big display on my current "work in progress"-printer.
No biggie, upload configuration.h to the FW-Builder, change the display, download the new FW (full download), fire up Arduino IDE, recompile + push to RepetierServer & upload and you are golden.
... or so I thought ...
What really happens is that the upload of the new firmware crashes after a few seconds and leaves the Atmega dead in the water (blank display, no connect, looks like it's bricked)
Since my Firmware-source-directory is under control of SVN I can *confirm* that the only change was "FEATURE_CONTROLLER 11" -> "FEATURE_CONTROLLER 2", as soon as I change this parameter back to 11, recompile and upload (and reset the connection from ArduinoIDE to the Atmega before...; this took me a few tries to figure this out) the Atmega comes back up as if nothing ever happened.
Output from the Arduino-IDE during upload with "FEATURE_CONTROLLER 2":
--
Sketch uses 114,814 bytes (45%) of program storage space. Maximum is 253,952 bytes.
Global variables use 4,124 bytes (50%) of dynamic memory, leaving 4,068 bytes for local variables. Maximum is 8,192 bytes.
C:\Program Files\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega2560 -cwiring -PCOM4 -b115200 -D -Uflash:w:C:\Users\xxx\AppData\Local\Temp\build2ef549dead76a3228082581ba812396b.tmp/Repetier.ino.hex:i
avrdude: Version 6.0.1, compiled on Apr 15 2015 at 19:59:58
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "C:\Program Files\Arduino\hardware\tools\avr/etc/avrdude.conf"
Using Port : COM4
Using Programmer : wiring
Overriding Baud Rate : 115200
AVR Part : ATmega2560
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PA0
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 10 8 0 no 4096 8 0 9000 9000 0x00 0x00
flash 65 10 256 0 yes 262144 256 1024 4500 4500 0x00 0x00
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : Wiring
Description : Wiring
Programmer Model: AVRISP
Hardware Version: 15
Firmware Version Master : 2.10
Vtarget : 0.0 V
SCK period : 43.5 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e9801
avrdude: reading input file "C:\Users\xxx\AppData\Local\Temp\build2ef549dead76a3228082581ba812396b.tmp/Repetier.ino.hex"
avrdude: writing flash (114814 bytes):
Writing | ###avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer
avrdude: stk500v2_ReceiveMessage(): timeout
--
Can somebody please clue me in what is going on here?
this one really got me stumped
Working setup: Atmega 2560, RAMPS 1.4 with a RepRap Discount Full Graphic Smart Controller; last FW-modification 2016-12-something, working like a charm.
Today I wanted to change the display to a (known woking on a second atmega 2560 + RAMPS 1.4) smaller one, namely "Smartcontroller from RepRapDiscount on a RAMPS or RUMBA board" because I want to use the big display on my current "work in progress"-printer.
No biggie, upload configuration.h to the FW-Builder, change the display, download the new FW (full download), fire up Arduino IDE, recompile + push to RepetierServer & upload and you are golden.
... or so I thought ...
What really happens is that the upload of the new firmware crashes after a few seconds and leaves the Atmega dead in the water (blank display, no connect, looks like it's bricked)
Since my Firmware-source-directory is under control of SVN I can *confirm* that the only change was "FEATURE_CONTROLLER 11" -> "FEATURE_CONTROLLER 2", as soon as I change this parameter back to 11, recompile and upload (and reset the connection from ArduinoIDE to the Atmega before...; this took me a few tries to figure this out) the Atmega comes back up as if nothing ever happened.
Output from the Arduino-IDE during upload with "FEATURE_CONTROLLER 2":
--
Sketch uses 114,814 bytes (45%) of program storage space. Maximum is 253,952 bytes.
Global variables use 4,124 bytes (50%) of dynamic memory, leaving 4,068 bytes for local variables. Maximum is 8,192 bytes.
C:\Program Files\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega2560 -cwiring -PCOM4 -b115200 -D -Uflash:w:C:\Users\xxx\AppData\Local\Temp\build2ef549dead76a3228082581ba812396b.tmp/Repetier.ino.hex:i
avrdude: Version 6.0.1, compiled on Apr 15 2015 at 19:59:58
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "C:\Program Files\Arduino\hardware\tools\avr/etc/avrdude.conf"
Using Port : COM4
Using Programmer : wiring
Overriding Baud Rate : 115200
AVR Part : ATmega2560
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PA0
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 10 8 0 no 4096 8 0 9000 9000 0x00 0x00
flash 65 10 256 0 yes 262144 256 1024 4500 4500 0x00 0x00
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : Wiring
Description : Wiring
Programmer Model: AVRISP
Hardware Version: 15
Firmware Version Master : 2.10
Vtarget : 0.0 V
SCK period : 43.5 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e9801
avrdude: reading input file "C:\Users\xxx\AppData\Local\Temp\build2ef549dead76a3228082581ba812396b.tmp/Repetier.ino.hex"
avrdude: writing flash (114814 bytes):
Writing | ###avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer
avrdude: stk500v2_ReceiveMessage(): timeout
--
Can somebody please clue me in what is going on here?
Comments
- adding a second language (EN / LANGUAGE_EN_ACTIVE was 1, additionally changed LANGUAGE_DE_ACTIVE to 1) didn't change anything, still freezing.
- Uploading a build with FEATURE_CONTROLLER 0 (back to EN as the only language) worked.
On a hunch I swapped the "Smart adapter (rrd)" on the RAMPS itself.. and lo FW-upload works.
Looking at both of them the only difference seems to be that the non-working one has a white PCB-board, the other one's red; no other components visible except the headers; e.g. "Smartcontroller from RepRapDiscount on a RAMPS or RUMBA board" with "Smart adapter (rrd)"-white crashes the upload but uploading works with "Smart adapter (rrd)"-red.
I still don't get it why this should have any influence on the upload, especially when the display isn't even connected- and I could kick myself for _not_ trying a upload with a disconnected smart adapter and connecting afterwards (too late atm since a print is running) but...
/go figure
-> CLOSED: Hardware-Problem / Layer10-Error / ID10T ;-)
as always thanks for your outstanding support!
P.S.: found the !!! / 0x212121-Bug (Feature??) today, now this is a nasty one... (sounds like Windows-troubleshooting: "just reboot, maybe it's gone", only the other way around: "add <X> and rebuild .." :-D)