Ouch, it appears you've got much more going on than "it's falling back to Safe Mode." Apparently Logos (our communication protocol workhorse) doesn't like not having a NIC, because it seems to be implicated as the module crashing on boot - this is why the system is falling back to Safe Mode, thus Safe Mode is definitely not "intended or expected behavior." On your target there is likely a file called, "rtlog.txt" in the /ni-rt/system directory - can you find this file and attach it? The log file you provided is "tainted" between printing the crash information and normal startup information, it's hard to partition the crash details from the startup info. The rtlog.txt would exclusively have the crash info and would be very helpful.
I'll begin the process of getting my hands on a cFP-2220 and have the owner of Logos take a look at this, maybe we can figure out what's wrong and possibly get you something that will work.
Could you also possibly include a MAX technical report for the controller showing the software installed?
Okay, we've reproduced the problem in-house, and we've got a developer looking into why the crash is happening. Hopefully we can get to the bottom of what's going on and maybe provide some kind of a workaround for you. I do not have an ETA, but I wanted to let you know it's being looked into.
Any news on this issue? Have the people looking into it found anything promising and/or have an idea of the way forward?
This issue is being tracked by Corrective Action Request ID 349598. The change is on track to be included in the next release of the FieldPoint driver, but that is subject to change. Is solution delivered this summer acceptable?
Has this been resolved now?
We've run into another issue where the controller refuses to start the software. This time it has DHCP contact and launches the application once, but when this application tries to reconfigure the IP and do another restart it ends up in a software error state. The hunt so far seems to link the problem with a temp file possibly created by the System Configuration API.
Under ni-rt/system/ethernet there is normally just a single file; netconf.ini. Hower, on the device that kept crashing there was a tmp file as well. It could be accidental, but we did lots of other trials that failed until we deleted that file. Since then it has worked fine.
I'm speculating (on a very thin basis...) that the system uses a temp file during reconfigurations, and that something (power failure?) caused this temp file to remain. Then there is a bug that prevents new reconfigurations to succeed because the temp fiel blocks creation of a new one...Could that be the case?
I've attached the crash log here. (This might fit better in a separate thread, or not...I'm trying to get the attention of you gurus so perhaps this thread is the most effective one ;-) ).
The mystical temp file was named ini$$0.TMP, and contained the same as the netconf.ini file, but with different values.
As mentioned the software would crash as long as this file was present.
We are investigating this issue and will post back with more updates.
Product Support Engineer