Duet 2 WiFi stuck in SAM-BA after SPI firmware update

[umutduman]

Duet 2 WiFi stuck in SAM-BA mode and MCU overheats after SPI firmware changes – unable to recover via JTAG/SWD

We are working on a custom firmware feature for Duet 2 WiFi, and after modifying the firmware to communicate with an external MCU via SPI using the expansion port (PB0, PB1, PB13, PA24), we encountered a critical issue on two different Duet 2 WiFi boards. A custom G-code command (M2000) was implemented to trigger SPI communication from within the firmware, which compiled and flashed successfully using bossac with the command -e -w -v -l -b Duet2CombinedFirmware.bin. However, immediately after flashing, both of the Duet 2 WiFi boards failed to boot normally and appeared only as SAM-BA USB devices on the PC. Additionally, the MCU began overheating rapidly even while idle. When attempting to reflash the official Duet2CombinedFirmware.bin, we received a Verify failed message with Page errors: 1021 and Byte errors: 377954, indicating a severe write or flash integrity issue. We attempted recovery through both SWD and JTAG using a J-Link, ensuring correct pin connections and testing with and without resistors R36, R49, and R52 populated, but results remained the same. The J-Link interface consistently reported "RESET (pin 15) high, but should be low", "Unexpected core ID: 0x00000000", and "TDO is constant high", preventing identification of the target. We verified that VTarget was correctly detected as 3.3V and all connections were sound. We believe the custom SPI firmware may have caused a hardware fault or internal lockup, possibly through misconfigured peripherals such as DMA or SPI. At this point, we are unsure whether the MCUs are permanently locked or physically damaged and would appreciate any suggestions on recovery, or confirmation whether MCU replacement is our only option.

[chrishamm]

@umutduman It sounds a lot like you fried the MCU with your custom circuitry. The MCU should never get hot, but if you overload the pins or connect more than +3.3V to them, that will physically damage the processor. So I think a MCU replacement is your only option. I'd be quite surprised if you managed to damage the MCU only by configuring the SPI peripheral or DMA wrong.

[dc42]

@umutduman I agree with @chrishamm. What did you connect those expansion port pins to?

[umutduman]

@chrishamm, @dc42 thanks for reply sir. actually I just connected the mosi miso clock and cs pins of the other processor and shorted their grounds. after that I used eclipse to communicate with my other processor by making the necessary changes to the code. What surprised me is that I managed to communicate with the other processor using uart, but when I tried with spi I encountered this problem. It was the first time I burnt a processor without any physical contact with the hardware.

[dc42]

@umutduman what was the other processor that you connected it to, and how was it powered?

[umutduman]

@dc42 that is PsoC which is supplying by 3.3v