spdir flashing, verification error content mismatch

Home › Forums › TinyG › TinyG Support › spdir flashing, verification error content mismatch

Tagged: 

Viewing 15 posts - 16 through 30 (of 47 total)
1 2 3 4
  • Author
    Posts
  • November 27, 2015 at 8:51 pm #9001
    MockTurtle
    Member

    its the latest spjs version? …running on a raspberry pi.

    iirc, garbled text was in the console as i pressed run. it could also have been in the gcode window… its all fuzzy now.
    thought gcode actually loaded up fine in chillipeppr as the toolpaths looked right in the graphical viewer.

    chillipeppr on win 7 x64 machine.

    440.20 firmware on the tinyg.

    hmmm was connecting through wifi on my laptop. could wifi be a cause?

    i currently don’t have an avr programmer… but if need be i could buy one i guess. if it’ll fix the board for sure??? i’m based in south africa so logistics is a bit of an issue :-/

    November 27, 2015 at 9:25 pm #9002
    cmcgrath5035
    Moderator

    OK, you were running tinyG 440.20.
    Now you have a constantly flashing spinDir LED?
    That means bootloader is running
    You then tried to reload 440.20?
    And your did that using the SPJS 1.86 on RasbPi FW upgrade process?
    And then your saw the verification error?

    BTW, no obvious reason WiFi connection to SPJS would be the issue

    November 27, 2015 at 10:25 pm #9003
    MockTurtle
    Member

    nope never tried updating through Raspberry… plugged the tinyg into my winx64 machine via usb and used avrdude. i get exact same behaviour as KingBubbaTruck describes. also tried -e in command line with no success. gonna try updating using my mac… though i doubt it will make a difference…
    and hey thanks for trying to help…

    November 27, 2015 at 10:36 pm #9004
    MockTurtle
    Member

    ok. no joy updating using updater app under osx.

    Connecting to programmer: .
Found programmer: Id = "XBoot++"; type = S
    Software Version = 1.7; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=512 bytes.

Programmer supports the following devices:
    Device code: 0x7b

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9744
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 "tinyg-master-440.20.hex"
avrdude: input file tinyg-master-440.20.hex auto detected as Intel Hex
avrdude: writing flash (118274 bytes):

Writing | ################################################## | 100% 11.15s

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

Reading | ################################################## | 100% 14.16s

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

