Failure to flash self compiled firmware  

  RSS
andreas.b2
(@andreas-b2)
Active Member

I have forked Prusa's firmware to backport PINDA V2 temperature calibration from Mk3/3.3.1 to Mk2/3.1.0 at https://github.com/baloan/Prusa-Firmware . The code compiles successfully but when flashing my Mk2S/Rambo 1.3 I encounter two errors:

  • stk500v2_command(): command failed

  • verification error, first mismatch at byte 0x3e000
  • I know the PINDA temperature calibration uses EEPROM memory to store the calibration profile. I hoped changing the version number to 3.1.9 would trigger handling of the new memory in the firmware. Anyone knows what the correct way is to make sure firmware handles changed EEPROM memory usage properly?
    After booting the Rambo the LCD would remain unresponsive.
    Flashing back to Mk2/3.1.0 after, then factory reset, worked without issues.

    Full details here:

    avrdude: Version 6.3-20160220-prusa3d, compiled on Jul 5 2018 at 16:02:35
    Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
    Copyright (c) 2007-2014 Joerg Wunsch

    System wide configuration file is "C:/PROGRA~1/Prusa3D/Slic3rPE/resources\avrdude\avrdude.conf"

    Using Port : COM3
    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 : 0.1 us

    avrdude: AVR device initialized and ready to accept instructions

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

    avrdude: Device signature = 0x1e9801 (probably m2560)
    avrdude: safemode: hfuse reads as D0
    avrdude: safemode: efuse reads as FD
    avrdude: reading input file "C:\Users\andreas\Downloads\Firmware-Mk2SX-3.1.9.hex"
    avrdude: writing flash (256244 bytes):
    avrdude: stk500v2_command(): command failed

    Writing | ################################################## | 100% 44.30s

    avrdude: 256244 bytes of flash written
    avrdude: verifying flash memory against C:\Users\andreas\Downloads\Firmware-Mk2SX-3.1.9.hex:
    avrdude: load data flash data from input file C:\Users\andreas\Downloads\Firmware-Mk2SX-3.1.9.hex:
    avrdude: input file C:\Users\andreas\Downloads\Firmware-Mk2SX-3.1.9.hex contains 256244 bytes
    avrdude: reading on-chip flash data:

    Reading | ################################################## | 100% 32.01s

    avrdude: verifying ...
    avrdude: verification error, first mismatch at byte 0x3e000
    0x0d != 0xf8
    avrdude: verification error; content mismatch

    avrdude: safemode: hfuse reads as D0
    avrdude: safemode: efuse reads as FD
    avrdude: safemode: Fuses OK (E:FD, H:D0, L:FF)

    avrdude done. Thank you.

    ...
    Posted : 25/08/2018 11:35 am
    PJR
     pjr
    (@pjr)
    Antient Member Moderator

    I think this is down to the language variants (loaded to additional EEProm on the Einsy) which is flashed as a second write/read process.

    I had exactly the same result on the Mk3 when attempting to flash without the language variants.

    Not sure how far you will get with this; you may want to confer with Waldemar (see "Hyperfine" thread)

    Peter

    Please note: I do not have any affiliation with Prusa Research. Any advices given are offered in good faith. It is your responsibility to ensure that by following my advice you do not suffer or cause injury, damage…...
    Posted : 25/08/2018 3:34 pm
    andreas.b2
    (@andreas-b2)
    Active Member

    Thanks for your feedback.
    I think this is down to the language variants (loaded to additional EEProm on the Einsy) which is flashed as a second write/read process.

    How have you resolved your issue?

    Some reasons why language variants might not apply in my case:
    1. I'm working on a Mk2 Rambo 1.3a
    2. my firmware is based on the MK2 branch v3.1.0 and compiles. It is a Mk2 firmware and its language variants are in the same directory. There is no separate lang directory, just Firmware.
    3. I compiled the MK2 branch, tags/v3.1.0 firmware unaltered successfully, and I'm still getting verification error, first mismatch at byte 0x3c000, while the pre-compiled 1_75mm_MK2-RAMBo13a-E3Dv6full.hex works fine.

    I suspect that my hex files are to big:
    1_75mm_MK2-RAMBo13a-E3Dv6full.hex 241578 bytes works ok
    Firmware-Mk2-3.1.0.hex 252644 bytes fails to verify at 0x3c000 = 245760 bytes.

    But maybe there is a trick I am not aware of.
    How do I get in touch with Waldemar? Should I PM him?

    Related articles:
    https://www.avrfreaks.net/forum/verification-error-when-programming-raspberry-pi-avrdude-linuxgpio-bitbang Description of bootloader bug
    https://github.com/prusa3d/Prusa-Firmware/issues/910 Other Prusa owners having the same issue
    https://learn.sparkfun.com/tutorials/installing-an-arduino-bootloader Details on RAMBo bootloader flashing

    ...
    Posted : 25/08/2018 3:46 pm
    PJR
     pjr
    (@pjr)
    Antient Member Moderator

    The issue was resolved as soon as I uploaded firmware with the language variants.

    I am pretty sure it's not down to size (but it may be); more likely to be the double flashing; I think there is something somewhere telling something else to expect a second flash, and when that doesn't happen, it breaks. Of course the double-flash cannot happen in the 1.3a, but a flag may still be set in firmware source.

    You may as well PM Waldemar; I think he may be having a similar issue with the Einsy.

    Peter

    Please note: I do not have any affiliation with Prusa Research. Any advices given are offered in good faith. It is your responsibility to ensure that by following my advice you do not suffer or cause injury, damage…...
    Posted : 25/08/2018 7:59 pm
    andreas.b2
    (@andreas-b2)
    Active Member

    I tried Arduino IDE 1.8.6 instead of using 1.6.9 as recommended on https://github.com/prusa3d/Prusa-Firmware . Arduino IDE 1.8.6 compiles the 3.1.0 stock and my PINDA V2 backport without issues - and compiles smaller hex files.
    Firmware.ino.rambo-3.1.9.hex Size: 0x3bcbc
    0x3bcbc which is smaller than 0x3c000 and does not clash with bootloader storage. Flashing this image to my RAMBo 1.3a was successful.

    ...
    Posted : 26/08/2018 2:19 pm
    Share:

    Please Login or Register