@dc42 I have a bossa port in Windows Device Manager (Win 10 Pro) and in Ubuntu 20.04 I see Bus 004 Device 002: ID 03eb:6124 Atmel Corp. at91sam SAMBA bootloader when I 'lsusb'.

I am getting a Windows SAM-BA error: "SAM-BA error h_handle returned zero".
I am getting a Windows BOSSA error "Could not connect to device on COM9".

In Linux:
~/BOSSA/bin/bossac -e -w -v -b /home/nvidia/Downloads/Duet3Firmware_MB6HC.bin
No device found on /dev/ttyACM0

Both Windows and Linux machines can see it yet it errors out or refuses to connect. Is this a permissions thing? Is it a configuration issue? Are there jumpers/pins that could be mis-configured?

The documentation is terrible. It is conflicting, confusing, outdated, etc. I have seen others ask about the ribbon cable: The documentation states that a cable over 150mm is a problem yet the board was shipped from the factory with a 200mm cable.

The documentation states to install SAM-BA v. 2.17 yet the photo on the website is of SAM-BA v. 2.16. It also says that you will get connection errors (I am getting connection errors) if you specify the wrong board. Exactly what version of SAM-BA should be installed on a Windows 10 machine and exactly how do I find out or confirm which board/chip I have?

The documentation does not mention a MicroSD card during the erase/re-flash procedure. Should the MicroSD card be installed in the MB6HC board during the erase/re-flash process? What state (file structure, format, etc.) should the MicroSD card be in during the failback#2 procedure?

USB Cable: The documentation states "if it doesn't work, try new/different usb cable" however the board does not ship with a USB cable. What are the required specifications of the USB connection/cable?

I'd appreciate any help trying to flash firmware onto this $250 paperweight. Thanks.

@chrishamm said in Duet 3 MB6HC Questions:

@winstontj Unfortunately the stock bossa program on older DuetPi versions and Debian Buster is quite outdated so it doesn't recognize the MB6HC. You can upgrade it this way:

sudo curl -L "https://github.com/Duet3D/DuetPi/blob/master/stage-dsf/00-system/files/bossac?raw=true
" -o /usr/bin/bossac

After that you can flash the firmware again:

bossac -e -w -v -b /opt/dsf/sd/firmware/Duet3Firmware_MB6HC.bin

That should get you going again provided you don't have the ERASE jumper fitted any more. If you do, remove it first. You may have to reset the board once using the push button when the firmware is upgraded.

Following those exact instructions gives me this:

ubuntu@temp-duet:~/Desktop/Duet$ bossac -e -w -v -b Duet3Firmware_MB6HC.bin 
bash: /usr/bin/bossac: cannot execute binary file: Exec format error

I think that means it could be an application written for ARM (that I tried to run on Intel x86) however when I try to run it on various ARM boards --I tried both on a RbPi3B+ and NVIDIA Xavier AGX (8-core A53), no matter what I tried, I kept getting

nvidia@jetson:~$ sudo ./bossac -e -w -v -b Duet3Firmware_MB6HC.bin 
sudo: ./bossac: command not found

I tried every way I could to add, override, move, copy, etc. to $PATH and kept getting the same error. I put it in /usr/bin, /usr/local/bin, ~/bossac, etc. every time I got the same error above.

@Phaedrux
Below is Windows cmd output. I purposely changed the COM port from COM10 to COM2 because I read somewhere that sometimes applications look for COM ports numbered 1-4 and double-digit COM ports (like com10) don't always play nice with some things. Either way, COM2 is correct port and Windows Device Manager shows:

BOSSA Program Port (COM2)

This is the result:

C:\Users\duet-temp\Desktop\Duet3_6HC>bossac -e -w -v -b Duet3Firmware_MB6HC.bin
No device found on COM2

@Phaedrux I tried several ways with Windows cmd.exe. I tried to add the flag --port=COM2 and --port=\USBserial\COM2. Both did not work. Nothing works. What software do I need?

This is either a documentation issue, a Duet3D software issue or both. Several different machines can see the MB6HC board yet there is an issue, problem or fatal error every single time. Flashing this board should be an easy task yet going back as far as 2017 there have been similar issues:
https://forum.duet3d.com/topic/2715/bossac-command-structure/11

