16 replies to this topic

[mutsop]

Hi, After some successful tests with an LCD I was about to try netmftoolbox for my keypad. So I downloaded the files and used the samples. I connected everything, set the device to netduinoplus and pressed "Start Debugging". It starts to debug and then suddenly stops (and the play button is available again) but I don't get any runtime errors. The only thing I do see (in the status update) is the following message: "The debugging target is not in an initialized state, rebooting...". I'm not sure if it said the same thing the first time I've done this. But I do remember the debugging not stopping suddenly without me pressing the stop icon. Any ideas? As I'm really not in the mood to give up this wonderful hobby.

[ErikN]

You should check the Output Window to see if there are any errors or messages that would indicate what's happening. Does your main function sleep or does it terminate as soon as you finish your commands? It's possible the calls to the library aren't blocking and you exit your main function (and debugging stops) before the library has had a chance to do any work on its thread(s). -Erik

[mutsop]

This is my whole output:

Rebooting...


TinyCLR (Build 4.1.2821.0)


Starting...

Found debugger!

Create TS.

 Loading start at 14d324, end 162e8c

Attaching file.

Assembly: mscorlib (4.1.2821.0) (3880 RAM - 33236 ROM - 19134 METADATA)


Attaching file.

Assembly: Microsoft.SPOT.Native (4.1.2821.0) (1144 RAM - 6516 ROM - 4479 METADATA)


Attaching file.

Assembly: Microsoft.SPOT.Hardware (4.1.2821.0) (1752 RAM - 11440 ROM - 7371 METADATA)


Attaching file.

Assembly: Microsoft.SPOT.Net (4.1.2821.0) (704 RAM - 5060 ROM - 2452 METADATA)


Attaching file.

Assembly: System (4.1.2821.0) (872 RAM - 5992 ROM - 3206 METADATA)


Attaching file.

Assembly: Microsoft.SPOT.IO (4.1.2821.0) (740 RAM - 4620 ROM - 2522 METADATA)


Attaching file.

Assembly: System.IO (4.1.2821.0) (1548 RAM - 13292 ROM - 5862 METADATA)


Attaching file.

Assembly: Microsoft.SPOT.Hardware.SerialPort (4.1.2821.0) (512 RAM - 3488 ROM - 1543 METADATA)


Attaching file.

Assembly: Microsoft.SPOT.Hardware.Usb (4.1.2821.0) (580 RAM - 3740 ROM - 1844 METADATA)


Attaching file.

Assembly: SecretLabs.NETMF.Hardware (4.1.0.0) (256 RAM - 1108 ROM - 491 METADATA)


Attaching file.

Assembly: SecretLabs.NETMF.Diagnostics (4.1.0.0) (180 RAM - 440 ROM - 166 METADATA)


Loading Deployment Assemblies.

Attaching deployed file.

Assembly: Toolbox.NETMF.Hardware (1.0.0.0) (1692 RAM - 17824 ROM - 6774 METADATA)


Attaching deployed file.

Assembly: Toolbox.NETMF (0.1.0.0) (244 RAM - 1468 ROM - 435 METADATA)


Attaching deployed file.

Assembly: SecretLabs.NETMF.Hardware.NetduinoPlus (4.1.0.0) (268 RAM - 816 ROM - 423 METADATA)


Attaching deployed file.

Assembly: NetduinoPlusApplication2 (1.0.0.0) (264 RAM - 784 ROM - 383 METADATA)


Resolving.

Link failure: some assembly references cannot be resolved!!


Assembly: Toolbox.NETMF.Hardware (1.0.0.0) needs assembly 'mscorlib' (4.2.0.0)

Assembly: Toolbox.NETMF.Hardware (1.0.0.0) needs assembly 'Microsoft.SPOT.Hardware' (4.2.0.0)

Assembly: Toolbox.NETMF.Hardware (1.0.0.0) needs assembly 'Microsoft.SPOT.Native' (4.2.0.0)

Assembly: Toolbox.NETMF.Hardware (1.0.0.0) needs assembly 'SecretLabs.NETMF.Hardware' (4.2.0.0)

Assembly: Toolbox.NETMF.Hardware (1.0.0.0) needs assembly 'Microsoft.SPOT.Hardware.SerialPort' (4.2.0.0)

Assembly: Toolbox.NETMF.Hardware (1.0.0.0) needs assembly 'Toolbox.NETMF' (0.1.0.0)

Assembly: Toolbox.NETMF (0.1.0.0) needs assembly 'mscorlib' (4.2.0.0)

