Duet 2 WiFi stuck in SAM-BA after SPI firmware update
-
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.
-
undefined Phaedrux moved this topic from General Discussion
-
undefined Phaedrux marked this topic as a question
-
@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.
Duet software engineer
-
@umutduman I agree with @chrishamm. What did you connect those expansion port pins to?
-
@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.
-
@umutduman what was the other processor that you connected it to, and how was it powered?
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 that is PsoC which is supplying by 3.3v
-
@umutduman said in Duet 2 WiFi stuck in SAM-BA after SPI firmware update:
@dc42 that is PsoC which is supplying by 3.3v
I don't know what you mean by PsoC. However, when two microcontrollers communicate with each other and they are powered separately, it is important to ensure that when only one of them is powered, the outputs of that one cannot feed more current into the inputs of the second one than the maximum rated injection current of the second one. So my guess is that at some time, your other MCU was powered ands the Duet was not, causing the other MCU to feed injection current into the Duet input. In fact the SAM4E MCU on the Duet doesn't have an injection current rating, implying that injection current isn't allowed at all. Even if injection current doesn't burn out the input pin protection diode, it may trigger parasitic SCRs in some chips that then cause catastrophic damage.
Our Duet 3 main boards use an SPI connection to the optional attached Raspberry Pi or similar SBC and we have to avoid damage when just one of the Duet and the Pi is powered. We connect the SPI signals via buffers that are designed to handle inputs that are referred to a different power rail from the outputs. You can find the schematic and the part numbers of those buffers in Github, for example at https://github.com/Duet3D/Duet3-Mainboard-6HC/tree/master/Duet3_Mainboard_6HC_v1.02.
