BeagleV-Fire soft-bricked after flashing custom FPGA bitstream: HSS freezes at IHC initialization, USB MSD invisible

BeagleV
1

Hi everyone,

I am an intern working with the BeagleV-Fire board. While doing isolated testing on the FPGA fabric, I flashed a custom .spi bitstream using the standard gateway tools under Linux.

Unfortunately, this custom bitstream seems to have broken the FIC (Fabric Interface Controller) or clock synchronization between the FPGA and the MSS. The board is now completely soft-bricked and trapped in a hard lockup during early boot.

Here is the exact log captured from the UART interface (115200 8N1):

text

HSS: decompressing from eNVM to L2 Scratch ... Passed
[0.46024] wdog_service monitoring [u54_1] [u54_2] [u54_3] [u54_4]
[0.53662] beu_service :: [init] -> [monitoring]
[0.59868] GPIO_UI: USBDMSC requested
[0.65024] Initializing Mi-V IHC V2

Utilisez le code avec précaution.

What I have tried so far:

  1. USR Button Boot: When I hold the USR button down at power-up, the HSS correctly detects the button press (GPIO_UI: USBDMSC requested). However, it freezes immediately right after the next line: Initializing Mi-V IHC V2.

  2. USB Detection: Because it freezes at the IHC stage, the USB OTG controller never starts. Running lsusb on my Linux host computer shows absolutely nothing. The board is completely invisible to BeagleBoard Imager or BalenaEtcher.

  3. UART Bombardment: I tried running a loop script sending Enter, Space, and Ctrl+C over UART during boot to interrupt the HSS, but the system is frozen at the hardware level and doesn’t respond.

  4. Visual status: The two LEDs right next to the Ethernet port stay statically ON.

Our lab does not own a FlashPro5/6 JTAG programmer or a Tag-Connect cable.

Is there any hardware trick, pin-strap configuration, or a fallback boot mode to force an erase of the corrupted FPGA fabric / eNVM without a FlashPro hardware tool? For instance, could I use another Linux board (like a Raspberry Pi) to execute a DirectC/bit-banging recovery over the JTAG pins?

Thank you so much for your help and guidance!

2

You can try the DirectC approach from a PI or another Beagle.

The trick is to erase or disable the external SPI Flash chip while you’re at it.
Otherwise SysCon will pick up the bad bitstream and you’re back in hot water.

3

As for all your other points: No Linux => No nothing, that much should be obvious.

Even if you could break into HSS, all that’ll let you do is to reprogram the eMMC.
Unfortunately, that has absolutely zero influence on the bitstream.