Did I blow up my board?

Home › Forums › TinyG › TinyG Support › Did I blow up my board?

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • March 31, 2013 at 3:38 pm #3968
    cmagagna
    Member

    I just mounted my board in its new enclosure. I’ve got the USB, power, and fan connected but no motors or switches yet.

    When I power the board up I see the bootloader LED flash and via putty (or the Arduino IDE serial monitor) I see the normal boot prompt but when I try most commands ($x, $4, etc.) the bootloader LED starts flashing again and the board stops responding to the serial port until I reset it.

    $ works, and gives me this:

    [fb] firmware build 370.08
    [fv] firmware version 0.95
    [hv] hardware version 7.00
    [id] TinyG ID 9H3906-XWP
    [ja] junction acceleration 100000 mm
    [ct] chordal tolerance 0.010 mm
    [st] switch type 0 [0=NO,1=NC]
    [ej] enable json mode 0 [0=text,1=JSON]
    [jv] json verbosity 4 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]
    [tv] text verbosity 1 [0=silent,1=verbose]
    [qv] queue report verbosity 0 [0=off,1=filtered,2=verbose]
    [sv] status report verbosity 1 [0=off,1=filtered,2=verbose]
    [si] status interval 100 ms
    [ic] ignore CR or LF on RX 0 [0=off,1=CR,2=LF]
    [ec] expand LF to CRLF on TX 0 [0=off,1=on]
    [ee] enable echo 1 [0=off,1=on]
    [ex] enable xon xoff 0 [0=off,1=on]
    [baud] USB baud rate 5 [1=9600,2=19200,3=38400,4=57600,5=115200,6=230400]
    [gpl] default gcode plane 0 [0=G17,1=G18,2=G19]
    [gun] default gcode units mode 1 [0=G20,1=G21]
    [gco] default gcode coord system 1 [1-6 (G54-G59)]
    [gpa] default gcode path control 2 [0=G61,1=G61.1,2=G64]
    [gdi] default gcode distance mode 0 [0=G90,1=G91]
    tinyg [mm] ok>

    but $$ gives me this, then the bootloader LED starts flashing:

    [fb] firmware build 370.08
    [fv] firmware version 0.95
    [hv] hardware version 7.00
    [id] TinyG ID 9H3906-XWP
    [ja] junction acceleration 100000 mm
    [ct] chordal tolerance 0.010 mm
    [st] switch type 0 [0=NO,1=NC]
    [ej] enable json mode 0 [0=text,1=JSON]
    [jv] json verbosity 4 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]
    [tv] text verbosity 1 [0=silent,1=verbose]
    [qv] queue report verbosity 0 [0=off,1=filtered,2=verbose]
    [sv] status report verbosity 1 [0=off,1=filtered,2=verbose]
    [si] status interval 100 ms
    [ic] ignore CR or LF on RX 0 [0=off,1=CR,2=LF]
    [ec] expand LF to CRLF on TX 0 [0=off,1=on]
    [ee] enable echo 1 [0=off,1=on]
    [ex] enable xon xoff 0 [0=off,1=on]
    [baud] USB baud rate 5 [1=9600,2=19200,3=38400,4=57600,5=115200,6=230400]
    [gpl] default gcode plane

    I tried reflashing the board but avrdude gives a verification error so I’m not sure if it’s successful or not:

    C:Program Filesarduino-1.0.4hardwaretoolsavrbin>avrdude -C ..etcavrdude.conf -p x192a3 -c avr109 -b 115200 -P COM27 -U flash:w:tinyg.hex

    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.00s

    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.hex"
    avrdude: input file tinyg.hex auto detected as Intel Hex
    avrdude: writing flash (97478 bytes):

    Writing | ################################################## | 100% 9.66s

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

    Reading | ################################################## | 100% 11.78s

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

    avrdude done. Thank you.

    Is there anything else I can try, or did I zap the board somehow when I installed it and now it’s ruined?

    Thanks for any help,

    Chris

    March 31, 2013 at 3:43 pm #3969
    cmagagna
    Member

    I should say I’ve also tried resetting the board to factory default settings ($defa=1), different baud rates, turning off flow control, a different computer, etc. all with the same result.

    April 1, 2013 at 8:29 pm #3976
    Chris
    Member

    I’ve hit the same problem. I tried searching but couldn’t find your link. Can you post it? Thanks.

    April 2, 2013 at 1:00 am #3977
    Riley
    Keymaster

    Hey there guys,

     

    I just verified that in Windows I was able to flash via Arduino’s avrdude.

     

    C:\Users\ril3y\Desktop\arduino-1.0.2\hardware\tools\avr\bin>avrdude -C ..\etc\avrdude.conf -p x192a3 -c avr109 -b 115200 -P COM99 -U flash:w:tinyg.hex

     

    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.hex”

    avrdude: input file tinyg.hex auto detected as Intel Hex

    avrdude: writing flash (96706 bytes):

     

    Writing | ################################################## | 100% 12.10s

     

     

     

    avrdude: 96706 bytes of flash written

    avrdude: verifying flash memory against tinyg.hex:

    avrdude: load data flash data from input file tinyg.hex:

    avrdude: input file tinyg.hex auto detected as Intel Hex

    avrdude: input file tinyg.hex contains 96706 bytes

    avrdude: reading on-chip flash data:

     

    Reading | ################################################## | 100% 12.01s

     

     

     

    avrdude: verifying …

    avrdude: 96706 bytes of flash verified

     

    avrdude done.  Thank you.

     

    This MIGHT be the bootloader that is on your boards.  We might need to update the firmware (read this as re flash the xboot.hex file) with the current xboot firmware.

    April 5, 2013 at 4:11 pm #3980
    cmagagna
    Member

    Hi Riley,

    Thanks for your input. I see that you’re using Arduino 1.0.2 and I had 1.0.4 so I just tried with the older version but unfortunately get the same result.

    I don’t have an AVR programmer but just ordered one so I can try reflashing the xboot.hex bootloader without having to send the board back to you guys again. I’ll post again once I’ve tried this.

    Chris

     

    April 10, 2013 at 8:55 pm #3994
    cmagagna
    Member

    I just got an AVR programmer and have tried reflashing the bootloader but keep getting this error:

    Verifying Flash…Failed! address=0x31000 expected=0x1f actual=0xff

    This seems to be similar to the problem greyhound716 had in this thread:

    https://www.synthetos.com/topic/problems-flashing-firmware/

    but I’ve tried the exact same fixes and it didn’t help.

    I’ve got the latest AtmelStudio (6.1.2440 beta) and have upgraded the programmer to firmware 1.15.

    I’m following the instructions under “Flashing the Boot Loader onto the Xmega Chip” on this page:

    https://github.com/synthetos/TinyG/wiki/TinyG-Boot-Loader

    Chip target voltage is 3.3V and device signature is 0x1E9744. Here’s the fuse settings:

    JTAGUSERID = 0xFF
    WDWP = 8CLK
    WDP = 8CLK
    DVSDON = [ ]
    BOOTRST = BOOTLDR
    BODPD = DISABLED
    RSTDISBL = [ ]
    SUT = 0MS
    WDLOCK = [ ]
    JTAGEN = [X]
    BODACT = DISABLED
    EESAVE = [ ]
    BODLVL = 1V6

    FUSEBYTE0 = 0xFF (valid)
    FUSEBYTE1 = 0x00 (valid)
    FUSEBYTE2 = 0xBF (valid)
    FUSEBYTE4 = 0xFE (valid)
    FUSEBYTE5 = 0xFF (valid)

    Please let me know if you need anything else or can help with what I’m doing wrong etc.

    Thanks,

    Chris

     

    April 10, 2013 at 9:52 pm #3995
    alden
    Member

    Sigh. We never had these problems with AVRStudio4. Try the code anyway. I have seen this and the code actually programmed correctly, it just didn;t verify correctly. If that doesn’t work try programming it with AVRStudio4. It’s ben removed from the Atmel site but there are still links for it. Gargoyle: Avrstudio4 links

    ALso, you want the bootrst fuse to application unless you have the boot loader installed.

    April 10, 2013 at 10:21 pm #3997
    cmagagna
    Member

    Thanks Alden, I’ll try that out soon.

    In the meantime, with the new programmer I was able to write tinyg.hex directly to the board with avrdude:

    avrdude -c avrispmkii -v -p x192a3 -P usb -U flash:w:tinyg.hex

    and that looks like it’s fixed the problems I had originally (crashing on $$, $x, etc.).

    Chris

    April 22, 2013 at 6:18 pm #4045
    Chris
    Member

    I got my MKII week before last and still have problems, can’t flash a new bootloader nor the tinyg firmware. Either thru ATMEL Studio or the command line.

    Doing some digging and curious what everyone else is seeing for Lock Bits. Can people post their Lock Bits as reported from the Device Programmer in Studio (I’m using version 6).

    For the lockbits the following are set on my board. If I’m reading it right it’s locked from writing or verifying anything.

    BLBB = RLOCK

    Read lock – (E)LPM executing from the application section is not allowed to read from the boot loader section. If the interrupt vectors are placed in the application section, interrupts are disabled while executing from the boot loader section.

    BLBA = WLOCK 

    Write lock – SPM is not allowed to write the application section.

    BLBAT = WLOCK 

    Write lock – SPM is not allowed to write the application table

    LB =  RWLOCK

    Read and write lock – programming and read/verification of the flash and EEPROM are disabled for the programming interface. The lock bits and fuses are locked for read and write from the programming interface

    • This reply was modified 11 years, 5 months ago by Chris.
    April 23, 2013 at 5:53 am #4047
    alden
    Member

    I don’t know how the lock bits got set and we will look into that. But you can unlock them in either Studio4 or Studio6 in the programming dialog. Look under Lock Bits to see what state they are in. You can reset them by selecting Erase Device in 4 or 6. The lock bits page in the dialog tells you where to look in 4 and 6.

    Alden

    April 23, 2013 at 1:43 pm #4050
    Chris
    Member

    What values should I set them to?

    April 23, 2013 at 2:44 pm #4053
    Chris
    Member

    BTW. those values I posted ARE the values read by Studio 6.

    April 23, 2013 at 11:08 pm #4054
    Chris
    Member

    Spoke to Riley tonite. Looks like it was the Lock Bits being set incorrectly that was stopping anything being written, either thru avrdude and Studio. No idea how they got set because until last week I didnt have a programmer that could tweak them 🙂

    The fix was to erase the chip using my new mkii thru Studio. I check all the fuses were per the wiki instructions and set all the lock bits to NOLOCK (and wrote them.)

    I could then flash anything I wanted to the card, including xboot (although it wouldn’t verify, but seemed to flash ok and I got the boot blink). I tried tinyg.hex directly thru Studio w/o xboot. I verified the card booted correctly in the terminal. I then went back and reflashed xboot (no verify) and then tried an avrdude flash of tinyg.hex thru the USB port and it took first time. Again I verified everything thru the terminal.

    I’m very happy with the level of support from Synthetos. You guys are awesome and go way beyond to help.

    Cheers

    Chris

    April 27, 2013 at 8:57 pm #4066
    Riley
    Keymaster

    As an FYI to future travelers. This is a writeup on how to fix your LOCKBIT’s should anyone else come across this issue.

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

    Ril3y

  • Author
    Posts
Viewing 14 posts - 1 through 14 (of 14 total)
  • The topic ‘Did I blow up my board?’ is closed to new replies.