Error: Failed allocation for 434 blocks, 5208 bytes

I get this error every so often when my program is running. About every 5 - 10 minutes.

However, if I run the following code I do not get it. I run this command every time through the loop.

Debug.GC(true)

Three things.

1) I assume that error is memory related, correct?
2) Is it okay to call the garbage collect all the time?
3) Is there a better fix?

Thanks for the help.

Hi smarcus3, If you're getting this message with .NET MF 4.1, then calling Debug.GC(...) as you are doing is a good workaround. If you're running .NET MF 4.2, this error should not occur (and if a message appears, it's just letting you know that it's doing automatic garbage collection). Chris

I am running 4.2, so its just letting me know its doing GC. Thanks though I think the message should say something to that effect though.

I am running 4.2, so its just letting me know its doing GC. Thanks though I think the message should say something to that effect though.

Good feedback. Maybe we can tweak NETMF so that it says something else. Or only shows that info if requested by the developer.

Chris

With the word 'failed' it makes the message seem like something is messed up. Thanks for the quick reply Chris.

With the word 'failed' it makes the message seem like something is messed up.

Thanks for the quick reply Chris.

Hello Chris,

Sorry for bringing back this thread, but I am also experiencing something similar when making some fast input readings using interrupts.

My scenario is similar to this thread: http://forums.netdui...goodbye-net-mf/

After upgrading to firmware 4.2 I started to get these "Failed allocation for X blocks". To verify if my app was still running I put some LED blinking, but it seems the app is crashing.

I would like to confirm if my thinking is correct:

As my test app does not allocate much objects but it does use interrupts, I suspect the memory is missing due to the "nested interrupts". In other words, during the interrupt handling my application receives a new interrupt request that is also handled before the first interrupt is completely treated. So after some time there will be no RAM enough for saving such a huge stack, correct?

I tried to change the InterruptMode to InterruptLevelHigh instead and the error messages were gone. This way I would "avoid" having nested interrupts as I reactivate it only at the end of the handler. Obviously I will loose input pulses this way...

Igor.

Hi Igor, Good thinking. The interrupts should be queued (and NETMF will actually drop some if you get too many, to prevent overflows). But yes, if you get too many queued up...you could eventually run out of memory. This is more of an issue on Netduino Plus 1 than Netduino Plus 2, but it's true for any devboard. Chris P.S. Are you getting any glitching (extra state switching) on your input? Or is it an accurate pulse?

Hi Igor,

Good thinking.

The interrupts should be queued (and NETMF will actually drop some if you get too many, to prevent overflows).

But yes, if you get too many queued up...you could eventually run out of memory. This is more of an issue on Netduino Plus 1 than Netduino Plus 2, but it's true for any devboard.

Chris

P.S. Are you getting any glitching (extra state switching) on your input? Or is it an accurate pulse?

Hum...so there is no "nesting" on the interrupt handlers. In fact they are queued an stays on the queue until the previous interrupt handler if finished, right? Like a FIFO behavior.

Pulses seems to be accurate. With a 2KHz input pulse (generated by a PWM on another Netduino) I got stable readings. Should it make difference if I set InterruptPort to use pullup?

Thanks,

Igor.

Hi Igor,

Pulses seems to be accurate. With a 2KHz input pulse (generated by a PWM on another Netduino) I got stable readings. Should it make difference if I set InterruptPort to use pullup?

If your incoming pulses are push/pull (rather than open drain) then a weak pull-up shouldn't change things.

Chris