Booster stucked in reboot cycle

Ilyich2011

Hello, everyone!
During setting up a booster, I tried to set it a static IP, to connect it via ethernet to the PC. After commands

write ip-address 10.0.0.43
write netmask 255.255.255.0
reset

booster entered a reboot cycle I can not stop. It starts its fans for a several seconds, after that it flashes yellow LEDs for a second or two and reboots.

Device info (taken from the another booster from the same shipping. The faulty one I can not get info from now):
Version: v0.4.0-175-g9ef1510
Hardware Revision: v1.6
Rustc Version: rustc 1.68.2 (9eb3afe9e 2023-03-27)
Features:
Detected Phy: Enc424j600

What I already tried:
1) Monitor any debugging info via USB. It failed, as the USB at booster is initialized after it fails (there are some issues about that on github, for example https://github.com/quartiq/booster/issues/229 ). I tested, that via "sudo dmesg | grep tty" there are no new device connections are logged while the connected booster reboots => I can not connect to it to monitor something.
2) Tried to reflash it via DFU. I tried the last release version from the github (https://github.com/quartiq/booster/releases , tried 0.6.0). It successfully flashed accordingly to the manual, but the result was more or less the same (maybe the LED blink became shorter).
3) Tried flashing with 0.4.0 from the github (also did not work). Following issue https://github.com/quartiq/booster/issues/242 (the symptoms are very similar, as well as a firmware version), tried flashing with a firmware from the 'feature/enc424j600-support' branch setting the correct phy_feature, as it seems that it must be it that was flashed there on shipping. No luck again.
4) As my theory is that somehow the ip-address/netmask parameters I've set are incorrect and it causes panic at startup, I supposed that during the flash I didn't erase sections of the memory which contain network parameters, so I tried to reflash it using

dfu-util -a 0 -s 0x08000000:mass-erase:force:leave --download booster-release.bin

No luck again.
5) Finally, I tried to dump the firmware from the working device to the faulty one by running the following commands with a working one in DFU mode:

dfu-util -a 0 -s 0x08000000 --upload b0.bin
dfu-util -a 0 -s 0x08010000 --upload b1.bin
dfu-util -a 0 -s 0x08020000 --upload b2.bin

And these with a faulty one:

dfu-util -a 0 -s 0x08000000 --download b0.bin
dfu-util -a 0 -s 0x08010000 --download b1.bin
dfu-util -a 0 -s 0x08020000 --download b2.bin

And I still have the same results.

It seems, now I am out of idea how to revive it. Any ideas what's wrong and how to fix it?

sb10q

Please pay attention.

Ilyich2011 I tested, that via "sudo dmesg | grep tty" there are no new device connections are logged while the connected booster reboots => I can not connect to it to monitor something.

esavkin

Are there any logs from Booster?

rjo

I don't know off hand whether the mass-erase dfu command is correct like that.
Other than ensuring it is, the next step would be to connect a SWD debugger and have a look at the panic messages there.

rjo

Elsewhere it looks like people do this: https://github.com/dhylands/upy-examples/blob/master/mass-erase.sh maybe that's a useful reference.

Ilyich2011

Finally, resolved the issue by modifying the 0.6.0 firmware making it to ignore the current eeprom mainboard settings, using the default ones, and storing them to the device. But without any debug info it was tough)