Deployment Completed with Errors on sbRIO-9651 using LabVIEW 2017 SP1

[jam92]

It did in fact turn out to be a hardware related issue. We populated a new custom board and were able to successfully deploy and run our LabVIEW application on the RIO.

We'd obviously like to avoid any hardware issues like this in the future. At the moment we're not sure what exactly in the hardware was causing the problem. Does anyone have any recommendations for using the SOM to determine where the hardware problem is? Can we get any sort of self-check data? Is there a means of determine which pins are interacting with faulty hardware causing the restarts? Any more information would be sincerely appreciated.

Sincerely,

Alex M.

[Aryk]

Hi Alex,

I am currently going through the same process, I'm having a code that is working perfectly on the NI sbRIO DevKit hardware and we purchased a Cyth CFX-318 that same code doesn't deploy correctly and this issue is linked to the FPGA VIs, sometimes it works, sometimes it doesn't. The issue is very strange.

I've found a way of solving the deployment issue, my FPGA was wrapped in a In-Place Structure Node and couldn't load while removing solved the deployment issue.
Then my target crashed when the Open FPGA VI was called, this seems to be link with FPGA interaction resulting in this in the error log:

Spoiler

####
#Date: Wed, May 02, 2018 01:48:47 PM
#OSName: Linux
#OSVers: 4.6.7-rt14-ni-5.2.0f0
#OSBuild: 263687
#AppName: lvrt
#Version: 17.0
#AppKind: AppLib
#AppModDate:


InitExecSystem() call to GetCurrProcessNumProcessors() reports: 2 processors
InitExecSystem() call to GetNumProcessors()            reports: 2 processors
InitExecSystem()                                      will use: 2 processors

After rebooting the target and trying to redeploy, I'm back to the first issue where the code won't deploy

This seems to me that the problem is linked to both software and hardware or maybe a configuration file somewhere on the target or linked to deployed code

Can someone help on this issue?

[Aryk]

After doing some more test it has nothing to do with the In-Place node, modifying the VI, recompiling it and saving again is the trigger to allow the deployment. I've noticed that an FPGA VI that have issue deploying will lead to a crash when the sbRIO Open VI is called

[algarcia]

Hi Aryk,

As previously mentioned, if your code is working on a stock sbRIO and daughter card, then it is likely a hardware issue with the custom daughter card.

[Aryk]

Hi Alex G,

The CarrierBoard is from NI recommended source. I've noticed something, the issue seems to be only appearing when the Ethernet cable is connected, this issue doesn't happen when the code is deployed via WiFi only. I'm wondering if this could be related to a bad pin voltage when deploying via ethernet.
This morning our electronic designer that is designing a new carrier board for us, told us about spotting a potential pin inversion mistake with SD Card on the Carrier Design Guide. I'm wondering if those are not linked together, I think it is worth for NI to investigate this issue further.

[algarcia]

Aryk,

Which page specifically in the Carrier Design Guide are you referencing, and which pin?

Additionally which ethernet port is causing this issue?

[Aryk]

Hi Alex,

I've contacted our designer, waiting for them to come back
Its the main Ethernet ETH0, when plug the deployment will fail, and if the deployment doesn't fail, then the FPGA Load VI will crash the target.
When ETH0 is not connected everything works out fine

I've also notified NI to pass the information along to the sbRIO Team, as we are spending a lot of resource building custom boards, we want to make sure that we won't hit any rocks on the finished product

[algarcia]

Hi Aryk,

You mentioned that it worked on the DevKit hardware, but it isn't working on the Cyth CFX-318 board?

Have you tried reaching out to Cyth? What was their response to this? It seems strange that we're able to successfully deploy to the DevKit board, this makes me think that it is dependent on the Cyth board. What are your thoughts on this?

[Aryk]

Hi Alex,

It is a very weird problem. I don't know if the Cyth board is at fault, I doubt it.

Spoke with Cyth about this issue and with NI support, they suggested something was wrong with the sbRIO which is not the case. It is not a consistent issue, which lead me to think that this problem arise related to electronics and wiring. Its difficult to say given the randomness nature of this problem, it comes and go.

To get to the bottom of this, we would need to understand how the NI software interact with the RT target when it deploys the FPGA and how many current does it pulls through certain pins. I'm currently questioning whether or not we could have a bad ground isolation causing of a pin failures during deploy?

[algarcia]

Hi Aryk,

R&D looked into the possible pin inversion issue and everything appears to be correct and consistent in the design guide and actual hardware schematic of the device. I would advise double checking the grounding as you mentioned that could be causing problems.

As it currently stands, the FPGA is able to successfully run code with the DevKit Board, but we're only seeing these issue with the other board, correct? Based off of this information, I would suspect that the other board is at fault currently; that's what the previous user found in this forum. Additionally, since this is a 3rd party board, our knowledge and support is somewhat limited as we don't know all of the intricacies of the device.