Secondary network interface dead on two cards...

[Mads]

I'm dealing with a bit of a mystery here; I have two SOM developer kits which will not connect on their secondary network interfaces anymore.

Both of the cards have been away to be placed into a box, so the culprit might be in that process, but I cannot understand what could trigger it.The last card was just screwed onto a plate, hooked up to a set of connectors and that's it. Now the interface is dead. Both interfaces show up as activated and using DHCP in NI MAX, but the secondary interface has no connectivity. Its speed light does not turn on when plugged in.

What can cause this to happen, repeatedly...I'm hoping I'm just overlooking something really basic...Grasping at straws here...

[Spex]

Mads,

The most obvious cause for this behaviour would be lack of a programmed bitfile with secondary Ethernet support enabled.  The secondary Ethernet port is routed through the FPGA fabric, and you must explicity load a bitfile with the CLIP configured for secondary Ethernet support for that port to be 'live'. 

The bitfile with seconday Ethernet support must be configured to load on power up, ie downloaded to Flash of the SOM, and the SOM should be powered on/reset with that bitfile downloaded.

Regards,

spex

[Mads]

Ok...this is the development kit, and I have not downloaded any bitfiles, it's all as it was out of the box. And it worked earlier.

But I did upgrade from LV 2014 to LabVIEW 2014 SP1 the other day, and on one of the cards I upgraded the firmware...

[Spex]

Hi Mads,

When the development kit is brought out of the box, it has no bitfile loaded.  Unless an application is deployed with an enabled bitfile, the secondary port is non-functional out of the box. 

The RT application (if it includes an Open FPGA Reference function) may automatically load a bitfile when it is run.  Is it possible that when it worked earlier your application had loaded an FPGA bitfile with Ethernet support enabled?

Alternatively, you can use the project to download a bitfile with secondary Enet capability to the flash memory so the bitfile with Enet support loads automatically on power on.

As a test, can you open the example project for the development kit, compile the FPGA VI into a bitfile, run it, and then determine if the secondary Ethernet ports are functional?

-spex

[Mads]

That worked...I'm not sure how I got things to work previously then. I see from the documentation that it will load a default bitfile, but that one does not have the secondary interface enabled, not even when the correct CLIP file (dev board) is selected?

For a project that does not have any VIs to run on the FPGA, do I need to make a dummy one just to get the right bitfile on the FPGA?

[Spex]

Yep, dummy VI is required to enable secondary Ethernet if no other FPGA VI is needed. In that case, I would open the Dev Kit example project or add the DevKit CLIP to your existing project, then create a new blank VI on the FPGA and compile it.  That blank VI will use the CLIP with seconday Ethernet enabled.

What is important to understand that selecting a CLIP in the project doesn't immediately configure anything on the SOM target.  The CLIP code and configuration is compiled into the FPGA VI bitfile, and only when that bitfile is deployed are the CLIP settings active on the target. 

We set up the SOM this way to ensure that customers who didn't need secondary Ethernet can reclaim the FPGA space for other tasks, and if the SOM was transferred to another carrier that didn't have secondary Ethernet live and driving lines accidentally into an unknown carrier.

-spex