Assembly: NetduinoPlusApplication2 (1.0.0.0) needs assembly 'Toolbox.NETMF.Hardware' (1.0.0.0)

Assembly: NetduinoPlusApplication2 (1.0.0.0) needs assembly 'Microsoft.SPOT.Hardware' (4.2.0.0)

Error: a3000000

Waiting for debug commands...

So it does seem there are a few issues.

[ErikN]

Assembly: Toolbox.NETMF.Hardware (1.0.0.0) needs assembly 'mscorlib' (4.2.0.0)

Assembly: Toolbox.NETMF.Hardware (1.0.0.0) needs assembly 'Microsoft.SPOT.Hardware' (4.2.0.0)

Assembly: Toolbox.NETMF.Hardware (1.0.0.0) needs assembly 'Microsoft.SPOT.Native' (4.2.0.0)

Assembly: Toolbox.NETMF.Hardware (1.0.0.0) needs assembly 'SecretLabs.NETMF.Hardware' (4.2.0.0)

Assembly: Toolbox.NETMF.Hardware (1.0.0.0) needs assembly 'Microsoft.SPOT.Hardware.SerialPort' (4.2.0.0)

Assembly: Toolbox.NETMF.Hardware (1.0.0.0) needs assembly 'Toolbox.NETMF' (0.1.0.0)

Assembly: Toolbox.NETMF (0.1.0.0) needs assembly 'mscorlib' (4.2.0.0)

Assembly: NetduinoPlusApplication2 (1.0.0.0) needs assembly 'Toolbox.NETMF.Hardware' (1.0.0.0)

Assembly: NetduinoPlusApplication2 (1.0.0.0) needs assembly 'Microsoft.SPOT.Hardware' (4.2.0.0)

Error: a3000000

Looks like you're using a version of the Toolbox.NETMF that's meant for .NET MicroFramework 4.2 but the libraries you are using are for NETMF 4.1. You will need to either get a version of the toolbox compiled for 4.1 or you'll need to flash your board with the 4.2 Release Candidate firmware, install the .NET Micro Framework 4.2 SDK and change the build target of your project to 4.2.-Erik

[mutsop]

K I'll try that... But to be sure I opened up a new project and tried debugging that which gave me:

Rebooting...


TinyCLR (Build 4.1.2821.0)


Starting...

Found debugger!

Create TS.

 Loading start at 14d324, end 162e8c

Attaching file.

Assembly: mscorlib (4.1.2821.0) (3880 RAM - 33236 ROM - 19134 METADATA)


Attaching file.

Assembly: Microsoft.SPOT.Native (4.1.2821.0) (1144 RAM - 6516 ROM - 4479 METADATA)


Attaching file.

Assembly: Microsoft.SPOT.Hardware (4.1.2821.0) (1752 RAM - 11440 ROM - 7371 METADATA)


Attaching file.

Assembly: Microsoft.SPOT.Net (4.1.2821.0) (704 RAM - 5060 ROM - 2452 METADATA)


Attaching file.

Assembly: System (4.1.2821.0) (872 RAM - 5992 ROM - 3206 METADATA)


Attaching file.

Assembly: Microsoft.SPOT.IO (4.1.2821.0) (740 RAM - 4620 ROM - 2522 METADATA)


Attaching file.

Assembly: System.IO (4.1.2821.0) (1548 RAM - 13292 ROM - 5862 METADATA)


Attaching file.

Assembly: Microsoft.SPOT.Hardware.SerialPort (4.1.2821.0) (512 RAM - 3488 ROM - 1543 METADATA)


Attaching file.

Assembly: Microsoft.SPOT.Hardware.Usb (4.1.2821.0) (580 RAM - 3740 ROM - 1844 METADATA)


Attaching file.

Assembly: SecretLabs.NETMF.Hardware (4.1.0.0) (256 RAM - 1108 ROM - 491 METADATA)


Attaching file.

Assembly: SecretLabs.NETMF.Diagnostics (4.1.0.0) (180 RAM - 440 ROM - 166 METADATA)


Loading Deployment Assemblies.

Attaching deployed file.

Assembly: NetduinoPlusApplication1 (1.0.0.0) (164 RAM - 264 ROM - 90 METADATA)


Attaching deployed file.

Assembly: SecretLabs.NETMF.Hardware.NetduinoPlus (4.1.0.0) (268 RAM - 816 ROM - 423 METADATA)


Resolving.


Total: (10920 RAM - 90012 ROM - 49583 METADATA)



Total: (10920 RAM - 90012 ROM - 49583 METADATA)


