Did I blow up my board?

[cmagagna]

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

[cmagagna]

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.

[Chris]

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

[Riley]

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.

[cmagagna]

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

 

[cmagagna]

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

 

[alden]

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.

[cmagagna]

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

[Chris]

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, 7 months ago by Chris.

[alden]

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

[Chris]

What values should I set them to?

[Chris]

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

[Chris]

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

[Riley]

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