DL40 + Spider: problems using interrupt

SteZab · January 26, 2014, 5:56pm

Hello,

I am trying to use the DL40 module with a Spider I.
The goal is to handle up to 10 interrupts.

I flashed the DL40 using a Spider with a T35 display. No errors. I used the last DL40.bin from http://dl40io.codeplex.com/.

I connected the module to Spider Socket 10.

Then I try this simple code:

using System;
using System.Collections;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Presentation;
using Microsoft.SPOT.Presentation.Controls;
using Microsoft.SPOT.Presentation.Media;
using Microsoft.SPOT.Presentation.Shapes;
using Microsoft.SPOT.Touch;

using Gadgeteer.Networking;
using GT = Gadgeteer;
using GTM = Gadgeteer.Modules;
using dotnetwarrior.NetMF.DL40;

namespace GadgeteerApp1
{
    public partial class Program
    {
        // This method is run when the mainboard is powered up or reset.   
        void ProgramStarted()
        {
            DLIOModule DL40 = new DLIOModule(10);                       
            IInterruptPin InterruptPin1 = DL40.CreateInterruptPin(1, 1, Microsoft.SPOT.Hardware.Port.ResistorMode.Disabled, Microsoft.SPOT.Hardware.Port.InterruptMode.InterruptEdgeBoth);        
            InterruptPin1.Interrupt += new PinInterruptHandler(Pin_Interrupt1);          
            Debug.Print("Program Started");
        }

        void Pin_Interrupt1(IInterruptPin pin, uint interruptCount)
        {
            Debug.Print("Interrupt!");
        }
    }
}

I wired a cable to ground and a cable to P1.1. When I short the two cables, the interrupt does not fire!

Is it right to call the CreateInterruptPin with port=1 and pin=1 to use the P.1.1 pin?

I tried both with the pullup resistor enabled and disabled. No difference.

I also noticed that, after debugging the module, if I try to start a new debug session, I receive the error:

No DaisyLink modules are detected on socket 10.

I need to change the socket (for example using socket 11) and then try to debug again to be able to use the module again.

:wall:

Any idea?

taylorza · January 26, 2014, 7:50pm

The problem is that when the mainboard code executes it initializes the DL40 and the DL40 is in the ready state, then when you start debugging the code tries to initialize the DL40 again but since it is already in the ready state it does not get detected. I normally hold the reset button in and start the deployment from VS once the deployment starts I release the reset button.

As for the problem with your interrupt, can you start with a test with the code I posted in the following link, that is known to work then we can work from there.

https://www.ghielectronics.com/community/forum/jump/10325/123303

Please make sure you are using the latest binaries from Code Share
https://www.ghielectronics.com/community/codeshare/entry/633

Brett · January 27, 2014, 12:15am