What exactly do I need to get this board going? This has been an extremely frustrating process to the point that I regret buying a Duet3D product. Duet3D please help resolve this. I have many machines with various hardware (Intel x86, ARM, Apple) and various software (windows, various *nix flavors, etc.). What do the developers use? What configuration can I create to avoid as many variables as possible as well as mirror the existing documentation?

Duet3D please bring your documentation up to date. This is extremely frustrating!

@dc42 said in Duet 3 MB6HC Questions:

@winstontj have you tried Bossa.exe from https://github.com/Duet3D/BOSSA/releases under Windows?

All of the following is under Windows 10 Pro, build 19044.1706

BOSSA gives me a choice in the dropdown of COM1, COM3 and COM10. Windows Device Manager shows (under Ports, COM & LPT) "Bossa Program Port (COM10)". When select the BOSSA dropdown "COM10", it errors immediately with a small gui box with white X in red circle: "Error Could not connect to device on COM10".

How do I get BOSSA to connect to device \USBserial\COM10?

The SAM-BA v.2.17 dropdown shows COM1, COM3, COM10 and \USBserial\COM10. In SAM-BA, when I connect to COM10, it errors out immediately. However, when I connect to "\USBserial\COM10" (and select at91sam4e8-ek), I do not get an error (but the window box just goes away... no more GUI).

I don't know what to say. The computers see the board (bossa com port) it's just that none of the software will connect to it.

@chrishamm mentioned something about stock BOSSA being outdated and not recognizing the MB6HC board. Could this be a Windows (and/or Linux) driver issue? I installed the board drivers from here:
link text. Is there a newer, different or more appropriate Windows driver I should be using? (or maybe try??) The board is there... This is the difference between getting BOSSA to connect via \USBserial\COM10 vs. COM10

EDIT: Is there a Windows command line (powershell??) version of BOSSA where I could use flags or tell it to talk to the MB6HC specifically at \USBserial\COM10?

@winstontj EDIT: I think that in Win10Pro SAM-BA 2.17 is connecting to the board. When the initial dialog box opens, if I choose the USB COM10 (not just COM10) I don't get an error message, but the pop-up dialog box just vanishes and goes away. Nothing pops up that would allow me to browse for an upload firmware file. However... If I unplug the MB6HC from the Win10Pro machine, I get a SAM-BA error pop-up as if the device disconnected unexpectedly.

@chrishamm Sorry I walked away for a few days. It looks like @Phaedrux linked you some/the places in the docs.

I have no idea what the problem is or what I'm missing but this stupid board is still a paperweight.

In Diag mode (at least connected to Win 10 Pro) the MicroSD card being installed matters a lot. Right now the red diag led is faint/dimly lit and the erase jumper pins are open. On Win10pro with no microsd card I get "unknown usb device" in the windows device manager (device driver is installed). With the microsd card installed (doesn't seem to matter whether the microsd card is formatted, blank, has data on it, etc. it's just whether or not a microsd card is present in the board) So with the microsd card installed, win10pro sees "Bossa Program Port (COM10)"... But then I get: Error: "Could not connect to device on COM10".

If I right click and run elevated same thing: could not connect to device on COM10.

Not sure if it matters --the physical machine is an old Dell Optiplex 755. It's something I dug out and put a clean windows image on for this firmware issue. I believe it's a USB2.0 port. The Dell machine is old, mfg. date says 01/15/08 so I don't think there should be any compatibility issues. So Win10pro I'm having no luck with SAM-BA or BOSSA. I can see the board in device manager, it's recognised, etc. it just won't connect.

I then tried it on an Ubuntu 20.04 machine and an Ubuntu 18.04 machine. There seemed to be no difference between the two operating systems. The only thing I noticed was that was a little strange was that SAM-BA would only run the 64-bit application. The 32-bit would not open. The 64-bit would open and then as soon as I hit connect, the dialog box would vanish and the program would quit.

With BOSSA on Ubuntu 20.04: The documentation says update & install, etc. and FYI in Ubuntu 20.04, package libwxgtk3.0-dev has changed to libwxgtk3.0-gtk3-dev so you get a "no install candidate" error with libwxgtk3.0-dev. So with BOSSA, the way that you suggested in your post above: (sudo curl -L... etc.) I think something similar to the SAM-BA 32/64-bit thing is happening.