The debugging target runtime is loading the application assemblies and starting execution.
Ready.

Done.

Waiting for debug commands...

So no errors are found but I still have the same problem.

[ErikN]

I don't have a set up in front of me to be sure but now it looks like your program ran and terminated without error.
Can you post your main method? I have a feeling it's not going into a message loop or going to sleep.

Coincidentally the organizer of the project you were using (as well as many (all?) of its contributors) are members in this forum.
http://forums.netdui...er/3331-stefan/

I noticed the project doesn't have easily-consumed DLLs for you. It looks like you need to download the source and compile it yourself. More likely the intention is for you to pick and choose only the things you need so you don't end up with a very large DLL containing classes for which you have no need. The license is Apache 2 which is very permissive so this very action is allowed (if I've understood the license correctly) and indeed Stefan's comments seem to indicate the nature of the project is to be as open-source as possible.

It does mean there's a bit more up-front work for you though in order to get the pieces you want into your project.

-Erik

[mutsop]

Well this is my project

namespace NetduinoPlusApplication1
{
    public class Program
    {
        public static void Main()
        {
            // write your code here


        }

    }
}

So nothing... There seems to be an external error of some kind. I hope it's not my netduino+ itself

[ErikN]

No, this is exactly as expected. The program deployed to your Netduino, the program executes (does nothing) and exits.

Without instruction, what do you expect should happen?

If you want your program to continue forever, you will need to keep from exiting your Main function. Most of what I see is something like:

public static void Main()
{
   while (true)
   {
      System.Threading.Thread.Sleep(1000);
   }
}

The above code is out of my memory, not from looking at something specific so I might have gotten a namespace wrong there. The point is, this will cause your Main thread to sleep for 1 second, start the loop over which causes the thread to sleep for 1 second again, ad infinitum. The reason a sleep state is used is just to keep the power consumption low if no other work is being done. It's better than just doing while(true) { }.

Now to do some actual work, you'll need to either instantiate some objects, start some event listeners, etc. before falling into your infinite sleep loop, or change the code up to loop over a set of polling instructions.

The bottom line is, when your Main method has finished executing all its instructions, your program terminates regardless of what other events were pending. What you're seeing in your debugger is exactly what is expected. You click play, the program is deployed, execution starts, your 0 instructions are executed and the program terminates showing you the green arrow to start the run over again.

Hope this helps,
-Erik

[Bainesbunch]

public static void Main()
{
   while (true)
   {
      System.Threading.Thread.Sleep(1000);
   }
}

This is interesting then what happens if you create and instantiate a new thread. Do all threads terminate when the main loop exits ?

Should you terminate any threads you create after exiting the main loop before the application exits.

Cheers Pete.

[ErikN]

It is my understanding that everything will terminate when the main thread exits. That's why you need to keep it alive for the lifetime of your application run. That's not to say it has to DO anything. Like I said, it can sleep the whole time and not take up any execution time. In this case, all the work would be done using other threads and events. This approach of event-based programming means your system might go into low power mode because there is nothing that needs attention right at this second. As soon as some interrupt or event is fired, the system will process the instructions then fall back to sleep. This contrasts with the design of having a single thread that just loops instructions forever. In this case, unless you insert sleep states, you will be using power checking for changes rather than waiting for them to occur and run down your battery very quickly. -Erik

[mutsop]

Offcourse, rookie mistake Yes so when a thread is kept alive it keeps going. I'll look into the netMF toolbox for 4.1 as to my previous problem its seems though the 4.1 isn't available anymore... So I guess I'll be upgrading my netduino. But is that failsafe? Is tehre a well instructioned article on that?

[ErikN]

The 4.2 firmware is not yet "release" and there are still a number of known issues. Right now 4.1 is still the recommended version unless you need a feature that is only available in 4.2 version like using Visual Basic programming language.

The code for the tools mentioned per your previous problem is available on CodePlex. You could just download the source and drop the needed files in your project directly. This will compile the source with the version you're using and ensure your project is no larger than it needs to be.

You could post to the CodePlex project and ask why the 4.1 version doesn't appear to be available if that's really the problem.

Good luck and happy coding!

-Erik

[mutsop]

Oke everything works thanks alot!

[ErikN]

Awesome! Now for the fun part...creating!

[Bainesbunch]

It is my understanding that everything will terminate when the main thread exits. That's why you need to keep it alive for the lifetime of your application run.

That's not to say it has to DO anything. Like I said, it can sleep the whole time and not take up any execution time. In this case, all the work would be done using other threads and events. This approach of event-based programming means your system might go into low power mode because there is nothing that needs attention right at this second. As soon as some interrupt or event is fired, the system will process the instructions then fall back to sleep.

This contrasts with the design of having a single thread that just loops instructions forever. In this case, unless you insert sleep states, you will be using power checking for changes rather than waiting for them to occur and run down your battery very quickly.

-Erik

OK lets separate the principles of threads from events.

Events as we know are raised by several methods, a transition of state on an input pin, a byte arriving at the UART, a timer rolling over of even a user generated event.

Threads are the individual program paths that can run contemporaneously on the device.

Putting the main thread into a sleep is not suspending the CPU and reducing power requirements. The underlying OS is beavering away waiting for events tiding up memory (Garbage collection) etc etc.

So I have some questions.

Are all events in the MF thread safe. In the CF and ordinary frameworks we usually use delegates to handle cross threading events. This does not seem to exists in the MF.

If we do a thread.sleep with a child thread it is blocking sibling threads or the parent thread as well as the thread it is executed on. Take the snippet of code here …

   Imports Microsoft.SPOT
Imports Microsoft.SPOT.Hardware
Imports SecretLabs.NETMF.Hardware
Imports SecretLabs.NETMF.Hardware.Netduino

Module Module1

    Private HeartBeatThread As Thread
    Private StatusLEDThread As Thread
    Private watchdogTimer As Timer
    Private StatusLEDTimer As Timer
    Private LED_1 As New OutputPort(Pins.GPIO_PIN_D5, False)
    Private LED_2 As New OutputPort(Pins.GPIO_PIN_D6, False)

    Sub Main()

        ' create 2 new threads

        HeartBeatThread = New Thread(AddressOf StartHeartBeatThread)
        StatusLEDThread = New Thread(AddressOf StartStatusLEDThread)

        'Start them up
        HeartBeatThread.Start()
        StatusLEDThread.Start()

        'enter main loop and loop forever
        While True
        End While

    End Sub

    Private Sub StartHeartBeatThread()
        Dim HeartBeatDelegate As New TimerCallback(AddressOf LED1)
        watchdogTimer = New Timer(HeartBeatDelegate, Nothing, 1000, 1000)
        'enter endless loop in thread
        While True
        End While
    End Sub

    Private Sub StartStatusLEDThread()
        Dim StatusLEDDelegate As New TimerCallback(AddressOf LED2)
        StatusLEDTimer = New Timer(StatusLEDDelegate, Nothing, 250, 250)
        'enter endless loop in thread
        While True
        End While
    End Sub

    Private Sub LED1(ByVal stateInfo As Object)
        LED_1.Write(Not LED_1.Read)
        HeartBeatThread.Sleep(500)
    End Sub

    Private Sub LED2(ByVal stateInfo As Object)
        LED_2.Write(Not LED_2.Read)
    End Sub


End Module

So we create two new threads point them at some code and start them. Within the code of each we create a timer and point the event handler at another method. Then in each thread we enter an endless loop. Now in theory each timer is operating within its own thread and the thread is looping endlessly.


Now some questions.

• When we exit the main loop does the system kill the two threads we have created for us [No the threads we have created continue to run even after the main loop has exited, they need to be explicitly stopped in the main thread with a HeartBeatThread.Abort() and StatusLEDThread.Abort()]
  
• No matter what blocking we have on thread "HeartBeatThread" we should expect the LED2 method on thread "StatusLEDThread" to be called every 250ms. [This does NOT work calls to the Sleep on method in the "HeartBeatThread" thread (HeartBeatThread.Sleep(500) or Thread.CurrentThread.Sleep(500)) cause the whole program to sleep, this is not good as it means that threads can become application blocking, this negates the whole point of threads]

You can also get rid of the infinite loop in te main thread if you wish by executing the following Thread.Sleep(Threading.Timeout.Infinite) Oddly enough however this does not seem to block unlike a sleep in another thread.




Code attached to play with.

Cheers Pete.

Attached Files

•  Thread Test.zip   49.61KB   1 downloads

[Bainesbunch]

OK I have tried using just threads in my second test and it seems that the problem is with timers potentially not running in the thread they are created in or interfering with each other.

In the attached code I have removed the timers from the code path and just toggle the LED states within a loop in the individual threads. This seems to work a treat with NO blocking issues. Now i have to re-think my code and instead of timers in threads simply loop with a sleep.

Cheers Pete.

Attached Files

•  Thread Test.zip   49.53KB   4 downloads

[mutsop]

thanks for the help Bainesbunch Really helpful!