Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

4.2.0.x device not responding


  • Please log in to reply
18 replies to this topic

#1 SpitfireMike

SpitfireMike

    Member

  • Members
  • PipPip
  • 17 posts
  • LocationColorado Springs, CO, USA

Posted 22 September 2012 - 04:26 AM

Netduino Rev.A, updated to 4.1.0.6 in Apr without any problems. Tried updating to 4.2.0.0 earlier this month and was somewhat less successful. Same problems that others have reported, VS says "The debugging target is not in a initialized state; rebooting", disconnecting the USB cable and reconnecting did not have an effect. Uninstalling the MFSDK.QFE2 and netduinosdk_64 and reinstalling didn't change anything either. Was looking forward to trying 4.2.0.1, but can't connect with MF Deploy.

Device Manager shows the Netduino, says it's working properly, using Secret Labs 6.1.7601.17514 driver backed by winusb.sys.
MFDeploy from 4.2.0 shows the Netduino_Netduino device. Target | Device Capabilities shows a big list of responses (pasted below). Ping says "Pinging... TinyCLR", but doesn't respond after that. Trying to deploy the 4.2.0.1 firmware fails when I hit "Deploy", reports that the device isn't responding. Oddly enough, Target | Connect is successful, anything after that reports "NoConnection".

What do I do from here? I have 3 other Rev.A Netduinos that are still on 4.1, a bit hesitant to try the update to 4.2 with those. If I can't get 4.2 working, is there a way to go back to 4.1? I'd hate to resort to using this one as a coaster, the offset headers make my coffee cup all wobbly<g>




HalSystemInfo.halVersion:               4.2.0.0
HalSystemInfo.halVendorInfo:            Netduino (v4.2.0.0) by Secret Labs LLC
HalSystemInfo.oemCode:                  34
HalSystemInfo.modelCode:                177
HalSystemInfo.skuCode:                  4096
HalSystemInfo.moduleSerialNumber:       00000000000000000000000000000000
HalSystemInfo.systemSerialNumber:       0000000000000000
ClrInfo.clrVersion:                     4.2.0.0
ClrInfo.clrVendorInfo:                  Netduino (v4.2.0.0) by Secret Labs LLC
ClrInfo.targetFrameworkVersion:         4.2.0.0
SolutionReleaseInfo.solutionVersion:    4.2.0.0
SolutionReleaseInfo.solutionVendorInfo: Netduino (v4.2.0.0) by Secret Labs LLC
SoftwareVersion.BuildDate:              Aug 12 2012
SoftwareVersion.CompilerVersion:        410894
FloatingPoint:                          True
SourceLevelDebugging:                   True
ThreadCreateEx:                         True
LCD.Width:                              0
LCD.Height:                             0
LCD.BitsPerPixel:                       0
AppDomains:                             True
ExceptionFilters:                       True
IncrementalDeployment:                  True
SoftReboot:                             True
Profiling:                              False
ProfilingAllocations:                   False
ProfilingCalls:                         False
IsUnknown:                              False


#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 22 September 2012 - 04:39 AM

Hi SpitfireMike, You can absolutely move back to 4.1 if you want. The process is the same; just grab the 4.1 firmware. On 4.2... Can you try manually switching the drivers to the MFUSB drivers instead? And see if that works for you? Chris

#3 PhillipMorris

PhillipMorris

    Member

  • Members
  • PipPip
  • 17 posts
  • LocationSerres, HELLAS

Posted 22 September 2012 - 04:33 PM

Some problem.

HalSystemInfo.halVersion: 4.2.0.0
HalSystemInfo.halVendorInfo: Netduino (v4.2.0.1) by Secret Labs LLC
HalSystemInfo.oemCode: 34
HalSystemInfo.modelCode: 177
HalSystemInfo.skuCode: 4096
HalSystemInfo.moduleSerialNumber: 00000000000000000000000000000000
HalSystemInfo.systemSerialNumber: 0000000000000000
ClrInfo.clrVersion: 4.2.0.0
ClrInfo.clrVendorInfo: Netduino (v4.2.0.1) by Secret Labs LLC
ClrInfo.targetFrameworkVersion: 4.2.0.0
SolutionReleaseInfo.solutionVersion: 4.2.0.0
SolutionReleaseInfo.solutionVendorInfo: Netduino (v4.2.0.1) by Secret Labs LLC
SoftwareVersion.BuildDate: Sep 19 2012
SoftwareVersion.CompilerVersion: 410894
FloatingPoint: True
SourceLevelDebugging: True
ThreadCreateEx: True
LCD.Width: 0
LCD.Height: 0
LCD.BitsPerPixel: 0
AppDomains: True
ExceptionFilters: True
IncrementalDeployment: True
SoftReboot: True
Profiling: False
ProfilingAllocations: False
ProfilingCalls: False
IsUnknown: False


