12 replies to this topic

[Dave M.]

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.

[Chris Walker]

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

[Dave M.]

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.

[Ellen]

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

[Dave M.]

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!

[Dave M.]

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.

[Dave M.]

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???

[Chris Walker]

Hi Dave,

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

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

[Dave M.]

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.

[Dave M.]

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!

[Dave M.]

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.

[Dave M.]

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?

[Chris Walker]

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?

The SecretLabs.NETMF.Hardware.dll and SecretLabs.NETMF.Hardware.Netduino.dll assemblies should work on all the boards.

Something is afoot

Chris