When I ran

bossac -e -w -v -b /home/user/Desktop/Duet3/Duet3Firmware_MB6HC.bin

I got back:

bash: /usr/bin/bossac: cannot execute binary file: Exec format error

When I ran with sudo:

sudo bossac -e -w -v -b /home/user/Desktop/Duet3/Duet3Firmware_MB6HC.bin

I got back:

/usr/bin/bossac: 1: Syntax error: word unexpected (expecting ")")

A brief Google search shows that you often get the syntax word unexpected error when you are trying to run a 32-bit binary/program on a 64-bit OS (or the other way around)... Since I also was getting something weird with SAM-BA where the 32-bit would not open and the 64-bit would open, then closed upon attempted connection (similar to what I was getting in Win10pro, disconnect after cannot connect).

Is this a 32 vs 64 bit issue?

Next I tried a Pi 3B+ with the Duet Pi.zip (I am typing this from the desktop on the DuetPi).

pi@duet3:~ $ bossac -e -w -v -b /home/pi/Desktop/Duet3Firmware_MB6HC.bin 
No device found on /dev/ttyACM0
pi@duet3:~ $ sudo bossac -e -w -v -b /home/pi/Desktop/Duet3Firmware_MB6HC.bin 
No device found on /dev/ttyACM0
pi@duet3:~ $ ls -l /dev/tty*
crw-rw-rw- 1 root tty       5,  0 May 13 20:02 /dev/tty
crw--w---- 1 root tty       4,  0 May 13 20:02 /dev/tty0
crw------- 1 pi   tty       4,  1 May 13 20:02 /dev/tty1
crw--w---- 1 root tty       4, 10 May 13 20:02 /dev/tty10
crw--w---- 1 root tty       4, 11 May 13 20:02 /dev/tty11
crw--w---- 1 root tty       4, 12 May 13 20:02 /dev/tty12
crw--w---- 1 root tty       4, 13 May 13 20:02 /dev/tty13
crw--w---- 1 root tty       4, 14 May 13 20:02 /dev/tty14
crw--w---- 1 root tty       4, 15 May 13 20:02 /dev/tty15
crw--w---- 1 root tty       4, 16 May 13 20:02 /dev/tty16
crw--w---- 1 root tty       4, 17 May 13 20:02 /dev/tty17
crw--w---- 1 root tty       4, 18 May 13 20:02 /dev/tty18
crw--w---- 1 root tty       4, 19 May 13 20:02 /dev/tty19
crw--w---- 1 root tty       4,  2 May 13 20:02 /dev/tty2
crw--w---- 1 root tty       4, 20 May 13 20:02 /dev/tty20
crw--w---- 1 root tty       4, 21 May 13 20:02 /dev/tty21
crw--w---- 1 root tty       4, 22 May 13 20:02 /dev/tty22
crw--w---- 1 root tty       4, 23 May 13 20:02 /dev/tty23
crw--w---- 1 root tty       4, 24 May 13 20:02 /dev/tty24
crw--w---- 1 root tty       4, 25 May 13 20:02 /dev/tty25
crw--w---- 1 root tty       4, 26 May 13 20:02 /dev/tty26
crw--w---- 1 root tty       4, 27 May 13 20:02 /dev/tty27
crw--w---- 1 root tty       4, 28 May 13 20:02 /dev/tty28
crw--w---- 1 root tty       4, 29 May 13 20:02 /dev/tty29
crw--w---- 1 root tty       4,  3 May 13 20:02 /dev/tty3
crw--w---- 1 root tty       4, 30 May 13 20:02 /dev/tty30
crw--w---- 1 root tty       4, 31 May 13 20:02 /dev/tty31
crw--w---- 1 root tty       4, 32 May 13 20:02 /dev/tty32
crw--w---- 1 root tty       4, 33 May 13 20:02 /dev/tty33
crw--w---- 1 root tty       4, 34 May 13 20:02 /dev/tty34
crw--w---- 1 root tty       4, 35 May 13 20:02 /dev/tty35
crw--w---- 1 root tty       4, 36 May 13 20:02 /dev/tty36
crw--w---- 1 root tty       4, 37 May 13 20:02 /dev/tty37
crw--w---- 1 root tty       4, 38 May 13 20:02 /dev/tty38
crw--w---- 1 root tty       4, 39 May 13 20:02 /dev/tty39
crw--w---- 1 root tty       4,  4 May 13 20:02 /dev/tty4
crw--w---- 1 root tty       4, 40 May 13 20:02 /dev/tty40
crw--w---- 1 root tty       4, 41 May 13 20:02 /dev/tty41
crw--w---- 1 root tty       4, 42 May 13 20:02 /dev/tty42
crw--w---- 1 root tty       4, 43 May 13 20:02 /dev/tty43
crw--w---- 1 root tty       4, 44 May 13 20:02 /dev/tty44
crw--w---- 1 root tty       4, 45 May 13 20:02 /dev/tty45
crw--w---- 1 root tty       4, 46 May 13 20:02 /dev/tty46
crw--w---- 1 root tty       4, 47 May 13 20:02 /dev/tty47
crw--w---- 1 root tty       4, 48 May 13 20:02 /dev/tty48
crw--w---- 1 root tty       4, 49 May 13 20:02 /dev/tty49
crw--w---- 1 root tty       4,  5 May 13 20:02 /dev/tty5
crw--w---- 1 root tty       4, 50 May 13 20:02 /dev/tty50
crw--w---- 1 root tty       4, 51 May 13 20:02 /dev/tty51
crw--w---- 1 root tty       4, 52 May 13 20:02 /dev/tty52
crw--w---- 1 root tty       4, 53 May 13 20:02 /dev/tty53
crw--w---- 1 root tty       4, 54 May 13 20:02 /dev/tty54
crw--w---- 1 root tty       4, 55 May 13 20:02 /dev/tty55
crw--w---- 1 root tty       4, 56 May 13 20:02 /dev/tty56
crw--w---- 1 root tty       4, 57 May 13 20:02 /dev/tty57
crw--w---- 1 root tty       4, 58 May 13 20:02 /dev/tty58
crw--w---- 1 root tty       4, 59 May 13 20:02 /dev/tty59
crw--w---- 1 root tty       4,  6 May 13 20:02 /dev/tty6
crw--w---- 1 root tty       4, 60 May 13 20:02 /dev/tty60
crw--w---- 1 root tty       4, 61 May 13 20:02 /dev/tty61
crw--w---- 1 root tty       4, 62 May 13 20:02 /dev/tty62
crw--w---- 1 root tty       4, 63 May 13 20:02 /dev/tty63
crw--w---- 1 root tty       4,  7 May 13 20:02 /dev/tty7
crw--w---- 1 root tty       4,  8 May 13 20:02 /dev/tty8
crw--w---- 1 root tty       4,  9 May 13 20:02 /dev/tty9
crw-rw---- 1 root dialout 166,  0 May 13 20:13 /dev/ttyACM0
crw-rw---- 1 root dialout 204, 64 May 13 20:02 /dev/ttyAMA0
crw------- 1 root root      5,  3 May 13 20:02 /dev/ttyprintk
pi@duet3:~ $ sudo bossac -e -w -v -b /home/pi/Desktop/Duet3Firmware_MB6HC.bin 
No device found on /dev/ttyACM0
pi@duet3:~ $ lsusb
Bus 001 Device 004: ID 03eb:6124 Atmel Corp. at91sam SAMBA bootloader
Bus 001 Device 006: ID 0461:4d08 Primax Electronics, Ltd 
Bus 001 Device 005: ID 413c:2107 Dell Computer Corp. 
Bus 001 Device 007: ID 0424:7800 Standard Microsystems Corp. 
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@duet3:~ $ 

