cmagagna

Thanks for the JSON tip. I’ll check it out.

I’ll also open incidents at github from now on.

Thanks again.

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

Hi everybody,

I just got my board back from Synthetos, now with the bootloader and version 370.08 of the code.

I haven’t had a chance to hook it up to my ShapeOko yet, but I can verify both the limit switch bug and the saving parameters in inches bug are now fixed.

A special note of thanks to Synthetos for both the quick bug fixes and the immediate turnaround in upgrading the firmware on my board (they got it Friday; I got it back today). You guys are great!

Chris

Hi Alden,

I’ve verified this bug. The values are being saved, but not the units. Here’s an example where I reboot the TinyG, explicitly forcing inches with G20, verifying the system is in inches via $gun, set the X seek rate to 100 inches / minute, and reboot again. You’ll see the X seek rate goes to 3.937 inches / min, which works out to 100 (3.937 * 25.4).

Similar to what n7qvu says above, I’m just going to switch over to mm so I won’t have to deal with this problem, but I do want to make sure you’re aware of it.

Chris


{"r":{"fb":370.050,"fv":0.950,"hv":7.000,"id":"9H3906-XWP","msg":"Loading configs from EEPROM","f":[1,15,0,38]}}
{"r":{"fb":370.050,"fv":0.950,"hv":7.000,"id":"9H3906-XWP","msg":"SYSTEM READY","f":[1,0,0,960]}}
tinyg [inch] ok>
g20
tinyg [inch] ok>
$
[fb] firmware build 370.05
[fv] firmware version 0.95
[hv] hardware version 7.00
[id] TinyG ID 9H3906-XWP
[ja] junction acceleration 3937 in
[ct] chordal tolerance 0.000 in
[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 0 [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 1 [0=off,1=on]
[ee] enable echo 1 [0=off,1=on]
[ex] enable xon xoff 1 [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 0 [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 [inch] ok>
$x
...
[xvm] x velocity maximum 19.685 in/min
...
tinyg [inch] ok>
$xvm=100
[xvm] velocity maximum 100.000 in/min
tinyg [inch] ok>
$x
...
[xvm] x velocity maximum 100.000 in/min
...
tinyg [inch] ok>
{"r":{"fb":370.050,"fv":0.950,"hv":7.000,"id":"9H3906-XWP","msg":"Loading configs from EEPROM","f":[1,15,0,38]}}
{"r":{"fb":370.050,"fv":0.950,"hv":7.000,"id":"9H3906-XWP","msg":"SYSTEM READY","f":[1,0,0,960]}}
tinyg [inch] ok>
g20
tinyg [inch] ok>
$gun
[gun] default gcode units mode 0 [0=G20,1=G21]
tinyg [inch] ok>
$x
...
[xvm] x velocity maximum 3.937 in/min
...