Duet3 requires BOSSA flash if more than 1 exp boards.
-
Hmmm... I have a 6HC (of course, 0), and a 3HC expansion at 1 and 2. With an exception here or there that failed for completely different reasons, the standard apt update/upgrade always succeeds in loading firmware into the 6HC correctly.
Then, an M997 B1 and B2 works. That DOES cause a disconnect, and depending on the release, the error messages have ranged from a simple disconnect/reconnect, to a screen full of red. Despite whatever messages, this also always works.
Therefore... is there a possibility that your CAN is set up where it works for daily use but fails during upgrades? I'm not even sure what that could be; it might be worthwhile to ensure that none of your boards have terminator jumpers, except the last one and ensure that it DOES have them, etc.
Again, I'm not sure. Obviously you are having a different result than I am; mostly I'm posting to let you know that at least one person (outside of Duet) has this working, so that we can look for differences.
A (not that great) photo of my current installation, it is a little hard to see the CAN cables in this:
-
Hmm, thanks for the info. I am 99.99% sure that right now if I where to upload a new firmware file for the Duet3 or an expansion board I would have to re-flash the firmware using Bossa.
Here is my setup.
-
You can see no jumpers on 1 and yes jumpers on 2 in these photos:
-
@RobMink said in Duet3 requires BOSSA flash if more than 1 exp boards.:
Hmm, thanks for the info. I am 99.99% sure that right now if I where to upload a new firmware file for the Duet3 or an expansion board I would have to re-flash the firmware using Bossa.
Here is my setup.
Yeah, I can see the jumpers, they look right.
-
So... what else... I'm on RC9, and RC7, 8, and 9 on the 6HC all run RC7 on expansion, so I did NOT do the M997 B1 and so forth.
The main board did get 7, 8, and 9, (and numerous prior) during the "apt update/upgrade". Although, to be clear, this did not always work around RC4 and back. Somewhere around 6 or 7 it became completely reliable (for me).
-
AH, debugging question:
Once you have everything "bossa"-ed, and Pi ugpraded, and they are talking, does a
M997 B0
Succeed for you? Specifically for 0?
-
-
Very, very, very interesting that B0 fails.
Hmmm... let me look at all of this some more.
-
Ok, the fact that your machine operates for normal DWC argues very strongly that the Ribbon Cable and the SPI connection is OK. Nonetheless... if you want to give it a try... we can check that connection:
To install the test utility:
- wget https://github.com/DanalEstes/DuetTestSPI/raw/master/DuetTestSPI
- chmod 744 DuetTestSPI
To do actual checks, you will need to unplug the ribbon at the pi end(power off, of course) and jumper two spots: Pi GPIO pins 19-21 and 22-24
Then, run
./DuetTestSPIThe messages should be fairly clear... you can post here if you wish, or just state if the utility said all was OK (or not).
Then, plug the ribbon into the Pi, unplug the Duet end, and jumper those same pins. Run the utility again.
Like I said, this is a true long shot; at the same time, it can give some confidence that nothing truly weird is going on with the SPI.
-
I happened to do an update/upgrade a few min ago. Resulted in RC10. Firmware load to board went fine. See line 25 in second block.
M115 FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.01-RC10 ELECTRONICS: Duet 3 MB6HC v0.6 or 1.0 FIRMWARE_DATE: 2020-04-25b3
pi@duet3:~/TAMV $ sudo apt upgrade duetsoftwareframework Reading package lists... Done Building dependency tree Reading state information... Done Unpacking rpi-eeprom-images (5.8-1) over (5.7-1) ... Preparing to unpack .../12-rpi-eeprom_5.8-1_all.deb ... Unpacking rpi-eeprom (5.8-1) over (5.7-1) ... Preparing to unpack .../13-rpi-update_20200409_all.deb ... Unpacking rpi-update (20200409) over (20140705) ... Setting up duetruntime (2.1.1) ... Setting up rpi-chromium-mods (20200407) ... Setting up openjdk-11-jre-headless:armhf (11.0.7+10-3~deb10u1) ... Installing new version of config file /etc/java-11-openjdk/security/default.policy ... Installing new version of config file /etc/java-11-openjdk/security/public_suffix_list.dat ... Setting up openjdk-11-jre:armhf (11.0.7+10-3~deb10u1) ... Setting up openjdk-11-jdk-headless:armhf (11.0.7+10-3~deb10u1) ... Setting up rpi-update (20200409) ... Setting up openjdk-11-jdk:armhf (11.0.7+10-3~deb10u1) ... Setting up rpi-eeprom-images (5.8-1) ... Setting up duetwebcontrol (2.1.5) ... Setting up duetcontrolserver (2.1.1) ... Installing new version of config file /opt/dsf/conf/config.json ... Setting up duettools (2.1.1) ... Setting up reprapfirmware (2.1.1-1) ... Sending update request to DCS... Done! Setting up rpi-eeprom (5.8-1) ... Setting up duetsoftwareframework (2.1.1) ... Processing triggers for mime-support (3.62) ... Processing triggers for hicolor-icon-theme (0.17-2) ... Processing triggers for man-db (2.8.5-2) ... Processing triggers for desktop-file-utils (0.23-4) ...
-
Hmm, Ok. I will try that as soon as the printer is done printing and I have a wee bit of down time. Thanks!
-
Yeah, that whole SPI test is a longshot.
Perhaps before doing that, try a M997 B0 with the CAN cable unplugged from the 6HC.
-
And, FWIW, after I did the "apt " style update to RC10 on the main board, I did a M997 B1 just to check if the expansion boards needed an update (they don't, they are still RC7). WOW, the messages got a LOT cleaner. We now get a "Please wait, updating board 1" (or something like that) pop up, and
M997 B1 Board 1 starting firmware update
In the log. Clean reconnect when it finishes.
-
Just did the latest FW update, it went flawlessly.