Home › Forums › TinyG › TinyG Support › Help! Firmware flash problem – motor lights on hard
Tagged: firmware problem
- This topic has 4 replies, 2 voices, and was last updated 11 years, 2 months ago by alden.
-
AuthorPosts
-
September 18, 2013 at 9:00 pm #4535corb555Member
My v8 tinyG was working great but I tried for my first time to flash to latest firmware. Now when I power it up, the red light blinks for 15 seconds, then Motor1, 2, and 3 lights all come on and stay on (motor4 is off). I used firmware from github zip file: “Tinyg-master/firmware/tinyg/default/tinyg.hex”, (filesize below).
I used the following for flashing (ran a second time, same result):
avrdude -p x192a3 -c avr109 -b 115200 -P /dev/tty.usbserial-DA00865W -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: 0x7bavrdude: 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 (102740 bytes):Writing | ################################################## | 100% 12.86s
avrdude: 102740 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 102740 bytes
avrdude: reading on-chip flash data:Reading | ################################################## | 100% 12.28s
avrdude: verifying …
avrdude: 102740 bytes of flash verifiedavrdude done. Thank you.
September 18, 2013 at 9:36 pm #4536aldenMemberIt sounds like you got the code flashed. That’s the right sequence.
What version of the FW are you flashing?
Do you have problems driving it once it’s flashed? What are you using to drive it?
September 18, 2013 at 10:07 pm #4538corb555MemberI flashed 0.96 B 380.05. It seems like the board may be working fine but the motor lights now come on even though the motors are not on. The board responds to status request and I can enable and disable the motors, but the three green motor LEDs always stay on. I’m a bit relieved – I thought I had bricked the board but it seems OK except the for the motor lights.
I am using CoolTerm on Mac to drive it.
- This reply was modified 11 years, 2 months ago by corb555.
September 18, 2013 at 10:28 pm #4542corb555MemberI think I know what happened. When I flashed it resets all the config states on the board. Previously I had power management on, after flash it reset m1,m2, and m3 power mgt to off, so the power lights go on. Much relieved!
September 19, 2013 at 7:17 am #4543aldenMemberGood. The motor power sequencing is a tough one to get right as user requests are somewhat in conflict. There has been a longstanding request for motor power management to power on the motors as soon as the motor power management settings are taken, and not wait until the next move. Having implemented this in 380.05 it means that the motor power will come on at bootup, if you have set $1pm=1 (or 2, or 3, or 4). Then it turns off after the timeout interval ($mt)
I realize this is a change in behavior.
-
AuthorPosts
- You must be logged in to reply to this topic.