avrdude done.  Thank you.
    November 28, 2015 at 6:53 am #9006
    cmcgrath5035
    Moderator

    nope never tried updating through Raspberry… plugged the tinyg into my winx64 machine via usb and used avrdude. i get exact same behaviour as KingBubbaTruck describes. also tried -e in command line with no success. gonna try updating using my mac… though i doubt it will make a difference…
    and hey thanks for trying to help…

    Please be a bit more specific (I am gathering data here)

    On Win64, you attempted to flash from a CMD window, using avrdude from arduino dev environment? Or describe

    On OSx, you used the tinyGUpdater app from Synthetos web? or ?

    This looks like a fuse issue, for which a solution may soon be available (being worked by devs), this info may help.

    Have you done FW updates successfully in the past?
    It is not at all clear (to me) how fuse state could be changed.

    November 28, 2015 at 7:18 am #9008
    MockTurtle
    Member

    no worries. i’ll provide more info as required. thanks again for the feedback.

    >> On Win64, you attempted to flash from a CMD window, using avrdude from arduino dev environment?
    affirmative. i even tried using latest avrdude version. same results unfortunately.

    >> On OSx, you used the tinyGUpdater app from Synthetos web?
    yup. used the app. result as above (in my previous post).

    yes i did initially update the firmware when i first got the tinyg a few months back (using avrdude/winx64). then again i think when 440.20 came out? ..or was that spjs release… i make a point of keeping everything updated to the latest ‘stable’ release. in any case all was going swimmingly as i was building my machine…. until yesterday. never thought chillipeppr can be so vicious like that! also i only had stepper motors and the RasPi connected to the tinyg. no limit switches/superpid or anything like that yet.

    only thing i haven’t tried is using a atmel programmer as i don’t have one… do have a mini adafruit programmer jobbie but i don’t think that’ll work with the chip on the tinyg…

    November 28, 2015 at 7:23 am #9009
    cmcgrath5035
    Moderator

    only thing i haven’t tried is using a atmel programmer as i don’t have one… do have a mini adafruit programmer jobbie but i don’t think that’ll work with the chip on the tinyg…

    I asked the tinyGupdater dev to look at this thread.
    I believe he is working on a fix for this situation, has a Win64 beta that might help.

    November 28, 2015 at 10:29 am #9010
    KingBubbaTruck
    Member

    Is there someway to view the status of the lock bits and fuses without and avrisp MKII? I’ve got one on order, but just wondering if there’s more info we could collect?

    November 29, 2015 at 7:57 am #9014
    cmcgrath5035
    Moderator

    The only documentation I could find requires the programmer to read the bits

    November 29, 2015 at 8:57 am #9015
    MockTurtle
    Member

    so i guess at this point it looks like i’d have to get a programmer to get up and running again. no other option right?

    November 29, 2015 at 1:01 pm #9020
    KingBubbaTruck
    Member

    FWIW, I haven’t done this before, but I do have a programmer on order. Unfortunately, it’s being shipped from china, and won’t be here for a little while.

    I did read that just any programmer won’t do, as you need one that supports the PDI interface used by the mega.

    Here’s where I got the info on the programmer required and how to do it.

    https://github.com/synthetos/TinyG/wiki/Programming-TinyG-with-an-External-Programmer

    November 29, 2015 at 1:02 pm #9021
    KingBubbaTruck
    Member

    Oh, And this link too might come in useful later.

    https://github.com/synthetos/TinyG/wiki/Firmware-Update-Verification-Failure

    December 1, 2015 at 12:08 am #9051
    ril3y
    Keymaster

    Mockturtle,

    I should have brents board in a few days. What I am hoping is that it’s not actually bricked beyond repair with a AVRISP programmer. That is my goal. Then we can work together to get you a fix for your board. However, if the board’s fuses are incorrect then I think it might be safe to assume you might have got a few of the “badly flashed” boards that went out. This is a new issue for us. Specifically the issue of HAVING a bootloader but not having the fuses set correctly. This is one of the guesses I have for the situation we find you and brent in. However it has never happened before. We have shipped WITHOUT bootloaders but never without the fuses set correctly AND having a bootloader.

    I am hopeful that when I get the board it can be fixed without a programmer. However I cannot swear by this. Another option since you are in a different country is to reach out to a local hackerspace to see if they have an AVR available. I do not suggest this to shift the work onto you, but rather as a time saving option. Like you know it takes time to get a new board to South Africa. If I shipped it today you may not have it before the new year. However if this is the option that you would like to go please let me know and we can start that process.

    Rest assured that we WILL get you up and running asap. We are very sorry for your issue with your TinyG board and are trying to fix you up!

    ril3y

    December 1, 2015 at 5:13 am #9054
    MockTurtle
    Member

    hey ril3y,
    thanks for the feedback and taking the time looking into this…
    at this juncture i think its best to wait for the diagnosis on brent’s board… and that its fixable.
    in the mean time i’ve been trying to get hold of an avr locally… all else fails i’ll have to take you up on that replacement :-/

    December 7, 2015 at 9:07 am #9085
    nicholasleigh
    Member

    Has this issue been solved yet? Im still waiting to hear back and was told to wait because i could do the fix myself instead of sending the board back for a replacement. Its been 6 days now since i have had any contact. I was told that there would be a write up before ril3y gets the boads to look at and i could test to see if it fixes the problem

  • Author
    Posts
Viewing 15 posts - 16 through 30 (of 47 total)
1 2 3 4
  • You must be logged in to reply to this topic.