@oliof I have no document for the public, but for internal use only and it's still not very advanced, but it works for our configuration and purpose. Some settings are dependant of which type of SBC you are using - in our case a CM4 module on an IO board - and which GPIO pins are free on the SBC. The SWD pins SWDIO, SWCLK, RESET and GND need to be connected to the SBC, and the GPIOs need to be configured as output in /boot/config.txt.

This is the sequence of commands I use for flashing the firmware via the SWD interface (GPIO18 is connected to RESET in our case):

raspi-gpio set 18 dl
openocd -f ocd.cfg -c "init; halt; flash protect 0 0 last off"
openocd -f ocd.cfg -c "init; halt; flash write_image erase Duet3Firmware_MB6HC.bin 0x00400000"
openocd -f ocd.cfg -c "init; halt; reset run"
raspi-gpio set 18 dh

Executing an openocd command holds the connection and need to be terminated with CTRL+C after it has done its task. I still did not find a way to do this all in one line.

content of ocd.cfg:
adapter driver bcm2835gpio
bcm2835gpio peripheral_base 0xFE000000
bcm2835gpio speed_coeffs 236181 60
adapter gpio swclk 23
adapter gpio swdio 24
adapter gpio srst 18
transport select swd
set CHIPNAME atsame70q20
source [find target/atsamv.cfg]
reset_config srst_only srst_push_pull
adapter speed 1000

peripheral_base and speed_coeffs are dependant of which SBC you have

@misterjtc can you try loading the vc4-fkms-v3d overlay instead of the vc4-kms-v3d one, this is the one we are using in our setup

@oliof I have no document for the public, but for internal use only and it's still not very advanced, but it works for our configuration and purpose. Some settings are dependant of which type of SBC you are using - in our case a CM4 module on an IO board - and which GPIO pins are free on the SBC. The SWD pins SWDIO, SWCLK, RESET and GND need to be connected to the SBC, and the GPIOs need to be configured as output in /boot/config.txt.

This is the sequence of commands I use for flashing the firmware via the SWD interface (GPIO18 is connected to RESET in our case):

raspi-gpio set 18 dl
openocd -f ocd.cfg -c "init; halt; flash protect 0 0 last off"
openocd -f ocd.cfg -c "init; halt; flash write_image erase Duet3Firmware_MB6HC.bin 0x00400000"
openocd -f ocd.cfg -c "init; halt; reset run"
raspi-gpio set 18 dh

Executing an openocd command holds the connection and need to be terminated with CTRL+C after it has done its task. I still did not find a way to do this all in one line.

content of ocd.cfg:
adapter driver bcm2835gpio
bcm2835gpio peripheral_base 0xFE000000
bcm2835gpio speed_coeffs 236181 60
adapter gpio swclk 23
adapter gpio swdio 24
adapter gpio srst 18
transport select swd
set CHIPNAME atsame70q20
source [find target/atsamv.cfg]
reset_config srst_only srst_push_pull
adapter speed 1000

peripheral_base and speed_coeffs are dependant of which SBC you have

@dc42 Is there any recommendation what we can do or test in case of another occurance to narraw down the issue. Duet boards of our older machines are only connected with the SPI interface to the SBC, whereas newer machines also have the SWD interface connected and openocd installed on the SBC.

@qurt You could use the HTTP requests API and talk to the Duet Board via LAN. https://github.com/Duet3D/RepRapFirmware/wiki/HTTP-requests

@misterjtc can you post the content of your /boot/config.txt

@dc42 On the first occurances our guess was that the Duet boards got somehow damaged - the Duet Web UI could not connect to the board and the log journal of the DuetControlServer service running on the SBC showed that is was permanently restarted, reporting communication issues with the Duet board. We sent our customers replacement boards and with the new boards the issue was gone. If customers could not replace it themselves we exchanged the complete device. As the replaced Duet boards piled up our electronics department had a look at the boards. There was one board with a diode soldered in the wrong orientation, but on all other boards no issue could be found and the boards could be brought to life again by flashing the firmware via BOSSA/USB.

Currently I have no Duet board available in the 'corrupted' state as all have been re-flashed, but I think I can remember that the status LED was not flashing at all, I think normally it should be flashing at a 1 second period.

As a work-around to be able to flash a 'corrupted' board remotely we have assembled newer devices with a connection of the SBC with the SWD pins of the Duet board, so we can reset and flash the board via OpenOCD software directly from the SBC.

Hi all,

we have issues that the flash memory of MB6HC v1.02 Duet boards gets corrupted from time to time. The only way to restore the boards is by flashing the firmware either via BOSSA/USB or OpenOCD/SWD. The firmware version we are using is v3.4.5. The MB6HC is powered by the SBC (JP9 jumper set to 5V_SBC).

Currently all reported issues have the newest revision of the Duet board, v1.02. For the older boards (v1.00/v1.01) we used firmware v3.3.0, but as we had issues with this firmware with the newer boards (v1.02) we switched to v3.4.5.

Checking the schematics we saw that there has been some changes on the power supply / buck converters of the board between revision 1.01 and 1.02. We are not sure if this may cause the issue in some way. We measured the 3.3V and it slightly drops when VIN is cut off, what we did not expect as the 5V is set to be supplied by the SBC.

Our device is a laser cutter. Any time the device is opened we turn off the 24V power supply (VIN) connected to the Duet board. If the device is opened while executing any G-code we send a M999 to the Duet board to immediately stop the device. VIN may drop at different speed depending on what stepper motors are currently moved, or if the compressor is turned on while the laser source is active.

Any ideas where this issue may come from is very welcome as we have almost two hundred devices globally distributed.

Kind regards,
Andreas

@chrishamm Sorry I mixed up something: the machines where the "Firmware reset imminent" message is logged are for older machines with the older generation of the 6HC boards, on which we had installed the 3.3.0 RRF/DSF. On these machines still no flash memory corruption has been reported. On the new machines with the latest generation of the 6HC boards (v1.02) we installed version 3.4.5 of RRF/DSF. These newer machines have no "Firmware reset immiment" logging as this output has been removed from the source code. On these newer machines we have incident reports of non working 6HC boards. When analysing the boards we found no hardware issues but the firmware had been somehow corrupted. When we manually reflashed the boards with RRF 3.4.5 everthing was working again as expected.

So my question is how can the flash memory of the 6HC boards CPU be corrupted. Is there any condition or occurance which may lead to this or may trigger an automated firmware update, which may be interrupted when turning the machine off. Currently it looks like that this only occurs on the v1.02 generation of the 6HC boards or only with version 3.4.x of RRF/DSF.

@chrishamm
Here is an image of the log created via: journalctl -u duetcontrolserver | grep warn
The under-voltage event always occurs when the door of the laser cutter is opened. We have multiple machines out there logging a 'Firmware reset imminent' a few times a day.
I will have access to a machine on Monday, then I can try to reproduce the issue in-house and also update the RRF/DSF to 3.4.6 as you recommended.

@T3P3Tony The machine is a laser cutter, if the door is opened VIN is cut (laser source and stepper motors) and a M999 command is sent to the Duet board to stop executing any movement or cutting. So I would expect the "under voltage" and "Resetting controller" messages but not the "Firmware reset imminent" message.