…and make sure your firmware update to the dl40 actually was the right firmware otherwise you might look like I did :-[

SteZab · January 27, 2014, 11:37am

Hello,

first of all, thank you for your time!

As suggested, I followed these steps:

verify the DL40 firmware. I upgraded the firmware using the DL40.bin file found in the package downloaded here: https://www.ghielectronics.com/community/codeshare/entry/633
I downloaded version 14.
connect the DL40 to socket 11 (Y) or 10 (X) of the Spider I
deploy the code suggested:

using System;
using System.Threading;
using Microsoft.SPOT;
using dotnetwarrior.NetMF.DL40;

namespace GadgeteerApp1
{
    public partial class Program
    {
        // This method is run when the mainboard is powered up or reset.  
        class TestInterruptPin
        {

            static DLIOModule Module;
            static IInterruptPin InterruptPin;
            static IInterruptPin InterruptPin2;
            static IOutputPin LedPin;
            public static void Run(DLIOModule module)
            {
                Module = module;
                LedPin = Module.CreateOutputPin(2, 3, false);
                InterruptPin = Module.CreateInterruptPin(3, 1, Microsoft.SPOT.Hardware.Port.ResistorMode.PullDown, Microsoft.SPOT.Hardware.Port.InterruptMode.InterruptEdgeHigh);
                InterruptPin.Interrupt += new PinInterruptHandler(Pin_Interrupt);
                InterruptPin2 = Module.CreateInterruptPin(3, 2, Microsoft.SPOT.Hardware.Port.ResistorMode.PullDown, Microsoft.SPOT.Hardware.Port.InterruptMode.InterruptEdgeHigh);
                InterruptPin2.Interrupt += new PinInterruptHandler(Pin_Interrupt2);               
            }
            static void Pin_Interrupt(IInterruptPin pin, uint interruptCount)
            {
                Debug.Print("3.1");
                LedPin.Write(!LedPin.Read());
            }
            static void Pin_Interrupt2(IInterruptPin pin, uint interruptCount)
            {
                Debug.Print("3.2");
                LedPin.Write(!LedPin.Read());
            }
        }
        void ProgramStarted()
        {
            
            DLIOModule aModule = new DLIOModule(11);
            TestInterruptPin.Run(aModule);

            Debug.Print("Program Started");
        }
    }
}

Then I shorted the P3.1 or P3.2 to 3.3v. No interrupt detected.
I also tried to set the LedPin to true and I used a voltmeter from p.2.3 to ground: 0 volt detected.

Any idea?

Thanks again!

Brett · January 27, 2014, 2:08pm

Let me ask again, how did you update the dl40? Connected to the * port, and making sure the code deployed was the correct bin file? The example deployment deploys a different bin file, it has multiple files. perhaps show output of deploying?

SteZab · January 27, 2014, 4:11pm

@ Brett,

this is the procedure I used. I guess the problem is here.

I opened the solution file “serial communication with test daisylink.sln”. The DL40.bin file is a resource of the project. I deleted the DL40.bin included in the original project and I added a new resource using the DL40.bin file downloaded from codeplex. Then I deployed the software and saw the upgrade has been ok.

Is this the right procedure?

Thank!

SteZab · January 27, 2014, 4:18pm

Hi, I forgot to say that the DL40 is connected to the spider using its * socket.

SteZab · January 27, 2014, 4:26pm

This the output.

Found debugger!

Create TS.

Loading start at a0e00000, end a0e1383c

Assembly: mscorlib (4.2.0.0) Assembly: Microsoft.SPOT.Native (4.2.0.0) Assembly: Microsoft.SPOT.Security.PKCS11 (4.2
.0.0) Assembly: System.Security (4.2.0.0) Loading Deployment Assemblies.

Attaching deployed file.

Assembly: Microsoft.SPOT.IO (4.2.0.0) Attaching deployed file.

Assembly: Gadgeteer (2.42.0.0) Attaching deployed file.

Assembly: Gadgeteer.WebClient (2.42.0.0) Attaching deployed file.

Assembly: Microsoft.SPOT.Graphics (4.2.0.0) Attaching deployed file.

Assembly: Microsoft.SPOT.Hardware (4.2.0.0) Attaching deployed file.

Assembly: System.Http (4.2.0.0) Attaching deployed file.

Assembly: System (4.2.0.0) Attaching deployed file.

Assembly: Microsoft.SPOT.Net.Security (4.2.0.0) Attaching deployed file.

Assembly: serial communication with test daisylink (1.0.0.0) Attaching deployed file.

Assembly: Gadgeteer.WebServer (2.42.0.0) Attaching deployed file.

Assembly: GHI.Premium.Hardware (4.2.11.1) Attaching deployed file.

Assembly: GTM.GHIElectronics.Display_T35 (4.2.101.0) Attaching deployed file.

Assembly: Microsoft.SPOT.Touch (4.2.0.0) Attaching deployed file.

Assembly: System.Net.Security (4.2.0.0) Attaching deployed file.

Assembly: Microsoft.SPOT.TinyCore (4.2.0.0) Attaching deployed file.

Assembly: GHI.Premium.System (4.2.11.1) Attaching deployed file.

Assembly: Microsoft.SPOT.Net (4.2.0.0) Attaching deployed file.

Assembly: System.IO (4.2.0.0) Attaching deployed file.

Assembly: GHI.Premium.IO (4.2.11.1) Attaching deployed file.

Assembly: Microsoft.SPOT.Hardware.PWM (4.2.0.1) Attaching deployed file.

Assembly: Microsoft.SPOT.Hardware.SerialPort (4.2.0.0) Attaching deployed file.

Assembly: GHIElectronics.Gadgeteer.FEZSpider (4.2.101.0) Resolving.

GC: 1msec 39492 bytes used, 7300176 bytes available

Type 0F (STRING ): 24 bytes

Type 15 (FREEBLOCK ): 7300176 bytes

Type 17 (ASSEMBLY ): 34920 bytes

Type 1E (BINARY_BLOB_HEAD ): 4044 bytes

Type 28 (MEMORY_STREAM_HEAD ): 36 bytes

Type 29 (MEMORY_STREAM_DATA ): 396 bytes

Type 34 (APPDOMAIN_HEAD ): 72 bytes

GC: performing heap compaction…

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

‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\mscorlib.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Native.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Security.PKCS11.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\System.Security.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.IO.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.PWM.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Graphics.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.TinyCore.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Net.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\System.IO.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Gadgeteer\Core\Assemblies.NET Micro Framework 4.2\le\Gadgeteer.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\System.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Net.Security.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\System.Net.Security.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\System.Http.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Gadgeteer\Core\Assemblies.NET Micro Framework 4.2\le\Gadgeteer.WebClient.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Hardware.SerialPort.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Assemblies\le\Microsoft.SPOT.Touch.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\GHI Electronics\GHI .NET Gadgeteer SDK\Modules\Display_T35\NETMF 4.2\le\GTM.GHIElectronics.Display_T35.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\GHI Electronics\GHI Premium NETMF v4.2 SDK\Assemblies\le\GHI.Premium.System.dll’
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\GHI Electronics\GHI Premium NETMF v4.2 SDK\Assemblies\le\GHI.Premium.IO.dll’
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\GHI Electronics\GHI Premium NETMF v4.2 SDK\Assemblies\le\GHI.Premium.Hardware.dll’
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\GHI Electronics\GHI .NET Gadgeteer SDK\Mainboards\FEZSpider\NETMF 4.2\le\GHIElectronics.Gadgeteer.FEZSpider.dll’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘J:\Dev\c#\Gadgeteer\serial communication with test daisylink\serial communication with test daisylink\bin\Debug\le\serial communication with test daisylink.exe’, simboli caricati.
‘Microsoft.SPOT.Debugger.CorDebug.dll’ (Gestito): caricato ‘C:\Program Files (x86)\Microsoft .NET Gadgeteer\Core\Assemblies.NET Micro Framework 4.2\le\Gadgeteer.WebServer.dll’, simboli caricati.
Il thread ‘’ (0x2) è terminato con il codice 0 (0x0).
Using mainboard GHI Electronics FEZSpider version 1.0
Beginning chip reflash…
Il thread ‘’ (0x4) è terminato con il codice 0 (0x0).
Connecting…
Connected!
Erasing…
Erased!
Converting File…
Converted!
Downloading…
Il thread ‘’ (0x3) è terminato con il codice 0 (0x0).
Downloaded!
Board Flash Complete!
Il thread ‘’ (0x5) è terminato con il codice 0 (0x0).
Il programma ‘[24] Micro Framework application: Gestito’ è terminato con il codice 0 (0x0).

I flashed the DL40 again. I removed the DL40.bin resource from the project and added that provided with the driver downloaded from codeshare, version 14.

SteZab · January 27, 2014, 4:37pm

Does



mean that PIN P.3.2 will be used?

I think it is right, but I don't know how to solve and so I'm searching for some errors... :'(

taylorza · January 27, 2014, 6:38pm

@ SteZab - That is correct, pin 3.2 should be triggering interrupts if you use the code I linked to. You update procedure looks good, when you pull the pin high, can you read the value and see what you are getting back? The interruptPin has a function to read the value directly, check if that is returning the right values.

Brett · January 27, 2014, 8:28pm

… and did you change what BIN file was referenced in the app?

Here’s the line that is “as-is” on the firmware deployment project:

    public byte[] binFile = Resources.GetBytes(Resources.BinaryResources.Propeller);

taylorza · January 27, 2014, 8:32pm

Brett:

… and did you change what BIN file was referenced in the app?

Here’s the line that is “as-is” on the firmware deployment project:
    public byte[] binFile = Resources.GetBytes(Resources.BinaryResources.Propeller);

Wow, that is new, the last time I used the DL40 updater it was referencing the DL40 resource, did not now it was changed. Thanks for pointing that out Brett…

Brett · January 27, 2014, 9:11pm

that was that publically embarrassing of Brett’s ignorance a few weeks ago that uncovered that

SteZab · January 28, 2014, 3:05am

[quote]… and did you change what BIN file was referenced in the app?

Here’s the line that is “as-is” on the firmware deployment project:

public byte[] binFile = Resources.GetBytes(Resources.BinaryResources.Propeller);[/quote]

NO I DID NOT!!! That is the problem, for sure!!!

And now I am in the office and I cannot try… :’(

I will be back to you this evening, but I guess this is the problem…

Thank you very much!

Brett · January 28, 2014, 10:13am

This is why I said every DL firmware needed to contain a build version string that you could retrieve to see if your deployment worked… I’ve never looked at the DL structure to see how simple or not it would be to extend it in that way… @ Taylorza, thoughts?

taylorza · January 28, 2014, 3:25pm

You are correct, and the DaisyLink protocol actually supports this. I did not use it because at the time I did not have a manufacturer code (thank you again for sorting that out for me) and therefore needed to stick with the generic module ID using the GHI code.

Now that it has actually caused a problem, I will definitely release an update shortly that defines the module type, manufacturer and version.

SteZab · January 29, 2014, 3:53am

Guys,

other news…
I flashed again the DL40 changing the resource name:



The upgrade went good.

Now the led on DL40 board is switched on (before it was switched off).

I am not able to use the trick to hold the reset button on the spider, start the deploy and then release the button because my VS 2010 Express raises an error saying it is not able to find the device. I tried to release the button in different moments with no success. I am not able to debug with VS.

But I deployed the test program and restarted the spider without VS and saw with a voltmeter that the interrupt pin are both high, also if I use a pullDown resistor. Furthermore, the LedPin is 1,62 volt, so it is "undefined" even though I set it to true.

Could it be possible that my DL40 is not working properly?

Have a nice day.

Stefano.

taylorza · January 29, 2014, 5:47pm

@ SteZab - Did you double check that the resource being loaded onto the DL40 is the one from the codeshare and not the stock firmware?

Brett · January 29, 2014, 5:53pm

yes that was another trap I found, the original project was a VS2010 project and you have to load it differently for VS2012…

We should rev that project for VS2012 and display what resource it’s deploying

SteZab · January 30, 2014, 5:20pm

So, after changing the resource name in the code, all was fine, but I cannot realize a very important thing: resetting the spider does not reset the DL40. It is necessary to disconnect the DL40 from the spider or to switch the power of the spider off!

Now all seems to work fine. Now I’m going to test the interrupt feature with my real project. I will be back to you!

I’ve really appreciated your help!

Stefano.