If I cancel the deploy and unplug the Netduino and then hit 'start debugging' while the device is booting, the code gets downloaded to the netduino without error, however, VB gets hung up. The status reports 'The debugging target is not in an initialised state; rebooting'. It hangs here and gets no further.

Hi and welcome,

I had this issues with VSCS2010, I found that if it sticks at the Debugger not initialised, simply pulling the USB and re-plugging would move things along.

Also, you stated that you could not deploy and had a communication error. Could i ask if the blue LED was constantly on at this point?

If so it may be that previous code has caused the Netduino not to boot correctly. Which would explain why rebooting it whilst trying to deploy works, as the ND does not get chance to run the existing code as new code is downloaded straight away.

I either had to do as you mentioned, or use MFDeploy to wipe the development area on the flash.

Hope this helps.

Regards,
Stuart.

I brought my work Win7 laptop home and tried it on that and everything works fine, so I guess it's actually a WinXP issue.

If the problem is so far specific to your windows XP machine, When you plugged the device in for the first time, did you allow XP to install the driver its self or did you manually choose the driver in the SDK folders?

I had problems with the one my WinXP machine found from the internet (MS Update i think). Once i uninstalled and installed the SDK Drivers, i didnt have as many problems (the ones i was left with were silly user error type things which caused the device to need to be wiped )

Has anyone got any experience with these units?

DSO Nano v2

Hi Stuart Crawshaw,

Welcome to the boards!
In MFDeploy, if you click Target->Device Capabilities, what does it output?
And which firmware version did you had before, and to which version you're trying to upgrade?

Hi,

Thanks for the reply. If i run the Device Capabilities option i get:

HalSystemInfo.halVersion:               4.2.0.0
HalSystemInfo.halVendorInfo:            Netduino (v4.2.0.0 b1) 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 b1) by Secret Labs LLC
ClrInfo.targetFrameworkVersion:         4.2.0.0
SolutionReleaseInfo.solutionVersion:    4.2.0.0
SolutionReleaseInfo.solutionVendorInfo: Netduino (v4.2.0.0 b1) by Secret Labs LLC
SoftwareVersion.BuildDate:              Jun  8 2011
SoftwareVersion.CompilerVersion:        400902
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

which does seem like it has updated. But what is concerming me is that it may not be fully updated/stable as all the output from MFDeploy is not there.

