What about the Nios2?

Discussions related to embedded firmware, driver, and user mode application software development
erik
Posts: 17
Joined: Mon May 18, 2015 12:35 am

What about the Nios2?

Post by erik »

Hello,

I try to get the Nios2 work but there are not any information about that.

What I have done so far is to create the fsk_bridge project. I have not test it but in general it should be working.
So the only complete c-project for the Nios2 is the fsk_bridge?

What is the Nios2 doing in the hostet revision?
I created a revision based on the hostet myself without compiling an c-code an the bladeRF-cli is still working.
I thought the Nios2 is for configuring some peripherial devices like the Si5338.

My next point is to try to create a c-project. I will use the fsk_bridge as a reference.
My only goal is to configure the bladeRF by using the Nios2. I have inserted the lms and the Si5338 code so far.

I will let you know if I have reached anything
erik
Posts: 17
Joined: Mon May 18, 2015 12:35 am

Re: What about the Nios2?

Post by erik »

Ok I have figured out that the lms_spi_controller is the source running on the nios.

I get the code in eclipse but how can I debug when I have created my own code?
At the Moment the greatest problem is that i can not include any file to the project. Eclipse do not find it neither the stdio.h.
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: What about the Nios2?

Post by jynik »

We're actually right in the middle of a design overhaul (which is backwards compatible) of the NIOS II code to make it vastly more readable, add new features, and improve the performance of certain operations. This is very much a work in progress, so I wouldn't advise trying to use it yet, but if you want to take a peek, check the bladeRF fork on my GitHub account, in the dev-nios2_refactor branch. I think you'll find our new changes much more clear; I'm certainly like working with this code better. With that said, we're busying working on that code; I don't have much time now to offer support on something that's changing daily until we're ready to merge it.

Once we've gotten a sense that we are happy with the design changes, this will be pulled into a development branch in the official Nuand repo, for community members to test drive.

As it stands in master, the "hosted" NIOS II code merely receives requests to read/write device registers or interfaces attached via the NIOS II's parallel IO ports (PIO).

I'm told the fsk_bridge has been deprecated and no longer functioning since the early days of the platform. The full LMS6002D or Si5338 code is not currently running in the NIOS II. Part of the aforementioned efforts involves running some of the frequency tuning code in the NIOS II. To get that old bridge example running, I believe one would have to pull in this code and some FPGA logic for the FSK mod/demod.

How are you importing the project into Eclipse to start out? You'll have to have run an FPGA build to start to ensure the NIOS II BSP is built.

