Duet3 6hc Repair bootloader

Overview

This guide details the process to recover a Duet 3 6HC that is stuck in BOSSA mode by reprogramming the bootloader using a Raspberry Pi as an SWD programmer.

Parts

- Raspberry Pi (any model with GPIO, e.g., Pi 3, Pi 4, Zero, etc.)
- Duet 3 6HC Board
- Jumper Wires (Female-to-Female)
- MicroSD Card (for firmware updates later)
- Duet3Bootloader-SAME5x.bin (Download from Duet3D GitHub)

Steps

Identify the SWD Header on Duet 3 6HC

The SWD header is a small 5 or 6-pin unpopulated header near the Atmel SAME51 microcontroller, usually labeled SWD, JTAG, or DEBUG.

Wiring: Connect Raspberry Pi to Duet 3 6HC

| Raspberry Pi Pin | Duet 3 6HC Pin | Function |
|------------------|----------------|----------|
| Pin 2 (5V) or Pin 1 (3.3V) | 3.3V (VCC) | Power |
| Pin 6 (GND) | GND | Ground |
| Pin 22 (GPIO 25) | SWDIO | SWD Data |
| Pin 23 (GPIO 11) | SWCLK | SWD Clock |
| Pin 18 (GPIO 24) | RESET (Optional) | Reset |

Install OpenOCD on Raspberry Pi

`bash
sudo apt update && sudo apt upgrade -y
sudo apt install openocd -y
openocd --version
`

Configure OpenOCD for SWD Communication

Create an OpenOCD configuration file:
`bash
nano duet3.cfg
`
Add the following content:
`
interface bcm2835gpio
bcm2835gpio_peripheral_base 0x3F000000
bcm2835gpio_speed_coeffs 236181 60
transport select swd
set WORKAREASIZE 0x4000
source [find target/atsame5x.cfg]
bcm2835gpio_swd_nums 25 11
bcm2835gpio_srst_num 24
`

Start OpenOCD and Flash Bootloader

`bash
sudo openocd -f duet3.cfg
`
In another terminal window:
`bash
telnet localhost 4444
reset halt
at91samd chip-erase
flash write_image erase Duet3Bootloader-SAME5x.bin 0x00000000
verify_image Duet3Bootloader-SAME5x.bin 0x00000000
reset run
`
Power-cycle the Duet 3 6HC by disconnecting and reconnecting power.

Flash the Main Firmware

Download Duet3Firmware_MB6HC.bin from Duet3D GitHub and flash it using BOSSA:
`bash
bossac --port=usb -e -w -v -b Duet3Firmware_MB6HC.bin -R
`

Notes

- Ensure correct wiring to avoid programming errors.
- Only use 3.3V power (Pin 1) if unsure; using 5V may damage the microcontroller.

Troubleshooting

Problem

OpenOCD Fails to Detect Target Chip
When attempting to use OpenOCD with SWD debugging on a Raspberry Pi, you might encounter the following output:
`
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'adapter driver' not 'interface'
...
Info : SWD DPIDR 0x00000000
`
The critical issue here is SWD DPIDR 0x00000000, which indicates that OpenOCD is not detecting the target chip.

Solution

1. Check Physical Connections
- Ensure SWDIO, SWCLK, GND, and VCC are correctly connected.
- Try swapping SWDIO and SWCLK.
- Ensure the target is powered and running.
- Use 10kΩ pull-up on SWDIO and 10kΩ pull-down on SWCLK, if necessary.

2. Verify SWD Pins on Raspberry Pi
`bash
raspi-gpio get
`

3. Check If the Target Is Locked
`bash
openocd -f interface/raspberrypi-native.cfg -f target/stm32f4x.cfg -c "init" -c "reset halt" -c "stm32f4x unlock 0" -c "shutdown"
`

4. Enable Debug Logging in OpenOCD
`bash
openocd -d3 -f
`

5. Try PyOCD as an Alternative
`bash
pip3 install --upgrade pyocd
pyocd list
`

If OpenOCD reports SWD DPIDR 0x00000000, SWD communication is failing. By verifying physical connections, checking pin states, reducing clock speed, unlocking the target, and using debug logs, the issue can be resolved.