Duet3 requires BOSSA flash if more than 1 exp boards.



  • If i leave more than 1 exp board connected to the duet3 main board and run an upgrade from the RPI CLI or upload new firmware and let DWC run an upgrade the duet3 bricks. I must then erase, flash using bossa, then update each board by setting its id to 1, hooking it up as the only board and then M997 B1 ing it. The last board in the series (#3 for me) updates fine. (I have issues with M997 B1 if it is not the only board and always an issue with M997 B2) I get errors that the Duet3 has lost connection when upgrading the exp boards, and lots of can errors. I also get an error blink on the board I am attempting to upgrade

    In short, if more than one exp board is attached firmware upgrades always fail through DWC. To update the exp boards they must be the last board on the can bus.

    This has been an issue throughout all upgrades I have done. I wanted to explore the bug a little more than just 'upgrades fail.'



  • 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:

    IMG_0390 (1).jpeg



  • 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.20200425_125107.jpg



  • You can see no jumpers on 1 and yes jumpers on 2 in these photos:

    IMG_0438.jpeg IMG_0439.jpeg

    IMG_0439.jpeg



  • @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.20200425_125107.jpg

    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?



  • @Danal

    Nope, I made this video tho show what I am doing.

    https://youtu.be/Fn2VejqtvBY



  • 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:

    1. wget https://github.com/DanalEstes/DuetTestSPI/raw/master/DuetTestSPI
    2. 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
    5e1f265c-e398-4af3-a282-dd5bbd4a9965-image.png

    Then, run
    ./DuetTestSPI

    The 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.


Log in to reply