VS says "The debugging target is not in a initialized state; rebooting".
Where do I find MFUSB Drivers ?

#4 SpitfireMike

SpitfireMike

    Member

  • Members
  • PipPip
  • 17 posts
  • LocationColorado Springs, CO, USA

Posted 22 September 2012 - 04:37 PM

Someone give a gold start to Chris. Switching to the MFUSB driver seems to have fixed it. Thanks


Easy to follow instructions for anyone else having this problem in another one of Chris' posts:
http://forums.netdui...-mfusb-drivers/

#5 SpitfireMike

SpitfireMike

    Member

  • Members
  • PipPip
  • 17 posts
  • LocationColorado Springs, CO, USA

Posted 22 September 2012 - 05:20 PM

Spoke too soon. Trying to deploy/run from VS I'm still getting the "The debugging target is not in an initialized state; rebooting..." message. Using the technique of unplugging the USB cable causes an immediate reboot of my Win7 box. Same thing is happening with one of my 4.1 Netduinos. MFDeploy 4.2 does not see the Netduino. I'll reboot again, uninstall the SDKs and drivers, start from scratch.

#6 PhillipMorris

PhillipMorris

    Member

  • Members
  • PipPip
  • 17 posts
  • LocationSerres, HELLAS

Posted 22 September 2012 - 05:41 PM

I did it already. Uninstalled and installed everything. Just the same. When I try to unplug Netduino, I get a blue screen saying something but a memory dump and my Windows 7 PC restarts. Any ideas ?

#7 SpitfireMike

SpitfireMike

    Member

  • Members
  • PipPip
  • 17 posts
  • LocationColorado Springs, CO, USA

Posted 22 September 2012 - 06:27 PM

Uninstalled MicroFrameworkSDK_NETMF42_QFE2 and netduinosdk_64bit_NETMF42, rebooted, installed again, plugged in the 4.1, MFDeploy connects successfully. Simple blinky-LED program with 4.1 deploys and runs successfully. Deploy and run the same program on the one updated to 4.2 and it has the old problems. Same program, still using 4.1, but on the 4.2 firmware. I'll just stick with 4.1 for now.

#8 lor3

lor3

    Member

  • Members
  • PipPip
  • 12 posts

Posted 24 September 2012 - 11:31 AM

I'm also have a lot of issues with 4.2 (I think RC6 was fine). Tried reinstalling everything, have reflashed device firmware (bootloader up) and still have the "Resetting device..." VS message. Also tried using the MFUSB drivers which causes BSOD on my machine (Win7 64-bit). Going to try 4.2 on my Plus device now - it seems a shame to have to revert to 4.1 and miss out on the nice new features.

#9 lor3

lor3

    Member

  • Members
  • PipPip
  • 12 posts

Posted 24 September 2012 - 02:21 PM

My Netduino Plus is working fine so whatever the problem is it's specific to the basic Netduino.

#10 Elisoj

Elisoj

    Member

  • Members
  • PipPip
  • 12 posts
  • LocationMunich, Germany

Posted 22 October 2012 - 08:23 AM

My Netduino Plus is working fine so whatever the problem is it's specific to the basic Netduino.


I can't agree that the problems only occur with the basic Netduino. I have a N+ and from the first day I had problems with deployment, stating that "device is not in an initialized state, rebooting". It also gets stuck on "Preparing to deploy assemblies to the device". Yesterday I got a BSOD during deployment, but I can't reproduce it yet.

For now, I just wanted to chime in, I'll post updates when I have steps to reproduce.

#11 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 22 October 2012 - 08:39 AM

It seems like most users are having good luck with .NET MF 4.2 (either using WinUSB or switching back to the MFUSB drivers). But it sounds like a few computers just don't like the new setup. If we can find a way to reproduce this in the lab, we'd love to dig into it. We'd really like for everyone to be able to upgrade their NETMF boards to .NET MF 4.2. Chris

#12 Elisoj

Elisoj

    Member

  • Members
  • PipPip
  • 12 posts
  • LocationMunich, Germany

Posted 23 October 2012 - 04:07 PM