Is this thing just a junk paperweight? What am I missing? With the DuetPi OS, all I did was connect it to the internet, update it & reboot, add the username (pi) to the dialout group, and then I ran:

sudo curl -L "https://github.com/Duet3D/DuetPi/blob/master/stage-dsf/00-system/files/bossac?raw=true
" -o /usr/bin/bossac

and

bossac -e -w -v -b /opt/dsf/sd/firmware/Duet3Firmware_MB6HC.bin

I'm at a bit of a loss. I need to start hooking up wiring/electric on this machine. If I can't get this board to be functional in the next 24-48 hours I'm going to have to buy a different board. This is ridiculous. What needs to be done to flash firmware on a MB6HC board that has been erased and is in diag mode?

@dc42 I have a bossa port in Windows Device Manager (Win 10 Pro) and in Ubuntu 20.04 I see Bus 004 Device 002: ID 03eb:6124 Atmel Corp. at91sam SAMBA bootloader when I 'lsusb'.

I am getting a Windows SAM-BA error: "SAM-BA error h_handle returned zero".
I am getting a Windows BOSSA error "Could not connect to device on COM9".

In Linux:
~/BOSSA/bin/bossac -e -w -v -b /home/nvidia/Downloads/Duet3Firmware_MB6HC.bin
No device found on /dev/ttyACM0

