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

N+2 deploys, starts loading debugger then stops


  • Please log in to reply
13 replies to this topic

#1 MarkNic

MarkNic

    Member

  • Members
  • PipPip
  • 22 posts

Posted 28 November 2012 - 03:03 AM

Background: Own 2 N+ boards and have been working with them for quite a while. New N+2 and tried to load a simple app to do nothing more than read a couple digital pins. When I run it, VS starts to deploy and start the debugger but before any breakpoint is hit the app freezes. After that MFDeploy can see the board but when I ping: "Error: No response from device". Power off/on does not change things. Only recourse is to redo the firmware with DFU tools. That part works fine and I've done it over a dozen times trying to get the board to go but no joy. I initially thought the problem to be that I was running from Windows 8 so I moved over to a Win7 (32bit) machine but freezes just the same. ClrInfo.clrVersion: 4.2.0.0 ClrInfo.clrVendorInfo: Netduino Plus 2 (v4.2.1.0) by Secret Labs LLC ClrInfo.targetFrameworkVersion: 4.2.0.0 SolutionReleaseInfo.solutionVersion: 4.2.1.0 SolutionReleaseInfo.solutionVendorInfo: Netduino Plus 2 (v4.2.1.0) by Secret Labs LLC SoftwareVersion.BuildDate: Nov 7 2012 I tried both USB drivers but MFUSB is currently installed. I can't get any further with it. Anyone with ideas or similar situations? Thanks, Marknic

#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 30 November 2012 - 09:17 AM

Hi Marknic, Are you redeploying an existing Netduino Plus 1 project to Netduino Plus 2? If so, can you please remove the SecretLabs.NETMF.Hardware.NetduinoPlus.dll reference from your project? And add the new SecretLabs.NETMF.Hardware.Netduino.dll (no "plus" in there) instead? When switching between .NET MF boards, changing the Hardware Provider is typically necessary. We've actually found a good way to make this migration automatic, and will be including this in the December SDK update. But in the meantime, let's make sure we get you up and running. Does this fix the issue for you, Marknic? Chris

#3 MarkNic

MarkNic

    Member

  • Members
  • PipPip
  • 22 posts

Posted 01 December 2012 - 06:59 PM

Chris,

Thanks for getting back.

Are you redeploying an existing Netduino Plus 1 project to Netduino Plus 2?


No, a new N+2 specific VS project created (create an input port, try to read it, debug.print the result in a loop) and used in this experience. Although, as part of the testing, I did check and make sure the "non-plus" assembly was referenced and used. Always looks like the code is deployed but then freezes just before it starts to run. Like I mentioned, once the board stops, MFDeploy can't ping. All I can do to fix it is erase/reinstall the firmware.

I haven't gotten to the point where I do want to extend an application that now runs on a Gadgeteer device to also operate on the N+2 - now that it has the extended performance and memory. Kudos for that move BTW. Anyway, once I get passed deploy and debug, then I will worry about the migration. First things first.

Regards,

Mark

#4 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 01 December 2012 - 08:14 PM

Hi Marknic, Can you please post your simple app so we can run it and take a look at it really quickly? If it does the same thing here, we can debug the issue. If not then we'll take a look at potential driver issues. Chris

#5 MarkNic

MarkNic

    Member

  • Members
  • PipPip
  • 22 posts

Posted 02 December 2012 - 06:02 PM

Chris, Ok, apparently in my attempt to quickly test the board I pointed at the cpu pin (my stupidity + intellisense != good app). I get that the enumerated values are different so my bad. var myPin = new InputPort(Cpu.Pin.GPIO_Pin12, false, Port.ResistorMode.PullUp); One thing I did test though was running this same code (using the N+1 VS app template) on a N+1 and it stalled in the same way but does recover. That is, if I shut down the app and ping in MFDeploy it replies. If you run the code on the N+2 (using the N+2 VS app template) it locks up. MFDeploy can see the board but it won't reply to a ping and requires a reload of the firmware to get it going again. Like I said, I get that the pin mapping is different but if I had written the test with Cpu.Pin.GPIO_Pin3, the app would have run. Pin2 would really have the pin I activated so the app wouldn't have worked right but also wouldn't have locked to the point of having to reload the firmware. Just an FYI/Observation. Thanks for the support, Mark

#6 Arron Chapman

Arron Chapman

    Advanced Member

  • Members
  • PipPipPip
  • 289 posts
  • LocationOregon, USA

Posted 02 December 2012 - 06:07 PM

Chris,

Ok, apparently in my attempt to quickly test the board I pointed at the cpu pin (my stupidity + intellisense != good app). I get that the enumerated values are different so my bad.

var myPin = new InputPort(Cpu.Pin.GPIO_Pin12, false, Port.ResistorMode.PullUp);

One thing I did test though was running this same code (using the N+1 VS app template) on a N+1 and it stalled in the same way but does recover. That is, if I shut down the app and ping in MFDeploy it replies. If you run the code on the N+2 (using the N+2 VS app template) it locks up. MFDeploy can see the board but it won't reply to a ping and requires a reload of the firmware to get it going again.

Like I said, I get that the pin mapping is different but if I had written the test with Cpu.Pin.GPIO_Pin3, the app would have run. Pin2 would really have the pin I activated so the app wouldn't have worked right but also wouldn't have locked to the point of having to reload the firmware. Just an FYI/Observation.

