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?


Comments

  • Try changing some feaures or add a language for lcd. The bootloader has a bad habit of stopping to work if it receives !!! Yes three !. This can sometimes happen in binary code depending on features enabled etc. Might als O be a simple upload problem that sometimes happens and vanishes after some tries,
  • Hi!

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




Sign In or Register to comment.