Official bladeRF forum

That honestly sounds more like a USB signaling/power negotiation issue than a bladeRF software problem, especially since it works through a hub.

I’ve seen similar behavior with some Intel xHCI controllers where direct USB 3.x connections behave badly with SDR devices, but putting a powered USB hub in between stabilizes timing enough for transfers/FPGA access to work correctly.
heardle
A few things I’d try:

disable USB selective suspend in Windows power settings
disable USB power saving for the xHCI controller in Device Manager
force the port to USB 2.0 mode if possible
try a different cable (bladeRF can be surprisingly sensitive to marginal cables)

The “Failed to send NIOS II request” / Read Error -5 usually points to communication instability rather than FPGA corruption from what I’ve experienced.

Honestly, if the hub works reliably, many SDR users just keep using one permanently.

If it works through a USB hub but not directly, that sounds more like a USB controller or power management issue than a bladeRF problem. Have you tried disabling USB selective suspend and any Intel USB power saving features in Windows?