Thanks for the support,

Mark


For reference you should really be using the Pins enum (Pins.GPIO_PIN_D10) provided by SecretLabs.NETMF.Hardware.Netduino. The Cpu.Pin enum is relative to the pins on the uC not to the lables on the N+2.

When you talk EE use small words, I'm just a Software Developer :)
My Blog/Site and Everything Else

If my post helped you please consider pressing the "Like This" button in the bottom right-hand corner.

 

Oh my. So many things, so little money!!

 


#7 MarkNic

MarkNic

    Member

  • Members
  • PipPip
  • 22 posts

Posted 02 December 2012 - 06:41 PM

For reference you should really be using the Pins enum (Pins.GPIO_PIN_D10) provided by SecretLabs.NETMF.Hardware.Netduino. The Cpu.Pin enum is relative to the pins on the uC not to the lables on the N+2.


Arron,

Yes, I get that. That's why I mentioned it in my post. The point of my last reply was just to point out the possible semi-destructive nature of a simple pin mismatch on the N+2 board that doesn't appear to occur on the N+1. If, for example, the Netduino assemblies threw an exception for pin references "outside of bounds", the board would not have locked up and I would have known immediately what the problem was.

Like I said, just an FYI,

Mark

#8 Brenden

Brenden

    New Member

  • Members
  • Pip
  • 3 posts

Posted 02 December 2012 - 11:00 PM

Hi Chris, I seem to have done something similar - used the CPU pin assignment instead of the Pins Enum and now my N+2 board does not respond. When I try to deploy a simple blinky program, VS just hangs indefinitely. Never gets to executing the program or hitting any breakpoint. MFDeploy recognizes the board, but the board does not respond to a ping at all I have tried to use STDFU Tester appication to, to reflash the firmware, but the board is not picked up at all. Is there something else I can try to rectify my mistake? Brenden

#9 Arron Chapman

Arron Chapman

    Advanced Member

  • Members
  • PipPipPip
  • 289 posts
  • LocationOregon, USA

Posted 03 December 2012 - 02:55 AM

Arron,

Yes, I get that. That's why I mentioned it in my post. The point of my last reply was just to point out the possible semi-destructive nature of a simple pin mismatch on the N+2 board that doesn't appear to occur on the N+1. If, for example, the Netduino assemblies threw an exception for pin references "outside of bounds", the board would not have locked up and I would have known immediately what the problem was.

Like I said, just an FYI,

Mark

Ahh, I misread :)

When you talk EE use small words, I'm just a Software Developer :)
My Blog/Site and Everything Else

If my post helped you please consider pressing the "Like This" button in the bottom right-hand corner.

 

Oh my. So many things, so little money!!

 


#10 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 03 December 2012 - 03:10 AM

Hi Brenden,

I have tried to use STDFU Tester appication to, to reflash the firmware, but the board is not picked up at all.

When you press and hold the pushbutton on your Netduino Plus 2 while plugging into your PC via USB...what does it show up as in Device Manager? Is the driver installed?

Chris

#11 Brenden

Brenden

    New Member

  • Members
  • Pip
  • 3 posts

Posted 03 December 2012 - 05:33 AM

Hi Brenden,


When you press and hold the pushbutton on your Netduino Plus 2 while plugging into your PC via USB...what does it show up as in Device Manager? Is the driver installed?

Chris


Hi Chris,

It comes up as STM32 BOOTLOADER under Other devices. But there is no driver installed.

Brenden

#12 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 03 December 2012 - 06:00 AM

HI Brenden,

It comes up as STM32 BOOTLOADER under Other devices. But there is no driver installed.

Did you install DFUSE?
http://www.st.com/in...DEMO/um0412.zip

Also, have you tried pointing Device Manager to the drivers in this folder?
C:\Program Files (x86)\STMicroelectronics\Software\DfuSe\Driver

Finally--are you running Windows 8 by any chance? Some of the ST drivers aren't signed so you'll need to reboot with driver signing disabled _once_ to successfully set up Device Manager with the drivers.

Chris

#13 Brenden

Brenden

    New Member

  • Members
  • Pip
  • 3 posts

Posted 03 December 2012 - 06:44 AM

Hi Chris, Thanks very much - the driver did the trick. I have it up and running again! Brenden

#14 JBeck

JBeck

    New Member

  • Members
  • Pip
  • 7 posts

Posted 19 January 2013 - 10:32 PM

Hi, I have similar problems with deploying, turned out it didn't reply to pings either.

I tried holding the button while connecting, initially got the device as STM32 BOOTLOADER, then installed the DfuSe drivers and now see it as "STM Device in DFU mode" in the Device Manager, but MFDeploy doesn't find it (it does show up when booting normally, but doesn't reply to pings). Did I miss any steps..?

 

EDIT: should note that I got it working again by upgrading the firmware as per http://forums.netdui...-firmware-v422/

 

 

Note: maybe I fried the Netduino? I accidentally had a wire from D10 touch the MOSFET's drain (supplied by 5V) in a setup similar to this:

http://www.pretzello.../LED-MOSFET.png

Completely noob w/ electronics, hoping my little buddy is still OK...

 

Thanks /Jonas






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.