5 replies to this topic

[mrcity]

Hi folks, I'm having problems communicating with the Netduino Mini -- in particular, Visual Studio .NET doesn't want to talk to it. My computer is hooked up via Bluetooth to a Firefly serial bluetooth adapter over COM10, and I'm hooking the Netduino TX & RX pins on COM1 (ports 1 & 2) to the RX & TX pins on the Firefly. I've been able to communicate with the Firefly to program its settings (115200 baud, 8 bits, 1 stop bit, no parity, DTE). I've also seen the boot sequence of the Netduino itself over RealTerm, but it never responds to any commands (does the initial program listen for any commands?). After boot, it's constantly sending signals over the wire such that the TX/RX status light is going crazy and RealTerm complains of a buffer overrun even at 115K. Now here's the kicker: I can use RealTerm to communicate OK with my Firefly (and the Netduino, I'm guessing, based on seeing the boot messages), but when I hit "Build & Deploy" on Visual Studio, it doesn't ever sync up. Ok, well I've gotten it to "work" twice in maybe 8 hours, but it doesn't seem to load the program and the debugger crashes. If I don't follow a very specific sequence of events, VS won't connect, and RealTerm will give me an "Apro exception" until I either unplug or completely reset the Firefly. Any suggestions? Thanks, Stephen

[hanzibal]

Does programming using a wired RS232 connection work? A stupid question: Why do you want a Bluetooth <-> RS232 link for programming?

[mrcity]

I haven't tried a wired RS232 connection because all my computers are a little too modern to have that as a direct capability. I'm also too cheap to go & buy a USB->RS232 or FTDI cable. I guess the second best alternative would be to find my Arduino Duemilanove & try to use its FTDI capability -- the key word there is "find" it... Or if the regular Netduino has an FTDI chip I could use to program the Mini, that'd be better. If I do get it to work over BT, then I'll definitely make an instructable. I'm suspecting the primary problem is with .NET because the serial communication through RealTerm looks OK, aside from all the nonsense sent after Netduino boot-up. Thanks!

[Bendage]

I have successfully used a BT adapter with no problems. Have you been able to ping it and read the firmware with MF Deploy successfully?

[mrcity]

Hi Bendage, thanks for the reply and your hint. I got into MF Deploy and it sees the device OK. Here is the output from "Device Capabilities." HalSystemInfo.halVersion: 4.1.2821.0 0 HalSystemInfo.halVendorInfo: Netduino Mini by Secret Labs LLC 61 HalSystemInfo.oemCode: 34 0 HalSystemInfo.modelCode: 177 61 HalSystemInfo.skuCode: 4098 0 HalSystemInfo.moduleSerialNumber: 00000000000000000000000000000000 0 HalSystemInfo.systemSerialNumber: 0000000000000000 0 0 ClrInfo.clrVersion: 4.1.2821.0 0 ClrInfo.clrVendorInfo: Netduino Mini by Secret Labs LLC 0 ClrInfo.targetFrameworkVersion: 4.1.2821.0 127 0 SolutionReleaseInfo.solutionVersion: 4.1.0.5 127 SolutionReleaseInfo.solutionVendorInfo: Netduino Mini by Secret Labs LLC 0 72 SoftwareVersion.BuildDate: Nov 7 2010 0 72 SoftwareVersion.CompilerVersion: 400771 0 FloatingPoint: True 72 SourceLevelDebugging: True 0 ThreadCreateEx: True 72 0 LCD.Width: 0 76 0 LCD.Height: 0 76 LCD.BitsPerPixel: 0 0 AppDomains: True 51 ExceptionFilters: True 0 IncrementalDeployment: True 51 SoftReboot: True 0 Profiling: False 0 0 ProfilingAllocations: False 0 ProfilingCalls: False 50 IsUnknown: False At times when I'm not interacting with the Mini, it spits out a bunch of extraneous output as such: Buffer OVFLW Buffer OVFLW Buffer OVFLW 61 61 0 0 MSdbgV1<nul><c6><c1><vt><f0>QA6y<soh><nul><nul><nul>L% Buffer OVFLW Buffer OVFLW I've verified that all my devices are communicating over 115200 bps, 8 data bits, no parity, 1 stop bit, and no flow control. Based on how I'm actually seeing legible text, the communication channels seem to be set correctly. Perhaps I'll just update or completely reflash the firmware. Thanks, Stephen

[Bendage]

Based on your symptoms it has always been the case in the past that a locked up app running on the board does not allow VS to respond to it. Have you erased the current app on the mini and replaced it with a simple non thread locking app just to test a simple deployment? When all else fails I just kill the board and reinstall from the bootloader.