Page MenuHomeAleph Objects Inc

Add support for flashing FW to Ultimachine Archim board for Quiver
Open, HighPublic

Description

The Archim board is a 32-bit board based on the Arduino Due. This board uses a different flashing program. In order for the Archim board to be used on Quiver, Cura 2 will need to be able to flash it.

Edit: we should always use development names for in development products because final release names are likely to change before final release.

Related Objects

Mentioned In
T9151: Smoke test 3.6.17
T9202: Smoke test 3.6.18
T9139: Smoke test 3.6.16
rCT60efc39bb812: T1250: Avoid crashing when USB serial device disappears (unplugged cable for…
T8894: Smoke test 3.6.15
rCT885ee2f8df1d: T1250: Return from serial port init function if we can't open serial device.
T8192: Smoke test 3.6.11
T7761: Smoke test 3.6.10
Dev-release
T7040: Smoke Test 3.6.8
rCTd7c46e8fa305: T1250: Add .bin format to file format filter while flashing from ChangeToolHead…
T6670: Windows 7 Connection
T6646: Smoke Test 3.6.6
rMARLINbc1d49b6d4ba: Restored default behavior for MIN/MAX temp (T1250)
rCTb786e76f5f83: T1250: Added list of serial port USB VIDs that will be autodetected by USB…
rCT9967783e2a3b: T1250: For port autodetection, we should use pyserial tools instead of…
rCT728b9cee4f80: T1250: Commenting out some too verbose log messages.
rCT3a436e41d263: Merge branch 'master' into T1250
rCT41df34e6959c: T1250: The minimum set of code that flashes Archim board is now working.
rCT3544cf4451df: T1250: Added WordCopy applet and added mor functions to Samba and EEFC Flash.
rCT0e0654623ab7: T1250: Added classes for SAM-BA and EEFC flash.
rCT5c9d6fbce089: T1250: Added some chips to the chip DB.
T5513: publicly accessible Quiver FW flashing
rCTdb82a04325ea: Merge branch 'master' into T1250
T5471: Layer view showing improper moves and layers
T4931: Alpha User Testing Feedback
rCTd1710d63a3f8: T1250: Added more functionality to bossapy. It enters bootloader and reads…
rCT931794d117b6: T1250: Added initial (dummy) version of bossa programmer.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
marcio added a comment.Feb 5 2018, 9:15 AM

@martinbogo: Well, the only firmware I've used with it is a hacked up version of Marlin 2.0 from Ultimachine. There is no current stable FW for the Archim board because Marlin 2.0 hasn't been released yet, so I haven't really put much work into it. I've attached a ZIP file with the code I had used to compile FW several months ago, it's really old, but it is what we are using on our internal testing.

marcio added a comment.EditedFeb 5 2018, 9:42 AM

@martinbogo: The above FW requires TMC2130 drivers. If you are using a retail Archim 1.0, you will need to modify the FW to turn off support for the Trinamic drivers. We haven't tested it in that configuration however. Our only development board is using TMC2130 drivers and this is what the Quiver will likely have.

karrad lowered the priority of this task from Normal to Low.Feb 21 2018, 2:11 PM
karrad moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Apr 4 2018, 10:42 AM
karrad added a subscriber: karrad.

This will be required for next release, moving to backlog for now

karrad moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 12 2018, 10:53 AM

Attached are the ".elf" and".bin" file I obtain when I compile the Archim 2.0 FW using the Arduino 1.8.3 IDE. Johnny told me this can be flashed to the Archim using the following command line:

~/.arduino15/packages/arduino/tools/bossac/1.7.0/bossac -i -U true -e -w -b -R /
tmp/arduino_build_*/Marlin.ino.bin

I also found out you can generate a ".hex" file by running the following command line:

avr-objcopy -O ihex -R .eeprom Marlin.ino.elf Marlin.ino.hex

But Cura gives the error "Firmware update failed due to a communication error" when trying to upload that ".hex" file to the Archim 2.0.

Elf:


Bin:
Hex:
Source:

The Arduino IDE uses Bossac as well, using the following command line:

/home/aleph/.arduino15/packages/arduino/tools/bossac/1.7.0/bossac -i -d --port=ttyACM0 -U true -e -w -v -b /tmp/arduino_build_576153/Marlin.ino.bin -R

Here is the project page for Bossac:

https://github.com/shumatech/BOSSA

The Archim 2.0 has a atsam3x8e

I have now updated the Makefile for Marlin 2.0 such that I can generate .hex files for Quiver. Still no way to install them, however.

alexei raised the priority of this task from Low to High.Sep 11 2018, 11:11 PM
marcio added a subscriber: alexei.Sep 12 2018, 7:52 AM

@alexei: In order to properly compile, the "arm-none-eabi-*" tools will need to be present in the PATH. This is not the case for our standard LulzBot Debian build. The tool chain I am now using stored on my machine here:

/home/aleph/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/*

It appears to be part of the Arduino IDE.

It is now possible to update Quiver FW from the command line using a ".bin" file generated from the Makefile. The shell script and executable to do the FW install is here:

/home/aleph/shared-j/Documents/R&D/marlin/marlin-quiver-firmware

It looks like bossac does not support .hex files, but if Cura is made to support them we could use .hex instead of .bin for consistency with the other printers.

@marcio,
I'm following this https://reprap.org/wiki/Archim_v1.0 for flashing

Hold the erase button and press the reset button. The board will now boot into the Bossa bootloader.

From bossa bootloader I can then flash with

bin/bossac -i -d --port=ttyACM0 -U true -e -w -v -b -R Marlin_Quiver_TAZ7_Quiver_DualExtruder_bugfix-2.0.x.1_5727a786a.bin

After this new USB device comes up for a while:

Oct 15 14:17:02 kernel: usb 1-5: new full-speed USB device number 14 using xhci_hcd
Oct 15 14:17:02 kernel: usb 1-5: not running at top speed; connect to a high speed hub
Oct 15 14:17:02 kernel: usb 1-5: New USB device found, idVendor=03eb, idProduct=2424
Oct 15 14:17:02 kernel: usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 15 14:17:02 kernel: usb 1-5: Product: LulzBot Quiver
Oct 15 14:17:02 kernel: usb 1-5: Manufacturer: marlinfw.org
Oct 15 14:17:02 kernel: usb 1-5: SerialNumber: 123985739853
Oct 15 14:17:02 kernel: cdc_acm 1-5:1.0: ttyACM0: USB ACM device

But then something is happening and it falls back to Archim:

Oct 15 14:17:36 kernel: usb 1-5: reset full-speed USB device number 14 using xhci_hcd
Oct 15 14:17:36 kernel: usb 1-5: device firmware changed
Oct 15 14:17:36 kernel: cdc_acm 1-5:1.0: ttyACM0: USB ACM device
Oct 15 14:17:36 kernel: usb 1-5: USB disconnect, device number 14
Oct 15 14:17:36 kernel: usb 1-5: new full-speed USB device number 15 using xhci_hcd
Oct 15 14:17:37 kernel: usb 1-5: New USB device found, idVendor=27b1, idProduct=0001
Oct 15 14:17:37 kernel: usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 15 14:17:37 kernel: usb 1-5: Product: Archim
Oct 15 14:17:37 kernel: usb 1-5: Manufacturer: UltiMachine
Oct 15 14:17:37 kernel: cdc_acm 1-5:1.0: ttyACM0: USB ACM device

After which I can't communicate with the board. Probably this is happening because I have nothing, except for power (logic middle PS) and USB connected?
What am I doing wrong?

@alexei: It's possible it's just failing because of lack of thermistors. This will cause Marlin to halt. It appears to me that you may have flashed successfully, you just don't really have a good way to see it since you just have a board. I can compile some FW for you without MIN_TEMP errors.

@marcio ,
Yes, Marlin build that just works without anything connected to the board except for power and USB would be extremely helpful.
Because with current FW it's impossible to flash from CuraLE, since it can't even connect via ttyACM0.

@alexei: Try this one. I set the MIN_TEMP to 0C, so hopefully it won't trigger

@marcio ,
Yes, this worked!
I needed to push reset button, but after doing so I was able to M115:

> [14:53:26] M115
< [14:53:26] FIRMWARE_NAME:Marlin FIRMWARE_VERSION:bugfix-2.0.x.1.1
EXTRUDER_TYPE:AerostruderDual
SOURCE_CODE_URL:https://code.alephobjects.com/diffusion/MARLIN
PROTOCOL_VERSION:1.0 MACHINE_TYPE:LulzBot Quiver EXTRUDER_COUNT:2
UUID:a952577d-8722-483a-999d-acdc9e772b7b
< [14:53:26] Cap:SERIAL_XON_XOFF:0
< [14:53:26] Cap:EEPROM:1
< [14:53:26] Cap:VOLUMETRIC:0
< [14:53:26] Cap:AUTOREPORT_TEMP:1
< [14:53:26] Cap:PROGRESS:0
< [14:53:26] Cap:PRINT_JOB:1
< [14:53:26] Cap:AUTOLEVEL:1
< [14:53:26] Cap:Z_PROBE:1
< [14:53:26] Cap:LEVELING_DATA:1
< [14:53:26] Cap:BUILD_PERCENT:0
< [14:53:26] Cap:SOFTWARE_POWER:0
< [14:53:26] Cap:TOGGLE_LIGHTS:0
< [14:53:26] Cap:CASE_LIGHT_BRIGHTNESS:0
< [14:53:26] Cap:EMERGENCY_PARSER:1
< [14:53:26] Cap:AUTOREPORT_SD_STATUS:0
< [14:53:26] Cap:THERMAL_PROTECTION:1
< [14:53:26] Cap:PAREN_COMMENTS:0
< [14:53:26] Cap:MOTION_MODES:0

I have another question though: Is it possible to reload into bossa bootloader without pushing any buttons on the board?

@marcio , Just tested it with bossac from master branch and -a switch doesn't work on Archim board :(

I have another question though: Is it possible to reload into bossa bootloader without pushing any buttons on the board?

In general, if the FW is not running (i.e. crashed), you must hit the erase button. I have not found a way around this. On TAZ 7, we added a recessed button to allow the user to erase the board, as this seems necessary on the Due style board.

@alexei: And after the flash, you must power cycle the printer (since you can't push the reset button)

alexei added a comment.EditedOct 15 2018, 2:43 PM

@marcio,

This is what works for me and not requiring the reset afterwards:

stty -F /dev/ttyACM0 1200; sleep 2; bin/bossac -i --port=ttyACM0 -U true -u -e -w -v -b -R Marlin_Quiver_TAZ7_Quiver_DualExtruder_bugfix-2.0.x.1_00fd7439b.bin

bossac is built from arduino branch (master doesn't work for me) https://github.com/shumatech/BOSSA/tree/arduino

A bit of explanation about magic 1200 baudrate: https://playground.arduino.cc/Bootloader/DueBootloaderExplained

@marcio , Output of the above command, just for reference here.

Atmel SMART device 0x285e0a60 found
Device       : ATSAM3X8
Chip ID      : 285e0a60
Version      : v1.1 Dec 15 2010 19:25:04
Address      : 524288
Pages        : 2048
Page Size    : 256 bytes
Total Size   : 512KB
Planes       : 2
Lock Regions : 32
Locked       : 12
Security     : false
Boot Flash   : false
Unlock all regions
Erase flash
done in 0.012 seconds

Write 287108 bytes to flash (1122 pages)
[==============================] 100% (1122/1122 pages)
done in 7.735 seconds

Verify 287108 bytes of flash
[==============================] 100% (1122/1122 pages)
Verify successful
done in 5.715 seconds
Set boot flash true
CPU reset.
alexei claimed this task.Oct 16 2018, 9:28 AM
logan added a subscriber: logan.Feb 1 2019, 3:27 PM
marcio added a comment.Feb 5 2019, 8:34 AM

@karrad: The to the bossac build is this. There are releases for Linux, Windows and Mac. Once you install that, you can load the ".bin" file from the command line using the following command:

bossac -i -U true -e -w -b -R <firmware_file>.bin

@logan: You had asked about something that could be put in OHAI that would not require "shared-j" access. This should work. The script we have been using internally only needs "shared-j" for the menu interface, the flashing itself happens with bossac.

logan added a comment.Feb 5 2019, 8:35 AM

@marcio Ah, when i tried flashing with the script pushed to the repo it wasn't working, it said "bossac: no such file or directory" or something similar

marcio added a comment.Feb 5 2019, 3:20 PM

@logan: If it is not in your path, you need to do ./bossac -i -U true -e -w -b -R <firmware_file>.bin

Firmware flashing for Archim works now, there are still some pieces missing like progress indicator and flash verification, but I think it can be merged to master at present state.

marcio added a comment.Feb 7 2019, 1:48 PM

_detectSerialPort shoud accept both port.vid == 0x03EB and port.vid == 0x271B. Here are the possibilities:

  • Mini Rambo: 271B:0001
  • Rambo: 271B:0001
  • Archim in "erase" mode: 03eb:6124
  • Archim running with default Marlin: 03eb:2424
  • Archim running with FW > .86: 271B:0001

So checking for either 0x03EB and 0x271B should be sufficient.

alexei added a comment.Feb 7 2019, 4:32 PM

Merged to master. Leaving this ticket open, because there is still some work to do.

Attempted to flash firmware to Quiver 7 with 3.6.5 but am getting errors. Attaching a .txt of the error that is getting thrown.

This is the error thrown after hitting reset button and attempting flash

Following these steps @logan and I were able to get a successful flash through 3.6.5:

1.press and hold reset button
2.turn off printer
3.release reset button
4.turn on printer
5.flash by selecting custom firmware .86

@EricNugent , @logan ,

You shouldn't push any buttons and turning printer on and off.
I also suspect that by "reset" button you really mean "erase" button?

I attempted to flash with the same steps listed above except replacing step 5 with "automatically upgrade firmware"
This resulted in 2 fails, unknown connection error reported both times.
I then attempted to flash by specifying custom FW similar to above, but after selecting the appropriate FW file, CuraLE immediately closed (crashed).

logan added a comment.Feb 11 2019, 1:01 PM

@alexei well if we didn't, it didn't work, so....

@logan, "automatically upgrade firmware" is not supposed to work, because there is no Quiver FW files in CuraLE yet.

@logan, If you have serial ports and baudrate set to AUTO, please set them to a specyfic values too (/dev/ttyACM0 and 250000) there are known issues with AUTO options ATM.

logan added a comment.Feb 11 2019, 1:17 PM

@alexei good to know about auto FW flashing, thank you for relaying that information. If we're testing something, that is good information to relay ahead of time.
Also good to know that now we shouldn't press the erase button vs before when it was required, we were not informed of this.

I set port to ACM0 after starting a new instance of CuraLE 3.6.5, baud rate was 250k
The only issue I am seeing right now is due to things still in development listed above I think; progress indicators etc.
One attempt at flashing, the flash was successful but never reported as finished by CuraLE, just acted like it was still trying
The next attempt quickly reported finished

@logan , good that now you can flash, yes, progress indicator is still WIP and currently it doesn't work.

adam added a subscriber: adam.EditedFeb 13 2019, 10:32 AM

3rd time was the charm for me. The first two instances of cura I tried froze up in the file manager trying to track down the custom firmware location. Once cura stopped freezing it flashed .86 fine. There was some odd LCD grey-out and then flicker for a minute after flashing, but it's stable and correct now.
edit: I did not hit the erase button nor did I power down the machine before/after flashing. I treated this the exact same way I would flash custom firmware to a Mini 2

adam added a comment.Apr 10 2019, 12:05 PM

trying to flash with the accessory tool heads I couldn't get Cura to connect even after setting port and baudrate and restarting cura several times in between. I also cleared cache after a fresh build today. I went ahead and used the reset button and the ./install workaround to flash firmware so I can test wiping and probing on all the accessory tool heads. We definitely want to make sure this works when people try to put a HS, SL, or HS+ on here.

adam added a comment.Apr 10 2019, 12:42 PM

update: when going from single tool head to single tool head, it worked fine. Perhaps this is some variety of failure caused by the mintemp error when you go from two thermistors to one?

alexei moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Apr 11 2019, 7:50 AM

@marcio , could you check that flashing FW for double extruder doesn't trigger thermal runout error.
@adam Could you attach corresponding Cura logs here, please?

@alexei: If Marlin does not find the appropriate thermistor, it will halt the machine. At this point, no further flashing is possible without pushing the erase button. This is because the USB functionality on the Archim is handled by software and relies on the machine being in an operational state.

My guess is that if the single extruder FW is flashed before the dual toolhead is removed and replaced (with the machine off), then it will succeed. When going from a single to a dual toolhead, it will be necessary to first change the toolhead to the dual while the machine is powered off. followed by flashing the dual FW.

For what it is worth, I noticed long ago that Marlin 2.0 will not trigger a min/max temp when the heaters were off, so in upstream Marlin 2.0 this issue would not manifest itself. I modified Marlin to immediately trigger a min/maxtemp error for consistency with our prior FW. One possibility might be to remove this workaround, but users will need to be re-educated not to expect a mintemp when disconnecting their toolheads.

adam added a subscriber: TyTh.Apr 11 2019, 8:28 AM

@TyTh see above for likely tech support question.

@marcio I like that solution, and while different than previous firmware i think it will be much better than requiring different tool head changing techniques. Can you get a local build up for testing on this?

@karrad: I pushed .110 with our extra check for MIN_TEMP and MAX_TEMP removed.

adam added a comment.Apr 11 2019, 12:20 PM

.110 allows me to flash dual firmware with a single on it without erroring out instantly and allows me to flash back to single firmware through Cura. Also verified that pre-heating E2 with a single extruder hooked up will produce the mintemp error.

I guess now we know why Marlin changed the behavior of MIN_TEMP/MAX_TEMP... it's a feature!

I am getting a report from a Windows 7 user that is attempting to connect on Port 7, however no port 7 is available in port selection drop down:

Fresh uninstall and clear cache, @alexei Any thoughts or something else I can attempt to grab?

Yahuba added a subscriber: Yahuba.May 2 2019, 8:36 AM

Still finding this issue in Windows 7 when testing 3.6.7. Fresh install of CuraLE (cleared cache). Windows 7 recognizes Taz Pro printer in device manager but driver is not installed.

logan added a comment.May 3 2019, 11:49 AM

Flashed 2.0.0.114 to a TAZ Pro and CuraLE crashed upon completion
Local build of 3.6.8 updated per wiki instructions, running on Hillstar
Had just added the machine and went to update FW
Last in terminal at crash:

2019-05-03 11:42:33,060 - CRITICAL - [(139850596830848)-MainThread] cura.CrashHandler.init [61]: An uncaught error has occurred!
2019-05-03 11:42:33,063 - CRITICAL - [(139850596830848)-MainThread] cura.CrashHandler.init [64]: Traceback (most recent call last):
2019-05-03 11:42:33,065 - CRITICAL - [(139850596830848)-MainThread] cura.CrashHandler.init [64]: File "/home/aleph/Projects/cura/build-master/build/dist/plugins/plugins/USBPrinting/USBPrinterOutputDeviceManager.py", line 57, in progress
2019-05-03 11:42:33,067 - CRITICAL - [(139850596830848)-MainThread] cura.CrashHandler.init [64]: return progress / len(self._usb_output_devices)
2019-05-03 11:42:33,070 - CRITICAL - [(139850596830848)-MainThread] cura.CrashHandler.init [64]: ZeroDivisionError: division by zero


logan added a comment.May 3 2019, 12:40 PM

Same thing just happened when flashing 2.0.0.112, FWIW

logan added a comment.May 8 2019, 10:45 AM

This is now happening in pilot where they are flashing for production, CuraLE crashes upon each completion

While smoke testing 3.6.11 on Mac OS X (Mojave) connected to a Taz Pro - Was prompted to flash FW as soon as CuraLE connected to Printer. Flashing FW caused LCD to flash the screen and eventually ended up with a rainbow type color bar on the screen (see photo). Turned off printer and restarted.. the LCD screen stayed black.
Restarted CuraLE, did not connect printer but flashed FW instead (Marlin 2.0.0.135) and that brought LCD back to life.