ND+1 Connected to Router

Hi.  This one is difficult to explain.  I have been trying to figure it out on my own for days and have failed.    For a few weeks I have been building an application on an ND+1.  It works great.  Reading humidity, multiple temperatures, light levels, controlling relays, etc.  I connected the ND to a Netgear WNCE2001 (Ethernet Adapter) and set my ND to a static IP address.  Again, works great.  With port forwarding on my home router I am able to access all the sensor info from the internet.  Woo Hoo!   So, I went ahead a bought a nice box to house all my components and used external power supplies (not USB) for the ND and Netgear.  I noticed I couldn't 'talk' with the ND when I put in the static IP address.  Weird.  So, I unplugged the ND and plugged the USB cable to my PC for debugging.  Works great -- was able to access it via static IP with no problem!  Weird.  So, without unplugging the netgear I unplugged the ND USB and used the AC Power.  Now it works!  With both the ND and Netgear on external power I was able to access the ND via the IP Address.    So, now I recycle power on both the ND and Netgear and they don't work -- all the lights look happy (just like when plugged into to the USB port but, I can't access the ND via IP address).     For debugging I swapped out power supplies for the ND.  I tried staggering the boot so the netgear loads first, tried watch dog timer, tried cutting out all the code except for the webserver, tried polling the webserver, tried cycling the ethernet pin (CPU 50) -- tried so many things that I can't recall them all. Because I have lots of LED flashing debug points (flashes tell me where I am in the code) I can see that the ND is polling away waiting on the socket.     The only way to access the ND via IP address is if I run the ND in debug mode from the laptop.  Then I can unplug the ND and give it power from the AC power supply and it still works great.   I know I've done a poor job of explaining the issue and all my attempts of debugging....  just hoping someone may recognize this and can say "oh, that's easy just do ------ "   Thank you!

Hi Seascan

 

Have you upgraded to .netmf v4.2 yet?

 

I had issues with v4.1 - mostly this meant the other end of the Ethernet cable had to be live before applying power to the N+1. I recall the problem changed when I tried to observe it with the debugger attached. (I'm not sure if thats Schrodinger's cat, quantum mechanics or Pandora's box)

 

Now I am using v4.2 with static IP addresses, and it does not seem to matter which end becomes live first (Netduino+1 or Rapsberry Pi). Though I recently spent an afternoon working out how the C# sockets behave when the cable is not connected. (I now catch the exceptions and am able to plug in the Ethernet cable before or after my program has started. I can even unplug and replug later on.)

 

Paul

Hi Paul.  Thank you for the reply.

 

Yes, I am running 4.2.  I have alternated between 4.2.0.1 and a version of 4.2 that has OneWire and a Watchdog timer.  I've reflashed this ND many times to see if that is the issue.

 

What it comes down to is that it runs perfectly while connected by USB but, bizarrely when off external power.

 

To ensure I am truly cycling power, I rigged up a relay to an output pin.  The hot wire for my AC plug is wired into the normally closed portion of the relay.  When I set the relay high the power to the ND is reset (as well as the relay going back to the NC position). Works great!

 

In the Main portion of my code I read from the SD card.  If there is a file called rebootme then I reboot and delete the file (so that it doesn't reboot on the next go around).  

Take a look at this:

  Sub Main()        _onBoardLED = New OutputPort(Pins.ONBOARD_LED, False)        Dim Flash As Boolean        If System.IO.File.Exists("SDRebootMe.txt") Then            Do Until System.IO.File.Exists("SDRebootMe.txt") = False                System.IO.File.Delete("SDRebootMe.txt")            Loop            For x = 1 To 45                For i = 1 To 10                    _onBoardLED.Write(Flash)                    Thread.Sleep(100)                    Flash = Not Flash                Next            Next            _ResetRelay.Write(ONSTATE)            Exit Sub        Else            Do Until System.IO.File.Exists("SDRebootMe.txt") = True                Dim file As New System.IO.FileStream("SDRebootMe.txt", System.IO.FileMode.Create)                Dim SR As New System.IO.StreamWriter(file)                SR.WriteLine("FooBar")                SR.Flush()                SR.Close()                file.Close()            Loop        End IfEnd Sub

I have do loops to ensure that the file is deleted or written!  Bullet proof, right??  NOPE.  When I run off external power it just constantly reboots and re-runs the same portion.  When I run off of the USB in debug mode it is perfect every time.

 

I put the do loops in for deleting and creating the file just to be doubly sure that it is working.  Since the code gets past this and starts flashing the LED the I KNOW the file was deleted.  Still on the next reboot it "sees" the file and drops into the same portion of the code.

 

I re-formatted the 2GB SD card (tried both FAT and FAT32).  Still no workie.  

I don't do Visual Basic, but I can't see anything wrong with the code.

 

The only thing that I am wondering about is what happens when the Main() subroutine finishes?

Does it exit and stop, or since there is nothing else to do, does .net re-run it?

This behaviour may be different when the debugger is attached.

 

Perhaps you could try adding a loop forever at the end of the ELSE section of your code - e.g. after writing the reboot me file, where your real program would go when the Netduino was not being rebooted.

 

Hope this is it - Paul

Thanks again, Paul.

 

When it gets to the end it just quits.  When I rerun it on USB it works great.  On external power it doesn't work.

 

I am thinking it's an SD card issue and just created a new thread with an even more simplified example.

 

Perhaps I need to just throw in the towel and try an ND+2.  But, I am concerned that this will happen on it as well!  

Is there anything else you can write to apart from the SD card?

 

Have you got access to a set-reset flip-flop (e.g. two nand gates wired together).

What I am thinking is to take the SD card out of the problem.

Use a latch that is always powered, and use two GPIOs to pulse it into set or reset, and a third GPIO to read the state.

 

Or, have you got access to a 74HC595 shift register?

Join the MOSI SPI output to the shift register input, and join the MISO to the shift register output.

Keep the 595 powered all the time, then when you write a byte to it, you will read back the previous write....

Excellent ideas!  I may try to implement... but, for now I want/need to get an understanding of this strange behavior with the SD card.  

Excellent ideas!  I may try to implement... but, for now I want/need to get an understanding of this strange behavior with the SD card.  

Yes, but I think there might not be a problem with the SD card.

 

I suspect the debugger is changing the behaviour after the Main() subroutine has finished.

So with the degugger the code stops and waits, but without, the Netduino just re-runs main, making it go back round for another go - making it look like it is always resetting.

 

OK, simple test to prove my theory wrong - could you add an LED flashing loop to the ELSE code, with the LED flash at a different rate so you can tell if the code is going to the ELSE?

 

Paul

I will try that... but, first I need a new SD card.  Now, it's hanging in debug mode when I try to delete the file 

 

(EDIT) -- Never mind, I just had to reformat.

I am starting to narrow down the issue.

 

Whenever I attach my screw shield (shield that converts the header pins to screw terminals) the SD card needs to be re-formatted.  The file I create can not be deleted -- even with the PC!

 

Curiouser and Curiouser!

 

 

Hi seascan, Oh wow, that's quite the adventure I would recommend ruling out specific items first. For instance, what you say that it runs off of USB power fine but not off of AC adapter power...have you tried plugging it into a USB wall adapter (i.e. plugging USB into one of the adapters that come with a mobile phone)? If that fixes it, then there's a chance that your AC power supply or 5V step-down circuitry is out of spec. Then there's the speed that your program boots at...if you're running it from the PC, do you have a debugger active? If so then that will alter the speed at which things happen when your board boots...potentially exposing a bug in code (yours or the core firmware). You may want to try running MFDeploy, plugging in your board, and then reading the output of Debug.Print() statements from your app (by pressing F5 quickly in MFDeploy). Finally...if all the above doesn't help, I would recommend using some of the free serial pins (D0/D1, D2/D3 on Netduino 1...or those and D7/D8, SDA/SCL on Netduino 2) on your Netduino mainboard and connecting those and GND via a USB TTL adapter to your PC. Then you can Debug.Print out the status of your program operation via a channel which acts consistently in all circumstances--and "see" what your code is doing remotely. Chris

Hi Chris.  Yes, it has been quite a journey.  I discovered that the problem occured when I was powering the relay from the +5V on the ND.  I guess that with the Ethernet, writing to the SD and powering a few sensors must have been too much.  I was tired and didn't want to fiddle with it anymore.  It's been weeks of brain-strain.  I was about to give up --  actually, I did.  I put everything away and said to myself that "that's it. Enough is enough".  

 

20 minutes later it hit me:  instead of using a relay or any other crazy ideas, how about waiting  a minute and sending an ethernet request to itself on powerup.  If I don't get a response then cycle the power with powerstate.

 

It worked!  

 

So, now I just need to figure out why I lose ethernet connectivity after 30 minutes or so (while on USB I never had this issue).  

 

So, it continues....

Chris, I should have added that I did try multiple power supplies.  Also tried using a phone charger through the USB to power it and had the same issue.  

 

I really like your idea:

 

 

[color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;]Finally...if all the above doesn't help, I would recommend using some of the free serial pins (D0/D1, D2/D3 on Netduino 1...or those and D7/D8, SDA/SCL on Netduino 2) on your Netduino mainboard and connecting those and GND via a USB TTL adapter to your PC. Then you can Debug.Print out the status of your program operation via a channel which acts consistently in all circumstances--and "see" what your code is doing remotely.[/color]