Unable to load DLL 'nuttx'

Meadow Development
1

Hi,

I’ve just upgraded my Meadow Board to MeadowOS Version: 0.4.0 (Sep 19 2020 14:37:21) and now if I create a vanilla application (or try and run any of the samples, using the 0.18 package versions), I get the following exception:

    Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: The type initializer for 'Meadow.Devices.UPD' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'nuttx': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
at Meadow.Core.Interop.Nuttx.open(String pathname, DriverFlags flags)
at Meadow.Devices.UPD..cctor()
--- End of inner exception stack trace ---
at Meadow.Devices.UPD.SetRegister(UInt32 address, UInt32 value)
at Meadow.Devices.F7GPIOManager.ConfigureGpio(GpioPort port, Int32 pin, GpioMode mode, ResistorMode resistor, GPIOSpeed speed, OutputType type, Boolean initialState, InterruptMode interruptMode, Int32 alternateFunctionNumber, Double debounceDuration, Double glitchDuration)
at Meadow.Devices.F7GPIOManager.Initialize()
at Meadow.Devices.F7Micro..ctor()
--- End of inner exception stack trace ---
at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
at System.Activator.CreateInstance[T]()
at Meadow.App`2.get_Device()
at McpLeds.MeadowApp..ctor()

Any ideas?

2

Hi Howard,

Have you figured out the problem? My current dev stack is:

  • Visual Studio 16.7.6
  • VS Tools for Meadow 0.12.12
  • Meadow.OS 0.4.0
  • Meadow.Foundation 0.19.0

You mentioned you’re using 0.18 package versions. Make sure to match my version stack, and try again. If you do a file-> new project, please make sure the Meadow.Foundation package is up-to-date.

3

Hi,

I realise (from spotting a comment on another post) that the default F5 behaviour is to deploy the application to the device AND to launch the .exe locally and it’s the local instance that generates the nuttx runtime error - which is obvious when you realise it, but it would be nice if this was called out in the getting started documentation (or figure out a way to deploy via F5 and not to run the .exe locally).

I have spent the last two days trying to get an app running and yesterday, did try the toolchain you mention above, but have been seeing the following two issues:


The only combination that I’ve found to work are:

  • Visual Studio 16.7.6
  • VS Tools for Meadow 0.11.1
  • Meadow.OS 0.4.0
  • Meadow.Foundation 0.18.0
4

Hi Howard,

We took a closer look at the extension, and we pushed an update with a small fix that should unblock you from deploying apps to your board. See if you get the update, latest version of the extension is now 0.12.3, and give that a try, we’re getting reports that the update fixed the Mono.Cecil problem.

Thanks,
Jorge

5

I just tried the HelloWorld app… got the same error:

Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.TypeInitializationException: The type initializer for ‘Meadow.Devices.UPD’ threw an exception. —> System.DllNotFoundException: Unable to load DLL ‘nuttx’: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
at Meadow.Core.Interop.Nuttx.open(String pathname, DriverFlags flags)
at Meadow.Devices.UPD…cctor()
— End of inner exception stack trace —
at Meadow.Devices.UPD.SetRegister(UInt32 address, UInt32 value)
at Meadow.Devices.F7GPIOManager.ConfigureGpio(GpioPort port, Int32 pin, GpioMode mode, ResistorMode resistor, GPIOSpeed speed, OutputType type, Boolean initialState, InterruptMode interruptMode, Int32 alternateFunctionNumber, Double debounceDuration, Double glitchDuration)
at Meadow.Devices.F7GPIOManager.Initialize()
at Meadow.Devices.F7Micro…ctor()
— End of inner exception stack trace —
at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
at System.Activator.CreateInstanceT
at Meadow.App`2.get_Device()
at HelloMeadow.MeadowApp.Initialize() in C:\Users\rchiverton\source\repos\HelloMeadow\MeadowApp.cs:line 24
at HelloMeadow.MeadowApp…ctor() in C:\Users\rchiverton\source\repos\HelloMeadow\MeadowApp.cs:line 16
at HelloMeadow.Program.Main(String[] args) in C:\Users\rchiverton\source\repos\HelloMeadow\Program.cs:line 14

using:
Windows 10
VS 2019
VS Tools for Meadow (preview) version 0.13.1
Meadow OS 0.4.4
Meadow Foundation 0.22.0

ok… what’s the fix?

(also… I had to comment this:

public static void Main(string[] args)
{
//if (args.Length > 0 && args[0] == “–exitOnDebug”) return;

    }

Can someone explain what this line is for? By default, the --exitOnDebug argument is present, and the app immediately exits (hence why I needed to comment it out).

6

Hi Robert!

That line is to prevent the application from running on Windows. If you attempt to run on Windows you get the error you are seeing. Pressing F5 will cause Visual Studio to deploy the App onto the connected Meadow, and then attempt to execute the application on Windows. Since we don’t yet support debugging of Meadow Apps in Visual Studio, we need this line to prevent misleading errors.

Once the application is deployed to the Meadow, it will automatically start on the Meadow.

If you have any other questions, please don’t hesitate to ask.

-Pete

1 Like