Both Windows and Linux machines can see it yet it errors out or refuses to connect. Is this a permissions thing? Is it a configuration issue? Are there jumpers/pins that could be mis-configured?

The documentation is terrible. It is conflicting, confusing, outdated, etc. I have seen others ask about the ribbon cable: The documentation states that a cable over 150mm is a problem yet the board was shipped from the factory with a 200mm cable.

The documentation states to install SAM-BA v. 2.17 yet the photo on the website is of SAM-BA v. 2.16. It also says that you will get connection errors (I am getting connection errors) if you specify the wrong board. Exactly what version of SAM-BA should be installed on a Windows 10 machine and exactly how do I find out or confirm which board/chip I have?

The documentation does not mention a MicroSD card during the erase/re-flash procedure. Should the MicroSD card be installed in the MB6HC board during the erase/re-flash process? What state (file structure, format, etc.) should the MicroSD card be in during the failback#2 procedure?

USB Cable: The documentation states "if it doesn't work, try new/different usb cable" however the board does not ship with a USB cable. What are the required specifications of the USB connection/cable?

I'd appreciate any help trying to flash firmware onto this $250 paperweight. Thanks.

@jay_s_uk
Thanks for the reply. I'm really frustrated with this thing. I've looked at the updating firmware link you posted but since the board is new (and shouldn't need fallbacks), I never read down through the fallback procedures.

I forgot to mention it in my initial post. When I operate the board with a Pi in SBC mode it "works" but everything is slow, it won't upload files, won't update firmware, etc. --but the DIAG LED light is off on the board in SBC mode.

However, when I try to run/connect to the board in standalone mode, that DIAG led light is on (and very faint). It's weird. I thought that maybe I had a bad board or something. But since that DIAG LED is on like that...

Should I go through the procedure of fallback#2 (erase jumper, reset, sam-ba to re-flash)?

Is it at all possible that I could have something running on my machine that could be interfering with the mb6hc in standalone mode? It is Ubuntu 18.04 (desktop) with nvidia sdk development software for jetson xavier and nano as well as software for google coral ai dev and dev mini boards. It talks to all of these boards (nvidia, google, etc.) via various usb protocols.

Where should I start assuming I have a mb6hc board with a faint/dim DIAG led in standalone mode and a blank/formatted MicroSD card?

Thanks.

I am attempting initial setup and firmware upgrades of the following board:
M115
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.2 ELECTRONICS: Duet 3 MB6HC v1.01 or later FIRMWARE_DATE: 2021-01-05

Duet Web Control 3.4.0
Electronics:
Board: Duet 3 MB6HC (MB6HC)
DSF Version: 3.4.0
Firmware: RepRapFirmware for Duet 3 MB6HC 3.2 (2021-01-05)

It runs in SBC mode but I cannot get the board to operate in Standalone mode. When running in SBC mode (with Pi 3B+ via ribbon cable) it seems fine except the board's firmware will not update past 3.2. The Pi is also noticeably slower than when it runs normal Raspbian or Octoprint. Are there specific config settings that are needed?

Ribbon cable: The documentation clearly states "Recommended length is 100 to 150mm. Longer cables will degrade the SPI signal between the Raspberry Pi and the Duet." Why on earth would Duet3D ever ship a 200mm cable from the factory? Is the factory-shipped 200mm ribbon cable contributing to any of the issues I am having while in SBC mode?

What do I need to do to upgrade the 3.2 firmware so that everything matches the latest 3.4?

Thanks.