Updating the firmware

Discussion in 'OpenBeam Kossel Reprap and OpenBeam Kossel Pro' started by Matthew Wilson, Jan 18, 2015.

  1. Steve Heer

    Steve Heer Active Member

    @Tyler Anderson

    Thanks Tyler,

    I will give it a go tonight. I want to play with the bricked board a little prior to attempting the firmware upgrade on the replacement. Don't want 2 bricked units! lol. I don't suppose there is any kind of warranty on these boards, is there?
    Also, the bricked board when powered up with the printers power supply has a steady power light but neither of the buttons (boot or reset) have any effect with respect to seeing something happening with the LED's when trying to depress the buttons. Does this have any bearing on my future attempt to un-brick the board this evening?.... or will I be wasting my time trying? Sorry for all the questions but AVR programming is new to me. Years ago I programmed AVR based smart cards through a card reader/programmer but the process was much different back then, you only needed to insert the card into the programmer and fly at 'er. Never bricked a card back then so this first attempt via Arduino resulting in the bricking has left me hesitant, not to mention $185 later (which will be ok if I can resurrect the original board....I will have a spare!!!!)
  2. Rick Gordon

    Rick Gordon Member

    i had the 69% problem on OS X as well. I think someone mentioned that it has to do with a newer version of avrdude.
    as for the USBtinyISP programmer's - I recall there being some issue with >64KB firmware (its around 91KB currently).
    I picked up an Olimex programmer pretty cheap. Only issue was I had to flash the firmware on the programmer using Windows to use it in avrdude mode. Oh, and it only has 10-pin out for this kind of thing - so I had to build a 10-6 pin jumper board. I do not have the Olimex to deliver power to the board.
    I haven't tried a bus pirate yet - i've heard good things about it though.

    here's a link to the Olimex - to me its easier to understand than the Bus Pirate - I'm not an AVR developer. https://www.olimex.com/Products/AVR/Programmers/AVR-ISP-MK2/open-source-hardware
  3. Steve Heer

    Steve Heer Active Member

    Good News! I resurrected my BWP!!!! I wasn't sure it was working because it was taking way longer than I thought for Bus Pirate to do it's things. I haven't tried anything other than seeing if I could connect to the BWP via MatterControl and MC seen the printer with no problems. Can someone look at these 3 logs of the process and tell me if the time taken to reflash/reprogram the BWP was normal or should this have happened much faster.... here is the log:

    FLASH FUSES LOG:

    D:\WinAVR-20100110\bin>avrdude -c buspirate -P COM10 -p at90usb1286 -U lfuse:w:0
    xFF:m -U hfuse:w:0x9B:m -U efuse:w:0xF0:m

    Detecting BusPirate...
    **
    ** Bus Pirate v3a
    ** Firmware v5.10 (r559) Bootloader v4.4
    ** DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
    ** http://dangerousprototypes.com
    **
    BusPirate: using BINARY mode
    avrdude: AVR device initialized and ready to accept instructions

    Reading | ################################################## | 100% 0.11s

    avrdude: Device signature = 0x1e9782
    avrdude: reading input file "0xFF"
    avrdude: writing lfuse (1 bytes):

    Writing | ################################################## | 100% 0.03s

    avrdude: 1 bytes of lfuse written
    avrdude: verifying lfuse memory against 0xFF:
    avrdude: load data lfuse data from input file 0xFF:
    avrdude: input file 0xFF contains 1 bytes
    avrdude: reading on-chip lfuse data:

    Reading | ################################################## | 100% 0.02s

    avrdude: verifying ...
    avrdude: 1 bytes of lfuse verified
    avrdude: reading input file "0x9B"
    avrdude: writing hfuse (1 bytes):

    Writing | ################################################## | 100% 0.03s

    avrdude: 1 bytes of hfuse written
    avrdude: verifying hfuse memory against 0x9B:
    avrdude: load data hfuse data from input file 0x9B:
    avrdude: input file 0x9B contains 1 bytes
    avrdude: reading on-chip hfuse data:

    Reading | ################################################## | 100% 0.02s

    avrdude: verifying ...
    avrdude: 1 bytes of hfuse verified
    avrdude: reading input file "0xF0"
    avrdude: writing efuse (1 bytes):

    Writing | ################################################## | 100% 0.02s

    avrdude: 1 bytes of efuse written
    avrdude: verifying efuse memory against 0xF0:
    avrdude: load data efuse data from input file 0xF0:
    avrdude: input file 0xF0 contains 1 bytes
    avrdude: reading on-chip efuse data:

    Reading | ################################################## | 100% 0.03s

    avrdude: verifying ...
    avrdude: 1 bytes of efuse verified

    avrdude: safemode: Fuses OK

    avrdude done. Thank you.
    ==========================================================================
    FLASH BOOTLOADER LOG:


    D:\WinAVR-20100110\bin>avrdude -c buspirate -P COM10 -p at90usb1286 -U flash:w:B
    ootloaderCDC-bwpro-1.hex:i

    Detecting BusPirate...
    **
    ** Bus Pirate v3a
    ** Firmware v5.10 (r559) Bootloader v4.4
    ** DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
    ** http://dangerousprototypes.com
    **
    BusPirate: using BINARY mode
    avrdude: AVR device initialized and ready to accept instructions

    Reading | ################################################## | 100% 0.11s

    avrdude: Device signature = 0x1e9782
    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 "BootloaderCDC-bwpro-1.hex"
    avrdude: writing flash (130864 bytes):

    Writing | ################################################## | 100% 4192.29s

    avrdude: 130864 bytes of flash written
    avrdude: verifying flash memory against BootloaderCDC-bwpro-1.hex:
    avrdude: load data flash data from input file BootloaderCDC-bwpro-1.hex:
    avrdude: input file BootloaderCDC-bwpro-1.hex contains 130864 bytes
    avrdude: reading on-chip flash data:

    Reading | ################################################## | 100% 4175.88s

    avrdude: verifying ...
    avrdude: 130864 bytes of flash verified

    avrdude: safemode: Fuses OK

    avrdude done. Thank you.
    ==========================================================================

    FLASH FIRMWARE LOG:


    D:\WinAVR-20100110\bin>avrdude -c buspirate -D -P COM10 -p at90usb1286 -U flash:
    w:KosselProMarlin-20150117.hex:i

    Detecting BusPirate...
    **
    ** Bus Pirate v3a
    ** Firmware v5.10 (r559) Bootloader v4.4
    ** DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
    ** http://dangerousprototypes.com
    **
    BusPirate: using BINARY mode
    avrdude: AVR device initialized and ready to accept instructions

    Reading | ################################################## | 100% 0.11s

    avrdude: Device signature = 0x1e9782
    avrdude: reading input file "KosselProMarlin-20150117.hex"
    avrdude: writing flash (88126 bytes):

    Writing | ################################################## | 100% 2823.17s

    avrdude: 88126 bytes of flash written
    avrdude: verifying flash memory against KosselProMarlin-20150117.hex:
    avrdude: load data flash data from input file KosselProMarlin-20150117.hex:
    avrdude: input file KosselProMarlin-20150117.hex contains 88126 bytes
    avrdude: reading on-chip flash data:

    Reading | ################################################## | 100% 2812.16s

    avrdude: verifying ...
    avrdude: 88126 bytes of flash verified

    avrdude: safemode: Fuses OK

    avrdude done. Thank you.
    Last edited: Sep 18, 2015
  4. Tyler Anderson

    Tyler Anderson Moderator Staff Member

    That all seems normal. Not sure if you can select a higher baud rate somehow. I usually just start it and go get a snack.
  5. Steve Heer

    Steve Heer Active Member

    I did try twice... the first time I thought it was hung since it took 3/4 of a minute to get past 0% so I aborted and bumped my baud rate from 9600 to 115200 and started again. It made no difference in programming speed. Both baud rates took just over 42 seconds to jump 1% completion.

    I have to say that the Bus Pirate is a pretty nifty piece of hardware! It works well and the live reporting of what's happening helps a lot in seeing the big picture when one is not familiar with the process to begin with.

    For any of you who are interested, the procedure used was exactly like Tyler has posted with the exception that I totally removed the BWP from the printer and connected the Bus Pirates +5 signal (BWP-pin 8) to the Vcc signal on the ISP BWP connector (pin 2). It was a little confusing reading the BP connection instructions as to what should connect to the ISP reset (ISP-pin 5) because it states that the aux1 pin can be used as reset but thinking about it a little further it made more sense to use the BWP's CS signal (BWP-pin 2) connect to the IPS's reset pin (ISP-pin 5). the rest of the pins were straight forward as to their connections.

    Note: I can not guarantee this will work for everyone as I have a motherboard that allows me to bump up the current going to the USB ports to provide charging capabilities. I say this because with this feature enabled, I can do things that I couldn't on my other computers USB ports which did not support the charging function. Since I don't know all the specs of the BWP, I'm not sure if the 100ma a standard USB port provides would yield the same results. If you want to play it safe then stick 100% to Tylers instructions of using the printers power supply and not connecting the +5 signal of the Bus Pirate to the Vcc signal of the ISP header.

    Thanks to @Tyler Anderson for guiding me through the process to resurrect my board and answering my questions. Now I have a spare BWP so life is good again! :) Now to get down to some calibrating and fine tuning so I can get my first prints started.
  6. Steve Heer

    Steve Heer Active Member

    I just ran into a an issue trying to flash PJR's firmware via bus pirate. I replaced the stock "KosselProMarlin-20150117.hex" with the compiled PJR version which I named "PJR-Marlin-Firmware.hex" to look like this:
    D:\WinAVR-20100110\bin>avrdude -c buspirate -D -P COM10 -p at90usb1286 -U flash:
    w:pJR-Marlin-Firmware.hex:i

    Here is the log of the verify failure:

    D:\WinAVR-20100110\bin>avrdude -c buspirate -D -P COM10 -p at90usb1286 -U flash:
    w:pJR-Marlin-Firmware.hex:i

    Detecting BusPirate...
    **
    ** Bus Pirate v3a
    ** Firmware v5.10 (r559) Bootloader v4.4
    ** DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
    ** http://dangerousprototypes.com
    **
    BusPirate: using BINARY mode
    avrdude: AVR device initialized and ready to accept instructions

    Reading | ################################################## | 100% 0.09s

    avrdude: Device signature = 0x1e9782
    avrdude: reading input file "PJR-Marlin-Firmware.hex"
    avrdude: writing flash (114548 bytes):

    Writing | ################################################## | 100% 3674.73s

    avrdude: 114548 bytes of flash written
    avrdude: verifying flash memory against PJR-Marlin-Firmware.hex:
    avrdude: load data flash data from input file PJR-Marlin-Firmware.hex:
    avrdude: input file PJR-Marlin-Firmware.hex contains 114548 bytes
    avrdude: reading on-chip flash data:

    Reading | ################################################## | 100% 3660.36s

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

    avrdude: safemode: lfuse changed! Was ff, and is now 28
    Would you like this fuse to be changed back? [y/n] y
    =================
    I hit Y to change the lfuse back to ff and now it just sits there with no more display. BusPirate led's still look like it's busy doing something but there is no output to the screen so I am not sure if answering Y is causing this or not. The original unbrick line showed the lfuse as ff in Tylers instructions so was I wrong in saying to change the lfuse back to ff? Looks like I may have to start from scratch again. Anyone have any idea's as to why the first byte at 0x0000 has the mismatch?
  7. Steve Heer

    Steve Heer Active Member

    not sure why pasting the dos prompt screen capture of text is inserting that smily face and it remains even after editing the post to correct it. it should show w:pJR instead of the w'smilyface'JR
  8. Steve Heer

    Steve Heer Active Member

    what the heck? it still replaces it when I type it in.... what gives. Does the site see the combination of characters as a smileyface code? here it is with space between chars.:
    w : PJR
  9. Steve Heer

    Steve Heer Active Member

    Well I finally got the BWP programmed with the PJR firmware but now have some really weird things happening. I ran G28 to home the head then G29 and it started ok. It deployed the probe and did the first row of probing then did what looked like a home command but did it very erratically then dropped down and did another row then homed again but this time I killed the power because the erratic homing was twice as bad.... it was trying to force it past the home position and causing the belt to jump teeth on the steppers. The whole unit was shaking!!! I was under the impression that the PJR firmware fixed all the leveling issues the stock firmware had but this is behaving way worse. I will double check that I didn't mix up any of the BWP connections to steppers and endstops but pretty sure that is not the issue. May be an EMI issue as I never tied down all the connecting wires to the base like in the instructions.

    BTW... I started from scratch to re-program the BWP. Used Bus Pirate to flash the fuses then flash the boot loader. Put the board back into the printer and removed the +5 pin from the Bus Pirate so I could draw power from the printer. When I powered up the printer it was already in boot/reset mode waiting for the firmware to be loaded and it showed up in device manager as "Brainwave Pro Boot loader". I had not seen that before but decided to continue on. Loaded the PJR Marlin firmware into Arduino and did a test compile to make sure there were no errors, (lots of warnings with logging turned up) but it compiled without error. Uploaded the sketch to the BWP and had success. Loaded Matter Control and tried the calibration with the results stated above. Taking a break for dinner then back at'er! I shall not be defeated! :)
  10. Steve Heer

    Steve Heer Active Member

    Erratic movements were caused by the probe pin not hitting the probe switch correctly. Found the pin wasn't quit tight enough. That issue is solved but I'm not sure why but the stock firmware had no problem deploying or retracting the probe other than the retraction process was moving away from the bed clamp and slamming into the glass but the PJR firmware now doesn't retract. What is weird is if I manually place the probe over the bed clamp and manually lower it enough for the pin to clear the grove and be forced over to lock it in the retracted position, the pin actually hits the carbon rod thus not allowing it to spring into the retracted locked position. It cleared it with the stock firmware. My bed clamp bracket is centered along the beam rail between the X and Y towers in the same place I originally set it to. I have not loosened off that bracket since the build. I tried swapping out the longer pin for the shorter pin but deployment won't work with the shorter pin. Kinda stumped as to why it no longer retracts. I have noticed that a lot of users here have their Z offset's way smaller than mine is. I pass the paper test after setting my Z offset to 9.8 which is significantly larger than what I read most users settings are at. I used G28 to home, G30 to autolevel and let it do its thing. Then I do a G1 Z0 to lower the head to the bed and it appears perfect for the paper test at this point but the retraction pin hits the carbon rod as in the picture below...
    here is the log of the G30 command before applying the Z offset:

    ->G28
    <-ok
    ->M114
    <-X:0.00 Y:0.00 Z:280.67 E:0.00 Count X: 539.10 Y:539.10 Z:539.10
    <-ok
    ->G30
    <-| Z-Tower Endstop Offsets
    <-| -1.0750 X:0.00 Y:0.00 Z:0.00
    <-| -1.7625 -0.8500 Tower Offsets
    <-| -1.5500 A:0.00 b:0.00 C:0.00
    <-| -1.7813 -0.8313 I:0.00 J:0.00 K:0.00
    <-| -1.5125 Delta Radius: 152.3570
    <-| X-Tower Y-Tower Diagonal Rod: 300.0000
    <-
    <-ok

    And after applying the Z offset:

    ->G28
    <-ok
    ->M114
    <-X:0.00 Y:0.00 Z:280.67 E:0.00 Count X: 539.10 Y:539.10 Z:539.10
    <-ok
    ->G30
    <-| Z-Tower Endstop Offsets
    <-| -1.1000 X:0.00 Y:0.00 Z:0.00
    <-| -1.7750 -0.8313 Tower Offsets
    <-| -1.5563 A:0.00 b:0.00 C:0.00
    <-| -1.7875 -0.8125 I:0.00 J:0.00 K:0.00
    <-| -1.4938 Delta Radius: 152.3570
    <-| X-Tower Y-Tower Diagonal Rod: 300.0000
    <-
    <-ok
    Anyone with suggestions?

    Attached Files:

  11. Shen

    Shen New Member

    I bricked my board. I found the unbricking guide at http://ztautomations.dozuki.com/Wiki/Firmware but since I don't have any avr or arduino experience. The guide hard for me to follow. Can someone show me with a photo which pin should I use? Also do I need to get a Bus Pirate? Would a Arduino Uno work?(since I can pick it up in a local store.) Thanks.
  12. Steve Heer

    Steve Heer Active Member

  13. Shen

    Shen New Member

  14. Corey Morreale

    Corey Morreale New Member

    I am able to update firmware (using PJR and FSRs) via AVRDUDE but anytime I try to do it via the hard way the board resets (stops the red slow flashing led) before it begins to upload while compiling sketch. is there some setting that needs to be configured?

    I upload firmware all the time on my MendelMax 3 with a Rambo running Marlin using Arduino.

    Also can someone post a link to the most recent version of the software that we should be running?
  15. Steve Heer

    Steve Heer Active Member

    @Corey Morreale I would check your COM port after hitting the reset on the BWP.... It seems to take on a new port so prior to sending the firmware via arduino IDE. I would check to see if this is the case then set the IDE to use the same active port. As for latest firmware, I have been using PJR's developmental branch as it has the G30 auto calibration routine whereas the official firmware does not.
  16. Corey Morreale

    Corey Morreale New Member

    it does take on a new port once reset and that is the port i use. it is just that while Arduino IDE is "compiling sketch" the led is slowly flashing red but before it starts "uploading" it stops flashing and the board turns back into normal mode. it is like there is a time limit on how long it can be in program mode (or whatever it is called) tempted to install a rambo or smoothieboard
  17. Steve Heer

    Steve Heer Active Member

    If I remember correctly, I experienced the same thing and found that you have to be quick to switch IDE port assignment and compile after resetting the BWP. I'm pretty sure there is a timeout. I keep my device manager window open so I have quick access to the port it opens to determine the port number and can usually catch everything in time.
  18. AndyG

    AndyG Member

    I had the same issue and there is definitely a timer. I was compiling on a really old netbook and was barely able to get it on there in time before the timer ran out.
  19. Corey Morreale

    Corey Morreale New Member

    who knows what my issue is. I have a very fast laptop and it doesnt finish the compiling before the timeout ends. I have no issues compiling and then doing the "easy way"

    don't have the issues updating marlin on my rambo board/mendel max 3
  20. psxblade15

    psxblade15 New Member

    Can anyone confirm what the latest firmware version is? Right now M115 is reporting:
    Seattle Automationz ZT-KIT-00255 (Firmware: 0.80) on my printer, and I'd like to know if I should be updating it or not...

Share This Page