Re: What about the Nios2?
Posted: Tue Jun 09, 2015 7:49 am
Hi Erik,
First, I just wanted to let you know that the updated code has been pushed to a dev-fpga_v0.2.0 branch on the Nuand repo. It will undergo some further review and testing there, before being merged to master.
Regarding the 2015.06.08.16:31:00 Info: No custom instruction connections, skipping transform message. Are you using Quartus 15.0? This is required for the new FPGA code. I honestly have no idea what this error message is actually trying to convey, and can only guess that your environment differs from ours in some significant way.
Timeouts
If you connect to the NIOS II core and the byte blaster is holding it in reset, then the host (libbladeRF) will not receive responses to its requests. This is why it times out. When stepping through code on the NIOS II, I use the -DLIBBLADERF_DISABLE_USB_TIMEOUTS CMake option to compile out the timeouts. (Note that since bladeRF-cli catches Ctrl-C, you'll want to kill it some other way, such as with SIGUSR1 if you find that you need to.)
If your FPGA image is bad or contains problems, timeouts will occur just because the device is not running.
To debug the NIOS code, I would load the FPGA as you normally do, and exit the CLI. Then I would attach the debugger, and have it load and reset the NIOS core. This should run fine.
libbladeRF version
If you checked out that code in the new branch or pulled it from my archive, you can build it the same way you normally would. See the wiki for this. If you're unfamiliar with using git to check out a branch, some of these resources should be of great help.
First, I just wanted to let you know that the updated code has been pushed to a dev-fpga_v0.2.0 branch on the Nuand repo. It will undergo some further review and testing there, before being merged to master.
Regarding the 2015.06.08.16:31:00 Info: No custom instruction connections, skipping transform message. Are you using Quartus 15.0? This is required for the new FPGA code. I honestly have no idea what this error message is actually trying to convey, and can only guess that your environment differs from ours in some significant way.
Timeouts
If you connect to the NIOS II core and the byte blaster is holding it in reset, then the host (libbladeRF) will not receive responses to its requests. This is why it times out. When stepping through code on the NIOS II, I use the -DLIBBLADERF_DISABLE_USB_TIMEOUTS CMake option to compile out the timeouts. (Note that since bladeRF-cli catches Ctrl-C, you'll want to kill it some other way, such as with SIGUSR1 if you find that you need to.)
If your FPGA image is bad or contains problems, timeouts will occur just because the device is not running.
To debug the NIOS code, I would load the FPGA as you normally do, and exit the CLI. Then I would attach the debugger, and have it load and reset the NIOS core. This should run fine.
libbladeRF version
If you checked out that code in the new branch or pulled it from my archive, you can build it the same way you normally would. See the wiki for this. If you're unfamiliar with using git to check out a branch, some of these resources should be of great help.