I've confirmed by going back and forth between 4.2.1.1 and 4.2.2.2 that the latter update causes I2C to not work again.

Thanks, Dave.  Can you suggest other ways for me to determine what's going on?  What I am seeing is that, running the same project, firmware 4.2.1.1 works, but when I run 4.2.2.2, the SDA and SCL lines stay high.  Each time I reprogram, I follow the instructions and disconnect / reconnect the hardware.  The only thing odd in the entire process is that firmware upload verification crashes the ST application.

I could be wrong, but this update seems to have broken I2C.  When my SDA/SCL lines were inactive under 4.1.1 while my program was running (verified with my logic analyzer), I found the I2C firmware fix update and loaded it.  Once I did that, my I2C bus started to work.  But in the process of debugging a STDFU app crash, I found out from another member about firmware 4.2.2, so I loaded it.  And now my I2C bus doesn't work again.  Has anyone else out there noticed this?  I'm going to downgrade the firmware again and will let you know what happens.

[*]the LockObject has no sense, because you are locking just the I2CBus instance creation, but the further usage is not thread-safe at all;
[*]consider two threads using the I2CBus: they don't work properly.
[/list]The thread-safety on drivers like I2C or SPI is a much more complex task, and cannot be solved with a simple lock.

 

Can you clarify why his usage of the lock isn't thread-safe?  Other than possible performance considerations with an exclusive lock, why wouldn't his approach work, since the read and write operations are contained within the lock?

 

But in general I agree - the code isn't well written at all and probably unnecessary as you noted.

 

I don't think Mario was saying that the code wasn't well written at all, he had some suggestions.  However, if you are going to say this, it would be more helpful to explain to the OP what you thought was lacking!