Oh, not good. I don't know how I managed to do that, but I can't talk to my netduino anymore. Maybe the problem has to do something with the fact that I switched to serial deployment (although that has been working for a week now). I was doing that in order to get it working as USB HID using Omar's excellent work.

Is there a way to get back to USB deployment again when neither MFDeploy nor VS can talk to it via serial or even see it via USB?
Do I have to reflash it? Is there some "medium reset" option in between erasing the app via MFDeploy and doing a full reflash?

Some more information:
* It's a N+
* When I power it over USB, PWR and the blue LED light up and the blue one goes off after ~3 secs
* Another PC of mine stated something around "The last device plugged into this computer malfunctioned and Windows doesn't recognize it" (the message was German)

#13 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 23 October 2012 - 04:48 PM

Hi Elisoj, No worries, let's get you back up and running again... If you've switched to serial deployment, the USB debug port will be disabled. So "this USB device isn't recognized" types of messages are normal. If you can't ping via serial, try holding the pushbutton on your Netduino while plugging it into your PC. This will put it into TinyBooter mode. Then ping it from MFDeploy. If you get a response, erase your current app. Then detach, re-attach, and try deploying from Visual Studio again. If all else fails, erase your board and re-flash from scratch. Chris

#14 Elisoj

Elisoj

    Member

  • Members
  • PipPip
  • 12 posts
  • LocationMunich, Germany

Posted 23 October 2012 - 04:59 PM

Hi Chris,

thanks for your help. I already tried to erase the app using this procedure:
* Holding the button while powered off
* Powering on, still holding the button
* Pressing PING within 5 seconds
(I have done this previously, before this incident, to erase the app and succeeded)

To make sure I get it right: Pinging over USB is not possible when serial deployment is active?

The problem is that it doesn't help this time. So I guess it's erasing (using the gold pad, afaik) and flashing the firmware. If I understand correctly, I do not have to install the TinyBooter Decompressor, or is it required in this case?

#15 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 23 October 2012 - 05:09 PM

Hi Elisoj,

To make sure I get it right: Pinging over USB is not possible when serial deployment is active?

Correct. NETMF listens for debug traffic over one port at a time. So if it's been switched to use serial deploy/debug, it won't be listening on USB.

So I guess it's erasing (using the gold pad, afaik) and flashing the firmware. If I understand correctly, I do not have to install the TinyBooter Decompressor, or is it required in this case?

Yes, when you erase the board you'll need to flash the NETMF bootloader onto the board. Then use MFDeploy to flash the NETMF runtime (TinyCLR) and you should be good to go from there.

Please let us know if you run into any troubles,

Chris

#16 Elisoj

Elisoj

    Member

  • Members
  • PipPip
  • 12 posts
  • LocationMunich, Germany

Posted 23 October 2012 - 05:14 PM

Hold on. I managed to get into TinyBooter mode with the procedure I described. I must have gotten the timing wrong on my first attempts. Sometimes it's helpful to write down what you already know and then follow your own instructions ... I also can do a serial deployment again, whoohoo! However, I am curious, how can I get back to USB deployment? I still cannot ping or deploy over USB.

#17 Elisoj

Elisoj

    Member

  • Members
  • PipPip
  • 12 posts
  • LocationMunich, Germany

Posted 23 October 2012 - 05:20 PM

I just realized you posted at the same time I did. Thanks a ton for your help, Chris. I did a search about getting back to USB deployment but didn't find anything. It must be really obvious so it's probably just me :-/

#18 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 23 October 2012 - 06:51 PM

Hi Elisoj,

I just realized you posted at the same time I did. Thanks a ton for your help, Chris. I did a search about getting back to USB deployment but didn't find anything. It must be really obvious so it's probably just me :-/

No worries :)

To switch back to USB, just run the same "deployment switch" tool that you used to switch to serial deployment. Except this time select USB. That's it.

You can of course also erase and re-flash the board to reset things back to factory defaults.

Chris

#19 Elisoj

Elisoj

    Member

  • Members
  • PipPip
  • 12 posts
  • LocationMunich, Germany

Posted 23 October 2012 - 07:51 PM

To switch back to USB, just run the same "deployment switch" tool that you used to switch to serial deployment. Except this time select USB. That's it.

You got me again, Chris. I made the mistake of not paying attention to use the custom build MFDeploy you mentioned in this post.
I thought that, given that this post is over a year old, it has already built into the normal MFDeploy. This was a) a silly assumption and B) I downloaded it to switch deployment methods the first time.

I got everything working again, thanks to you. Great things are afoot :-)




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.