I have updated from the stock FW when i bought the unit, to the 4.2 beta 1 version (including the bootloader), then tried a non-beta (4.1.0.6 i think) and that had the same output result in MFDeploy and now I have tried again with the beta (as the above output would suggest.

But as mentioned before, due to the output (or lack thereof) i am dubious as to whether it has updated correctly.

Hi Stuard,

When you went from 4.1.x to 4.2b1 you also updated the bootloader. When you tried to go back to 4.1.x, did you wrote back the older bootloader as well?

I did indeed. And just to confirm, i verified the written bootloader with the file using SAM-BA.

Hi Stuart,

It looks like you're all set. Sometimes MFDeploy needs a quick disconnect/reconnect of your device after updating...the Device Capabilities info (and the fact that your Netduino is booting into the TinyCLR runtime) means that it updated correctly.

Please go ahead and deploy some apps to your Netduino. If it gives you any troubles, we'll be here to help sort it out. The good thing about Netduino is that, since it's open source, you can erase and reflash it any way you'd like...and there's a community of nice folks here to help if you run into troubles.

Chris

Awesome, thanks confirming that all is ok.

Just to confirm, MFDeploy doesnt need to give a full output for the update to be successful? (as I tend to only get "Chk s" or "Chk signa" but never a full line of text...

Yes, please try that.

Also...we created a patch in the v4.1 firmware which helped fix this issue. We removed the patch in v4.2, since Microsoft incorporated a permanent fix for the issue there. If you are running into new issues with 4.2, we'd love to know more...so we can update the bug ticket at netmf.codeplex.com.

Thanks for helping test 4.2!

Chris

Running 4.2, i still get the Debugger not in an initialized state, rebooting message.
Hitting the reset button does nothing, pulling the power and re-inserting it seems to move things along.

MFDeploy sometimes doesn't print the entire text...there's some buffering going on. But the .NET MF runtime does a bit of signature checking each time you boot it. There are multiple levels of verification built in.

Chris

Thats good to know,

Seems I am good to go. i just deployed the very well known "blinking LED" code and it deployed and run successfully.

I have however noticed that when deploying, i will sometimes get a message along the lines of "Debbugger not in an initilized state; rebooting" but it does not seem to do anything.

It it just a case of disconnecting the device/pushing the reset button at this point and trying again?

Hi All,

I am currently having a major problem updating the firmware on my netduino.

Here are the steps i am taking:

• Open MFDEPLOY.exe
• Click Ping (Get response "Pinging... TinyCLR")
• Browse for update files and click Deploy
• Progress bar says the following:
  
• Connecting to device
• Connecting to TinyBooter
• Checking Signatures
• Erasing 0x0010C000
• Deploying ER_FLASH
• Checking Signature
• Executing Application

The progress window then closes and i am left with an output of:

Pinging... TinyCLR
Chk siCh

If i try anything else in MFDEPLOY after this, i get "Pinging... Error: No response from device"

If i disconnect it from power and then reconnect, i can then ping it but i dont think the Firmware is properly installed.

Any clues?

Thanks.

That's true indeed.
Consider that any heat sink close to the soldering point will cool the iron temperature. That could give a bad melting and a matt/crystalled result. Along this way, a regulated iron guarantee always a good soldering.
Cheers

Thanks for the heads up.

Im currently using a variable temperature gas soldering iron, it seems to do the job quite well. I manage the tip temperature with an infrared thermometer.

The DS1820 i am referencing is a 3-pin package similar to that of the 2n2222 transistor. By techniques i mean how would you do it, do you have any tips or tricks etc...

Thank you all so much for your input, this has been very helpful. Thank you Dan for the links you posted, I was looking for something like that. Especially since the croc-clips would act as a kind of heat shunt to protect the component being soldered. Regards, Stuart

Hello Everybody, General question to go out ot everyone regarding Soldering Techniques.... When soldering small components, for example: the wires on to the pins of a DS1820 sensor, how do you go about this? Ill also open this question up to everyone to share any other soldering Techniques they use when soldering other things too! Thanks again guys, Cant wait to see how you get yours done! -------- Stuart.

A few months ago I published a post about multiplexing:
http://forums.netdui...h-the-netduino/

Also HD44780 LCDs can work over 74hc595 IC's.

Thanks, i shall have a read through that post,

I currently have the LCD working via a 74HC595 using the SPI bus, so its just the buttons i need to get working in a conservative fasion.

So, Ill have a read and get back to you.

Thanks again.

Hi all,

Here is the outline,

I want to have a menu system accessible by buttons on my project. The display will be a 20x4 LCD Display and there will be 6 buttons as follows:

• UP
• DOWN
• LEFT
• RIGHT
• OK
• CANCEL

Now the basic idea of how these would work is have an interrupt port setup for each button (but thats 6 ports!). So now the question,

How could i achieve this, but only use the minimal number of ports?

I though about using a PISO Shift Reg, but then remembered it would need a clock etc and someway for the ND to know that data is coming in (i think).

I then there is the Matrix style setup but i would only save 1 pin (2 cols and 3 rows = 5 lines).

Any suggestions, fancy IC's or fancy components that will let be achive this goal?

Thanks for your continued support.
Stuart

Back in the 90's the Parralax stamp used 1 pin for 8 switches.
Bad fritzing but will give you an idea.

In this example (cant find single pin of gnd plane )
The resistors are connected to an analoge in pin and the capacitor end is connected to gnd (or however the netduino handles it)

The whole thing reads as a potentiometer so is simple to work.
Going by what I have lurned so far you may be able to drop the cap.

I hope this helps with your button issue.

Thats an interesting idea, thank you.
Ill keep this in mind, wouldn't this idea how ever require some slight pre-programming of the values per switch and also, if i press multiple switches at once, would this not cause an issue?

You will get an error because both will try to initialize the SPI bus.

The code I have would (in thory) use a centralised "shared" SPI bus (a static property of the main program, initialized on startup). Could i not modify it to work with the "shared bus"?

If you want to combine that LCD driver with other SPI devices (which is the case in my sample above) you need to use another LCDTransferProvider. I got one ready for that. Will upload it later today.

If i understand that correctly, i couldnt use the multiplexing solution as well as have an LCD on the SPI bus?

I read your post and it looks AMAZING! Just want i was looking for, but on a smaller scale .

I've always used Yenka (was previously called Crocodile Clips) that I still have a student licence for from school .. 10 years ago. If there's an open source sim that anyone would recommend I check out,that would be great.

Just for info, If you didnt know already, Yenka has a free license for Home users

Hello,
after some months I have restarted work with Netduino.
I have connected it to my PC in VMWare Virtual Machine and when deploy the application on the target, the debugger hangs and display "the debugging target is not in initialized state, rebooting...".
From real PC (not virtual machine) all works fine.
I have upgraded the firmware to last version 4.1.6 but nothing changed into virtual machine.

Why ?

Thanks,
Paolo.

Couple of questions,

When the netduino is conectec to VMWare, is the connection and exclusive connection to the guest or can the host see it as well?

If it is exclusive, what happens if you un-plug and replug the netduino whilst VS2010 is saying "the debugging target is not in initialized state, rebooting..."?

Hi guys,

I havent been able to find the answer to a question i have been asking myself.

Does this only apply to the DS1820 sensors when used in Paracitic power mode ONLY? as my understanding is, it was a limitation because of the timings being in milliseconds and anything longer than 970uS would cause a power-on reset to occur?

So, the question is, do i need this native driver if i an wiring my DS Sensors in a non-paracitic circuit?

Thanks,
Stuart.

Anyone?

The 1-Wire firmware is built with the 4.1.1 Beta 1 FW already. Were you testing the 4.2.x FW? As I understand it, the reason you have to have the 1-Wire support in the firmware is because 1-Wire communication is too fast for the managed code to handle.

-Valkyrie-MT

Hi,

Yes i am running the 4.2.x FW. I originally wanted to know if the OneWire limitation was for paracitic mode only, but you have answered that question for me.

But yes, it does seem that the managed code is too slow for onewire to be used without native support.

the reason i want to use the 4.2.x FW is its I2C support as i want to include an I2C EEPROM chip i have to save user settings (such as high temp thresholds etc for a thermostat type setup).

HI Stuart,

An I2C EEPROM also works on 4.1.x firmwares. Code sample can be downloaded at http://forums.netdui...e-i2cbus-class/

Even the ones where repeated START signals are required?

Not entirely sure I understand your question, so I'll try to answer with some observations/facts.

• You must have this native driver to directly communicate with 1-wire devices (parasitic or not) with the Netduino (alternatively, you can use components like those from Peter Anderson)
• With this firmware, I can read from a mix of DS18B20, DS18S20, DS18B20PAR sensors some connected in parasitic mode (only 2 wires - ground and 1-wire signal) and others connected with the 5VDC (non-parasitic). I currently have 5 sensors connected - 3 are not parasitic and 2 are parasitic. That works fine.
• On occassion, I will get a bad read (think 1 in 50 reads) for whatever reason (possibly because I don't have a MOSFET as recommended), but with the CRC check, you always know, so I handle them easily. And usually, it won't happen twice on the same sensor.

-Valkyrie-MT

Thats a shame, i was hoping to write my own class to handle the DS1829 sensors so i could continue to use/test the 4.1 FW.

Hi guys, I havent been able to find the answer to a question i have been asking myself. Does this only apply to the DS1820 sensors when used in Paracitic power mode ONLY? as my understanding is, it was a limitation because of the timings being in milliseconds and anything longer than 970uS would cause a power-on reset to occur? So, the question is, do i need this native driver if i an wiring my DS Sensors in a non-paracitic circuit? Thanks, Stuart.