I updated today because I needed to get I2C working (was previously using 4.2.1.0 and logic analyzer wouldn't see anything on SDA/SCL). Anyhow, the process worked fine and I was able to upload, but during verification the app keeps crashing. I ended up power cycling the N+2 and MFDeploy shows the following:  

HalSystemInfo.halVersion:			   4.2.0.0HalSystemInfo.halVendorInfo:		    Netduino Plus 2 (v4.2.1.1) by Secret Labs LLCHalSystemInfo.oemCode:				  34HalSystemInfo.modelCode:			    177HalSystemInfo.skuCode:				  4102HalSystemInfo.moduleSerialNumber:	   00000000000000000000000000000000HalSystemInfo.systemSerialNumber:	   0000000000000000ClrInfo.clrVersion:					 4.2.0.0ClrInfo.clrVendorInfo:				  Netduino Plus 2 (v4.2.1.1) by Secret Labs LLCClrInfo.targetFrameworkVersion:		 4.2.0.0SolutionReleaseInfo.solutionVersion:    4.2.1.1SolutionReleaseInfo.solutionVendorInfo: Netduino Plus 2 (v4.2.1.1) by Secret Labs LLCSoftwareVersion.BuildDate:			  Nov 30 2012SoftwareVersion.CompilerVersion:	    410894FloatingPoint:						  TrueSourceLevelDebugging:				   TrueThreadCreateEx:						 TrueLCD.Width:							  0LCD.Height:							 0LCD.BitsPerPixel:					   0AppDomains:							 TrueExceptionFilters:					   TrueIncrementalDeployment:				  TrueSoftReboot:							 TrueProfiling:							  FalseProfilingAllocations:				   FalseProfilingCalls:						 FalseIsUnknown:							  False

Honestly, I do not understand what each line item means, but it shows 4.2.1.1 in several places, so do you think it flashed ok? EDIT -- ok, my guess is "no". I went ahead and debugged my app, and I2C started to work. However, the 2nd time I went to run my app, it failed to deploy. This happens to me *a lot*, and I used to just disconnect / reconnect the N+2. However, this often results in a BSOD, so I started to disable the device in the Device Manager, unplug / replug, then enable the Netduino. Unfortunately, now it just come up as "Unknown Device". Since Windows already knew what the N+2 was and now it doesn't, all I can assume is that something is messed up internally now. Any ideas?

Dave,

 

This is what I get from my Netduino Plus 2 that has been updated to 4.2.2

HalSystemInfo.halVersion:               4.2.0.0...Profiling:                              FalseProfilingAllocations:                   FalseProfilingCalls:                         FalseIsUnknown:                              False

Hope this helps,

Chuck

 

There's a 4.2.2?    I usually don't keep up with updates unless something is busted.  I found 4.2.1.1 via my I2C problems and searching.  So I guess I'll try 4.2.2 now and see what happens.  Thanks for posting!  I'll compare your info to mine once I'm done.

Bummer, I cannot update my firmware because STDFU no longer recognizes the device.  I held Reset and plugged in, then ran STDFU and nothing shows up in the device list.  I'll try rebooting, since that actually worked for me on another firmware upgrade issue in the past with the Netduino Plus.

Sorry, I should have just tried rebooting before that last post.  I did that and it was able to reflash.  However, it is still crashing after the upload.  I'll check my settings vs. carb's, and will try debugging my app again.  Perhaps I should try the x32 version even though I'm on x64.

 

EDIT -- everything seems to be working even though verification crashed.  I can run my app again!

@H07R0D cool, thanks, I'll take a look at it.  That's the other one I had found but never looked at it.  I'm glad to hear that it works.

 

The main problem I've come across with the JSON parser in this thread is that it doesn't deal with nested values too well.  I was going to hack in a fix, but haven't gotten around to it yet because I keep thinking that it might be better to just rewrite parts of it.

 

Oooh..  I just looked at the code for the one you posted and it does serialization as well.  Awesome!  Thanks again.

Hi everyone, just wondering if there is a status update on this project. I was looking around for a JSON parser for the N+2 and this is only one of two projects that I have found so far. I have confirmed that the latest code available fails all of the tests. Because it still looks like Fabien doesn't have time to fix the parser, I started to work on it yesterday. I am making some progress, but while I understand exactly what Fabien's design intends to do, there are little gotchas here and there that trip me up. Besides saying "thank you" for providing us with the code, I have to say "THANK YOU" for providing unit tests with this project, Fabien. That's the only way I'll be able to verify that things are working. So far, I have the first two unit tests working. I'm now ironing out problems with the serializing of arrays of strings in the third test case. And one of the outstanding issues is that my modifications to the Find() method that has the ArrayList outparam unintentionally made it output an ArrayList of JSONObjects and not Hashtable, so I temporarily changed the unit tests to take this into account by casting in the loop.

So.... how are things going, Kristoffer? 

 

It turns out that I'm trying to get my L6470 eval kit working with both the Netduino Plus and mbed LPC1768, and I have had no luck with either.  I actually posted here recently: http://forums.netdui...h-time/?p=50999

 

I'm glad I found your post because it might help me to get further along.  One thing that might be tripping me up is the issue with CS having to be toggled after each byte.  It does say that in the text, but when I implemented mine, I used Figure 18 (timing diagram) instead.  This timing diagram says the exact opposite, if I'm reading it correctly -- that you can clock the MSB to LSB out with CS kept low.  How confusing!

 

I also have a different SPI configuration than you.  From the datasheet, I interpreted the clock's idle state to be high, and to look for a low-high clock transistion for the data.  Therefore, my config looks like this:

SPI.Configuration l6470 = new SPI.Configuration( Pins.GPIO_PIN_D2,                                                 false,                                                 1,                                                 1,                                                 true,                                                 true,                                                 100,                                                 SPI_Devices.SPI1);

Note that I am purposely running at 100kHz because my logic analyzer doesn't have enough memory to be able to reliably capture data.

 

On the mbed side, everything I send to the L6470 gets echoed back, which is weird.  On the NP, I get weird bit shifting effects where a bit shifts from the MSb to the LSb when I just send NOPs continuously.

 

If you have gotten yours to work, then I'm going to try using your config parameters to see if I get better results.  It would be great to hear how your L6470 project is going now!

I'm an idiot.  I misread the timing diagram and blindly interpreted MSB as MS BYTE, even though the CK line clearly implies that this is MS BIT.    Ok, things are getting better now on my end.  I'll look into the special hardware hack mentioned earlier.

Can anyone comment on nakchak's comment regarding the usage of events for connections / disconnections?  While I'd love to do that, I've gone through the API reference and used Intellisense to peek at the members, and it sure looks to me like Poll is the only way to get incoming data.

The Allocation Error is from your SDcard.
When you read from or write to the card mostly the first time after power up.

BTW, no SD card was installed in my N+. When I find some time I'm going to look into the RAM usage as suggested by Chris.

Hopefully, someone can give me a clue as to what's going on here... I finally found time to work on this project again, and I have isolated my problems to the instantiation of my SerialPort object, which is created with the following line:

_port = new SerialPort( port, baudrate, Parity.None, 8, StopBits.One);

This results in the following error message, which is printed about 16 times when I step over the creation of the object.

Failed allocation for 39 blocks, 468 bytes

This code works perfectly fine on my N+2... but surely the N+ can use the SerialPort in MF 4.2 without memory issues???

The Allocation Error is from your SDcard.
When you read from or write to the card mostly the first time after power up.

Ah, I will need to check the N+ when I get home! I know I tried the SD card many months ago, and I could very well have forgotten to take it out. Thanks!

Hi Dave,

Netduino Plus 2 has a LOT more memory than Netduino Plus 1. It's very possible that your code is running out of memory at home.

The "failed allocation" may not mean that you've run out of memory...but it does mean that NETMF is having trouble allocation memory. Do you see an OutOfMemoryException anywhere?

Can you walk through your code really quickly, and see where it stops working?

BTW, you can use the following line of code to see how much RAM you have left:

Debug.Print(Debug.GC(true));

Chris

Thanks, Chris. I'll definitely check on the GC and see what my RAM constraints are. I do get an OutOfMemoryException at the point where I call SerialPort.open() (only if I run without breakpoints). If I single step, I can get past the open() call, but then the code still doesn't work reliably. The behavior is very unpredictable.

I'm working on a project at both the office and at home. At the office I have a N+2, and at home I have a N+. My project works fine at the office, but when I checked out the code at home and tried to run it, the behavior was vastly different. In other words, it didn't work.

I figured that if I ran 4.2.x of the firmware on both, as well as 4.2.0.0 of the CLR, it should work. However, when I run my project at home, I immediately get an error like the following one in the output window:

Failed allocation for 24 blocks, 288 bytes

This usually prints over and over again. I read somewhere that it's technically not a fatal error, but what happens is that eventually the program crashes, and on a line in my code that doesn't make sense ( SerialPort.open() -- why would it fail when it's one of the first-constructed objects?). Other times, it runs, but extremely slowly and only occasionally seems to be able to pull bytes out of the serial buffer.

I was hoping that someone could enlighten me on this issue. Perhaps something from MFDEPLOY will make it really obvious what I'm doing wrong:

Work setup (working on N+2) -- output window messages + MFDEPLOY

Work

Create TS.

 Loading start at 806a238, end 8085f74

Assembly: mscorlib (4.2.0.0)

Assembly: Microsoft.SPOT.Native (4.2.0.0)

Assembly: Microsoft.SPOT.Hardware (4.2.0.0)

Assembly: Microsoft.SPOT.Net (4.2.0.0)

Assembly: System (4.2.0.0)

Assembly: Microsoft.SPOT.Hardware.SerialPort (4.2.0.0)

Assembly: Microsoft.SPOT.IO (4.2.0.0)

Assembly: System.IO (4.2.0.0)

Assembly: Microsoft.SPOT.Hardware.PWM (4.2.0.1)

Assembly: Microsoft.SPOT.Hardware.Usb (4.2.0.0)

Assembly: SecretLabs.NETMF.Diagnostics (4.2.0.0)

Assembly: SecretLabs.NETMF.Hardware.Netduino (4.2.1.0)

Assembly: Microsoft.SPOT.Hardware.OneWire (4.2.0.0)

Assembly: Microsoft.SPOT.Time (4.2.0.0)

Loading Deployment Assemblies.

Attaching deployed file.

Assembly: AmuletLibrary (1.0.0.0)

Attaching deployed file.

Assembly: SecretLabs.NETMF.Hardware (4.2.0.0)

Resolving.

The debugging target runtime is loading the application assemblies and starting execution.
Ready.

The thread '<No Name>' (0x2) has exited with code 0 (0x0).



MFDeploy (work)

Pinging... TinyCLR
HalSystemInfo.halVersion:               4.2.0.0
HalSystemInfo.halVendorInfo:            Netduino Plus 2 (v4.2.1.0) by Secret Labs LLC
HalSystemInfo.oemCode:                  34
HalSystemInfo.modelCode:                177
HalSystemInfo.skuCode:                  4102
HalSystemInfo.moduleSerialNumber:       00000000000000000000000000000000
HalSystemInfo.systemSerialNumber:       0000000000000000
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
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

Home setup (not working on N+):

Home

Found debugger!

Create TS.

 Loading start at 1542e0, end 16c5dc

   Assembly: mscorlib (4.2.0.0)

   Assembly: System (4.2.0.0)

   Assembly: Microsoft.SPOT.Hardware.SerialPort (4.2.0.0)

   Assembly: Microsoft.SPOT.IO (4.2.0.0)

   Assembly: System.IO (4.2.0.0)

   Assembly: Microsoft.SPOT.Hardware.PWM (4.2.0.1)

   Assembly: SecretLabs.NETMF.Diagnostics (4.2.0.0)

Loading Deployment Assemblies.

Attaching deployed file.

   Assembly: SecretLabs.NETMF.Hardware.Netduino (4.2.1.0)

Attaching deployed file.

   Assembly: AmuletLibrary (1.0.0.0)

Attaching deployed file.

   Assembly: SecretLabs.NETMF.Hardware (4.2.0.0)

Resolving.

The debugging target runtime is loading the application assemblies and starting execution.
Ready.


MFDeploy (home)

Pinging... Pinging... Pinging... Failed allocation for 23 blocks, 276 bytes
TinyCLR
Pinging... TinyCLR
HalSystemInfo.halVersion:               4.2.0.0
HalSystemInfo.halVendorInfo:            Netduino Plus (v4.2.0.1) by Secret Labs LLC
HalSystemInfo.oemCode:                  255
HalSystemInfo.modelCode:                255
HalSystemInfo.skuCode:                  65535
HalSystemInfo.moduleSerialNumber:       

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
HalSystemInfo.systemSerialNumber:       FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
ClrInfo.clrVersion:                     4.2.0.0
ClrInfo.clrVendorInfo:                  Netduino Plus (v4.2.0.1) by Secret Labs LLC
ClrInfo.targetFrameworkVersion:         4.2.0.0
SolutionReleaseInfo.solutionVersion:    4.2.0.0
SolutionReleaseInfo.solutionVendorInfo: Netduino Plus (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

Any help would be greatly appreciated! I would normally just shell out another $60 and not worry about it, but since my project is OSS, I'd like it to work on the Netduino/Plus/2.

Hi Dave,


Yes, Netduino Plus can use SerialPort without issues. As long as you have enough RAM available. If you create a single-line application with just that line...do you still get the error?

Also...which port is 'port'?

Chris

It seems to vary from run to run. Sometimes I get the error when I create the port. Other times, the error comes up after the creation. And even if the program keeps running (i.e. VS2010 doesn't crash first), the behavior is odd. My serial data event handler usually captures data very, very slowly.

Here's some test code I'm running right now:

Debug.Print( "creating serial port");
_port = new SerialPort( port, baudrate, Parity.None, 8, StopBits.One);
Debug.Print( "setting serial port read timeout");
_port.ReadTimeout = 100;
Debug.Print( "opening serial port");
_port.Open();
Debug.Print( "flushing serial port buffer");
_port.Flush();
Debug.Print( "registering serial port data event handler");
_port.DataReceived += new SerialDataReceivedEventHandler(serialPort_DataReceived);            
Debug.Print( "RAM left: " + Debug.GC( true) + " bytes");

The amount of RAM left is always 21300 bytes. "port" is "COM1", and baudrate is 115200.

I decided to try out my Netduino as well, since I have one of those here at home. I updated the firmware to 4.2.0.1, and the behavior is different. The first time I ran it, it froze when attempting to create the SerialPort. All subsequent attempts have failed, where VS2010 is frozen when saying that the device is "rebooting...". I have unplugged and reconnected the Netduino after each attempt, just to prevent BSODs. Weird!

Awesome, I figured it out. Apparently, the breadboard's power cable came out a little. While the N+ doesn't need this power to run, I do need it to power the MAX232 chip. So having an unpowered MAX232 seems to have wreaked havoc on the behavior of the N+. This didn't solve my problem with the standard Netduino, so I'll start looking at that next.

Got the Netduino to work. Since I'm not (yet) using any of the ethernet capabilities of the N+ and N+2, for now I have removed the assembly references to SecretLabs.NETMF.Hardware and SecretLabs.NETMF.Hardware.Netduino. That said, why would adding those references cause the Netduino to not boot correctly, even if I'm not using any of the classes in those namespaces?

I have this same problem in my application, using a Netduino Plus 2. Temporary workaround: Open the Device Manager, then disable the Netduino. After the failure tones, you can unplug and reconnect the Netduino. You'll get those failure tones again, but when you re-enable the Netduino, VS2010 will be able to deploy again. It's a little annoying, but I wonder if it has to do with buggy application code. In my particular case I think that could be the reason, and it's definitely tied to COM1 somehow. I'm in the process of working on a library that communicates with an external peripheral over RS232, and when my parsing fails, the external device keeps sending data. It seems like in this case, the Netduino freaks out and can no longer be programmed until I reset it with the above steps.

I think you missed the last line inside the loop since you tried to assign a bool to a delegate

haha!! You are correct, I *completely* missed that line. Guess I should have written this in the compiler before posting.

or +verbose:

public static void Method_6()
        {
            while (phcontroller.Read()==true && method_state_6 == true)
            {
                ph.Write(false);
                Thread.Sleep(1 * SecondMs);
                ph.Write(true);
                Thread.Sleep(5 * MinuteMs);

            }
}

or ++(really unnecessary)verbose:

public static void Method_6()
        {
            bool phState = phcontroller.Read();
            while (phState == true && method_state_6 == true)
            {
                ph.Write(false);
                Thread.Sleep(1 * SecondMs);
                ph.Write(true);
                Thread.Sleep(5 * MinuteMs);
                phState = phcontroller.Read();
            }
}

These two methods are not equivalent. The last one only Reads once. Did you mean something like this instead, which is definitely way too verbose?

public static delegate bool PhStateDelegate();

public static bool CheckPhState()
{
    return phcontroller.Read();
}

public static void Method_6()
{
    PhStateDelegate phState = CheckPhState;

    while (phState() == true && method_state_6 == true)
            {
                ph.Write(false);
                Thread.Sleep(1 * SecondMs);
                ph.Write(true);
                Thread.Sleep(5 * MinuteMs);
                phState = phcontroller.Read();
            }
}