Also note that Eclipse will complain about not seeing headers or macro definitions because it's really just a glorified (yet less functional than Emacs/Vi ;) ) editor calling the project's Makefile. You have to manually add include paths and such to the project properties if you want all the syntax highlighting and variable references and such to work. (IMHO, it's easier just to use your favorite editor and the Makefile...)

Best regards,
Jon
erik
Posts: 17
Joined: Mon May 18, 2015 12:35 am

Re: What about the Nios2?

Post by erik »

Hello and thank you for the quick answer,

I get the project to Eclipse by "Import" --> "General" --> "Existing Projects into Workspace" and the navigate to the lms_spi_controller bsp.
The only reason for using Eclipse is the hope to have the chance to debug maybe over usb or jtag. Without debugging it would be nearly impossible for me to build a running project.
Maybe I have to spend some time to get familiar with cmake (and forget debugging?). For beginners its much easier to use a gui, sorry.

But let me explain me main goal to ensure I'm on the right way.
I want to control the bladeRF from the nios and the fpga. Some signal processing and the whole configuration.

I have seen there are functions for setting registers in the lms and the si5338.
So I should be able to set up all things I have to.
Is that right or is there an easier way. Maybe like using the functions provided by lms.h and si5338.h?
That would be great but in my opinion it is not easy or impossible to get this running on the nios. Please correct me if this if wrong.

So when I have set up the registers I can send Signals using the fpga. Therefor I have to shift the valid signal and offer some I Q data. right?

At last for your information I'm now using the hosted revision. I think it is more common and better supported.

I'm very sorry about so much questions I try to get as much information as I can but it is all scattered around this forum, github and readmes.

Greetings,

Erik
erik
Posts: 17
Joined: Mon May 18, 2015 12:35 am

Re: What about the Nios2?

Post by erik »

Hello,

is there someone who can get a working nios2 project for eclipse?
I try for 3 days without any success.

So I'am not able to develop anything.
The "Getting Started with the Graphical User Interface" is not really helpful.
I think i can try to generate a new project but I do not want to do all by myself from the ground.
To import the existing project would be very great.

Please describe if you know how I can get this.

THX

Erik
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: What about the Nios2?

Post by jynik »

Hi Erik,

As I mentioned above, I'm currently working on a re-design (for readability, better performance, and new features) of the NIOS II support, which is ongoing in the branch I mentioned. When we've finished and tested this to a significant degree, I'll plan to add some actual documentation on what the implementation is doing, and how to launch a debug session.

Note that the NIOS II is essentially a tiny "microcontroller" -- you won't be doing any signal processing in it. Think of it as more of a means to control and interact with the blocks (e.g., signal processing modules) you place in the programmable fabric, or the devices attached to the FPGA. In the hosted design, it's simply taking requests to configure/control FPGA modules or devices (i.e., the Si5338 and LMS6002D).

As I mentioned above, I'm focusing on finishing up these changes, but will then work on some of the documentation you noted to be lacking. This will probably be another two weeks, but hopefully you'll find it vastly more helpful.

For now, here's quick summary to get you started, assuming $BLADERF is the top-level of the repository. Hopefully this gets you on the right path. When I finish the aforementioned re-design, I can be of more help, and will have steps like these better documented.

Before starting: Ensure you've pulled the latest bladeRF master. While working on the NIOS II, I found this change was needed by Eclipse to set up the debug target properly.

(1) Enter the "NIOS II command shell", which is just bash with a bunch of environment variables set. I installed Quartus 13.1 in ~/software/quartus, hence this being how I launch it: ~/software/quartus/13.1/nios2eds/nios2_command_shell.sh.
(1a) If you do not use the NIOS II command shell, you'll need the following environment variables in your shell, which will depend on where you've installed Quartus:

Code: Select all

# Quartus 13.1
export QUARTUS_13_1_DIR=~/software/quartus/13.1
export QUARTUS_ROOTDIR=$QUARTUS_13_1_DIR/quartus
export SOPC_KIT_NIOS2=$QUARTUS_13_1_DIR/nios2eds
export PATH=$PATH:$QUARTUS_ROOTDIR/sopc_builder/bin
export PATH=$PATH:$QUARTUS_ROOTDIR/bin
export PATH=$PATH:$QUARTUS_13_1_DIR/modelsim_ase/linuxaloem
export PATH=$PATH:$SOPC_KIT_NIOS2/bin
export PATH=$PATH:$SOPC_KIT_NIOS2/sdk2/bin
export PATH=$PATH:$QUARTUS_13_1_DIR/nios2eds/bin/gnu/H-i686-pc-linux-gnu/bin
(2) First, we need to do an initial build of the FPGA as-is, because this will generate the NIOS II BSP for us. In this case, the build is for an x40:
(2a) cd $BLADERF/hdl/quartus
(2b) ./build_bladerf.sh -s 40 -r hosted

(3) With the FPGA built, we should now have what we need for the NIOS II BSP. cd $BLADERF/hdl/fpga/ip/altera/nios_system/. Note that this is where all our NIOS II files live, included those autogenerated.
(4) cd software/ -- This is where the (soon to be more appropriately renamed) lms_spi_controller project lives, and the BSP.

(5) Launch the Eclipse that comes with the altera tools: ~/software/quartus/13.1/nios2eds/bin/eclipse-nios2
(5a) To get this to run on Ubuntu 15.04, I had to install the 32-bit JRE and a bunch of 32-bit libs.
(5b) Create a workspace wherever you see fit

(7) Import the lms_spi_controller and lms_spi_controller_bsp projects:
(7a) From the project explorer, right click and select Import...
(7b) "Existing projects into Workspace"
(7c) Select Root Directory
(7d) Select that "software/" directory from step 4. You should see both projects checked in in the "Projects" pane. Click Finish.

(8) You should now have both projects in Eclipse. Clean and build should work. Note that the eclipse editor won't know how to resolve macros and functions unless you configure this in the project settings to inform it of paths to search for source files and headers (i.e., the BSP and the gcc toolchain shipped with the Altera package).

(9) Load the FPGA via the bladeRF-cli. This ensures everything gets configured before we attach to the NIOS II target. We can reset and reload the NIOS after this.

(10) Connect the JTAG debugger. This assumes you're using an Altera or Terasic Blaster, and have already set up your udev rules to have access to it.

(11) Create a debug target.
(11a) Debug Configurations..
(11b) Create a new "NIOS II Hardware v2 (beta)" target
(11d) Project: lms_spi_controller
(11e) ELF file: lms_spi_controller.elf
(11f) Under Connections -> Processor, click Browse... It should detect the NIOS II via the USB-Blaster
(11g) Under Connections->JTAG UART, click Browse... Again, it should detect the NIOS II via the USB-Blaster
(11h) Uncheck "Check Unique ID" and "Check timestamp"
(11i) Here you can make a choice. Generally, I duplicate the debug configuration, and do one for attaching and one for loading and resetting:
(11i-1) If you only want to attach to the target, uncheck "Download ELF", "Reset Processor" and "Start Processor".
(11i-2) If you want to download your changes to the NIOS II code and restart it, leave all of these checked.

(12) Here's what my setup looks like at this point:
Debug_config.png
(13) From here, I'm able to launch the debug target and step through code:
debug.png
Don't be alarmed by Eclipse claiming every macro and type it can't resolve to be a "bug". If this bothers you, you can set up the source and header search paths for the project. (Since the project uses a Makefile, Eclipse doesn't know where to look -- it just launches make.)

(14) Now if you start setting break points, the host code will time out. You can disable timeouts the USB requests that go to the nios by changing this line from 250 to 0.


Again, check back in a couple weeks, or take a peek my dev-nios_refactor branch... I think you'll find the overhaul to make a lot more sense and help you pull what you need from the lms.c and si5338.c files.

Best regards,
Jon
erik
Posts: 17
Joined: Mon May 18, 2015 12:35 am

Re: What about the Nios2?

Post by erik »

Wow thank you very much this is great.

This will be realy helpfull. But at first I have to order a new byteblaster my old one is the "byteblaster" not "byteblaster II" and it is not support by quartus 2.
I will try the one you mentioned (Terasic Blaster) the Altera is too expensive.

Is there a way to load the code to the nios2 without byteblaster?
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: What about the Nios2?

Post by jynik »

This is the Terasic Blaster I use.

If you look for "Cyclone IV JTAG programmer" on Ebay you'll find kits that come with sketchy JTAG devices. I've tried these, and you definitely seem to get what you pay for... It's not worth the headache.

The only way to load code onto the NIOS II is by baking it into the FPGA (i.e., running that build_bladerf.sh build script). That'll get your NIOS II running, but you won't have any insight into why something isn't working.

Cheers,
Jon
erik
Posts: 17
Joined: Mon May 18, 2015 12:35 am

Re: What about the Nios2?

Post by erik »

I belive the eBay programmer is good for nothing. Will geht the terasic blaster.

THX for your help.
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: What about the Nios2?

Post by jynik »

I bought one of the Cyclone IV kits on Ebay that came with a really sketchy "Altera" programmer. I could feel the PCB in the programmer bouncing around loosely and it felt like it was going to break if I dropped it.

At the time I had tried it, the debug session seemed very fragile. The device would just go out to lunch pretty constantly.

So tl;dr - Good choice on the Terasic blaster. The $50 is worth saving yourself the headache you'd get with some of the garbage on Ebay.
erik
Posts: 17
Joined: Mon May 18, 2015 12:35 am

Re: What about the Nios2?

Post by erik »

Hello,

I have an additional question.
Is there a list of the commands the nios is receiving?

I try to implement somewhat like the cli but in the nios.
So I think i only have to know the uart commands to the corresponding commands of the cli.
I could get the commands by debugging and try every cli command but maybe there is allready a list.

Greetings,

Erik
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: What about the Nios2?

Post by jynik »

Hi Erik,

The current NIOS implementation receives and responds with a 16-byte word:

Code: Select all

0: Magic byte 'N'
1: Mode
     bit [7] Read operation
     bit [6]: Write operation
     bit [5:4] Device specifier
          00 = Config I/O between the NIOS II and the programmable fabric
          01 = LMS6002D register access
          10 = VCTCXO trim DAC register access
          11 = SI5338 register access
    bits[3:0]  Payload count
bytes[2-15]: Address/Data pairs.
As I mentioned earlier, I'm right in the middle of re-writing the NIOS code to improve readability and add new functionality. As such, I think it makes more sense to point you to the upcoming code, rather than familiarize with the older code.

So far, it's going really great, and we are adding functionality to improve the speed of commands, as well as provide the ability to schedule fast re-tune operations (synchronized with the timestamp counters). I'm personally very happy with the speedup results, and looking forward to improving them even further.

In doing this, I'm trying to ensure the source files are much better documented, especially the UART command formats. We will continue to support the current format, which we will call the NIOS Legacy Packet format.

This code is being worked on in this dev-nios_refactor branch, on my GitHub account. Once it's cleaned up, it will be brought into the Nuand repo.

Because this development branch is transient, I'm also attaching a .tar.bz2 of the dev repo, as to ensure this forum post contains the info in the future, when the branch is gone.

In this new code, you will find the following differences in paths:
  • The NIOS code has been moved from the "lms_spi_controller" project to a more appropriately named "bladeRF_nios" project.
  • There is a top-level fpga_common directory now
    • Command formats are specified here, as both the host code and NIOS need to know this information
    • LMS6002 code has been move here, allowing us to run a subset of the retune operation on the NIOS II. Note that we only build certain functions in the NIOS code, but you should be able to enable/disable what you want.
  • The architecture has been redesigned such that you can now have different "Packet handlers" and custom packet formats for your programmable logic. The legacy packet format works as it has in the past. You can see an example of a new format in the retune packet format, which utilizes the notion of a packet handler having deferred work
erik
Posts: 17
Joined: Mon May 18, 2015 12:35 am

Re: What about the Nios2?

Post by erik »

Thank you for your request.

I had a look to your branch some days ago but I wasnt sure if I can use the code I this state. Yesterday my byteblaster is arrived. I will install it now and than take a further peek to your branch and test the new development.
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: What about the Nios2?

Post by jynik »

Hi Erik,

What I posted is now functional. Currently, it requires some cleanup and some additional error checking.

If nothing else, I think that code is a little bit cleaner, which will allow you more quickly understand how to write code for and debug the NIOS II.

Please note that the libbladeRF, NIOS code and FPGA HDL are all updated. You will need to build the FPGA (v0.2.0) to use that branch. The updated FPGA includes an interrupt-based command UART, and the time tamer have been separated into an RX and TX time tamer, each with programmable interrupts.

Best regards,
Jon
erik
Posts: 17
Joined: Mon May 18, 2015 12:35 am

Re: What about the Nios2?

Post by erik »

Hello,

I have a problem with the new code. I cant run the build_bladerf.sh skript. Becaus of that:

2015.06.08.16:31:00 Info: No custom instruction connections, skipping transform
Exception in thread "main" java.lang.NullPointerException
at com.altera.sopcmodel.transforms.avalon.Domain.getSymmetryCheckerForPoint(Domain.java:308)
at com.altera.sopcmodel.transforms.avalon.Domain.isSymmetric(Domain.java:284)
at com.altera.sopcmodel.transforms.avalon.InitialInterconnectTransform.checkValidDomain(InitialInterconnectTransform.java:108)
at com.altera.sopcmodel.transforms.avalon.InitialInterconnectTransform.doExecute(InitialInterconnectTransform.java:83)
at com.altera.sopcmodel.transforms.SopcTransformStep.execute(SopcTransformStep.java:66)
at com.altera.sopcmodel.transforms.SopcTransformList.doExecute(SopcTransformList.java:112)
at com.altera.sopcmodel.transforms.SopcTransformStep.execute(SopcTransformStep.java:66)
at com.altera.sopcmodel.transforms.mm.MMTransform.doExecute(MMTransform.java:112)
at com.altera.sopcmodel.transforms.SopcTransformStep.execute(SopcTransformStep.java:66)
at com.altera.sopcmodel.transforms.SopcTransformList.doExecute(SopcTransformList.java:112)
at com.altera.sopcmodel.transforms.SopcTransformStep.execute(SopcTransformStep.java:66)
at com.altera.sopcmodel.transforms.avalon.AvalonTransform.doExecute(AvalonTransform.java:48)
at com.altera.sopcmodel.transforms.SopcTransformStep.execute(SopcTransformStep.java:66)
at com.altera.sopcmodel.ensemble.EnsembleUtils.doTransform(EnsembleUtils.java:1332)
at com.altera.sopc.generator.EnsembleGenerationFileSet2.attemptTransform(EnsembleGenerationFileSet2.java:90)
at com.altera.sopc.generator.EnsembleGenerationFileSet2.generate(EnsembleGenerationFileSet2.java:51)
at com.altera.sopc.generator.FileSet2.generate(FileSet2.java:134)
at com.altera.sopc.generator.Sellafield.generate(Sellafield.java:381)
at com.altera.sopcmodel.sbtools.sbgenerate.SbGenerate.act(SbGenerate.java:622)
at com.altera.utilities.AltCmdLineToolBase.runTheTool(AltCmdLineToolBase.java:640)
at com.altera.sopcmodel.sbtools.sbgenerate.SbGenerate.main(SbGenerate.java:1106)

In an older version of your branch maybe from within the last 3 weeks I can run the skript but not run the cli after loading the image because of that:

adminhtw@adminrechner:~$ bladeRF-cli -i -v verbose
[VERBOSE @ libusb.c:515] Using libusb version: 1.0.17.10830
[VERBOSE @ libusb.c:406] Found a bladeRF (idx=0)
[VERBOSE @ libusb.c:458] USB port reset succeeded for bladeRF adcb3b86c8749988eefcf733b81c1912
[VERBOSE @ usb.c:284] Changing to USB alt setting 0
[VERBOSE @ usb.c:284] Changing to USB alt setting 1
[DEBUG @ usb.c:201] Failed to read FPGA version[0]: Operation timed out
Failed to open device (first available): Operation timed out

Is there a way to solve one of these problems.

Thank you

Erik


edit:

The second failure i mentioned is not because of the new code.
It also is present with old versions. When you had attached the usb blaster and had a debug session you are not able to launch the cli after that.

So it seams that it is not possible to load the code to the nios using the usb blaster and than use the cli to check the configs which are done by the nios code.
I have to run the build_bladerf.sh skript every time.

Further there is an error because of the new fpga version.:

[INFO @ version_compat.c:110] FPGA version (v0.2.0) is newer than entries in libbladeRF's compatibility table. Please update libbladeRF if problems arise.
Failed to open device (first available): Operation timed out

How i can update the libbladeRF by myself?

THX Erik
Post Reply