4.1.5 CAN Problems with FEZ Mini

NETMF & Gadgeteer
1

I upgraded to 4.1.5 and am having some problems with the new CAN firmware on the FEZ Mini. It works fine on my FEZ Cobra but when I run it on the Mini I get the following when I reference the GetMessages method. This occurs for every message in the buffer. My code worked fine on the Mini with the old 4.1.3 firmware. Do I need to go back a rev or is there something else I can try?

GC: 2msec 48852 bytes used, 15528 bytes available
Type 0F (STRING ): 60 bytes
Type 11 (CLASS ): 2052 bytes
Type 12 (VALUETYPE ): 60 bytes
Type 13 (SZARRAY ): 1392 bytes
Type 15 (FREEBLOCK ): 15528 bytes
Type 16 (CACHEDBLOCK ): 120 bytes
Type 17 (ASSEMBLY ): 10584 bytes
Type 18 (WEAKCLASS ): 96 bytes
Type 1B (DELEGATE_HEAD ): 324 bytes
Type 1D (OBJECT_TO_EVENT ): 144 bytes
Type 1E (BINARY_BLOB_HEAD ): 29568 bytes
Type 1F (THREAD ): 1152 bytes
Type 20 (SUBTHREAD ): 144 bytes
Type 21 (STACK_FRAME ): 1116 bytes
Type 22 (TIMER_HEAD ): 144 bytes
Type 27 (FINALIZER_HEAD ): 72 bytes
Type 31 (IO_PORT ): 72 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 1680 bytes

2

Where is the problem? This is the GC output!

3

It’s when I call GetMessages either from the DataReceivedEvent or from a thread where I check the ReceivedMessagesCount. It doesn’t matter how many messages I get, one or all, I get that GC output for each message that I get. It hangs the app and I have to do a Reboot and Stop from MFDeploy to erase the app from memory.

4

Just took it back to 4.1.3 and it works like a champ.

Let me know if I can try something. I’d like to get it working on the latest firmware.

5

As Gus said, what you showed was just the output from the GC. That in itself is not a problem. Search here if you really don’t care, and turn that off. But that is only the output of the GC, the GC will still run.

If you think you have a problem with your app freezing or doing something untoward with the later firmware, then the first step will be to cut back your full app into a succint demonstration app that can show this, so that anyone can assist in diagnosing.

If I take a step back, did you do all the important things once you upgraded your SDK and firmware? That means installing the new GHI SDK, opening your existing project, ripping out all old references to the GHI components, and re-adding them (the alternative is to open a new project and then copy in your code, but rip/replace is probably easier)

6

If you see the problem at the same time GC runs then you are using a object that is no longer referenced and so the GC is collecting it. It may “seem” to work on old SDK but you have a bug that will surface sooner or later.

Read this section slowly please http://wiki.tinyclr.com/index.php?title=C-Sharp_Level2#Garbage_Collector

7

I did do all the steps to upgrade to 4.1.5, even verifying all the GHI and Microsoft modules using MFDeploy.

The questions I have are:

  1. Why do I get the GC messages with 4.1.5 and not with 4.1.3?

  2. Why do I get the GC messages only with USBizi and not with EMX?

  3. Why do I get the GC messages only with the call to CAN.GetMessages?

I’ll take it back to 4.1.5 and post the MFDeploy output so you can see what all is loaded. I’ve already removed all my code except for the CAN. I’ll also turn off GC Output to see if that makes a difference.

I did notice that on the EMX board the CANDataReceivedEvent didn’t seem to play very well with the SerialDataReceivedEvent in my Bluetooth module. I didn’t investigate this further because I’m more focused on the USBizi device but this may become a factor if I turn back on BT in the Mini.

8

You are asking the wrong questions :slight_smile: These will not help in finding answer at all but I will answer you anyway

  1. Coincidence? 4.1.5 uses less RAM? There is really no answer for this but GC is EXPECTED to run and this is very much normal behavior

  2. USBizi ram= 42KB …EMX RAM = 16000KB!! You need to use 1000x more RAM before GC needs to run!

  3. Because it happened that the system needed RAM and didn’t find any so it fired the GC.

You do not need to check the version or post here as you are not having problems! GC will run and this is expected. Did you read the section I pointed out? Did you specifically look at “losing resources”?

9

Have you actually tested 4.1.5 CAN on the FEZ Mini? I’ve been playing with this all day with no success both in my app and in your Example project. It kinda runs but invokes the GC like crazy. When I break into the app, it eventually throws an Out of Memory error. If I try to step after the breakpoint it goes into a GC loop. And this is your Example code. My CAN bus is a Cummins engine simulator. In my app, I kinda got it to work but when I turned on Bluetooth, it locked up and died. After every run of the app (yours or mine), I have to Reboot and Stop, then Erase with MFDeploy to get access to the device.

My point is that 4.1.3 runs perfectly. 4.1.5 is killing the Mini. I’ve already blown two days on this and have to get on with my project. I need 4.1.5 to work for our production units. We haven’t talked yet, but the numbers we’re looking at are very large, very soon.

10

New SDK has an all new CAN driver and so it maybe using more RAM which is pushing GC to run…etc.

If you are not happy with 4.1.5 then please keep on using 4.1.3 but note that this is not recommended. The right way to fix this is by finding the error in your code and fixing it, the error that is causing GC to cleanup a needed resource. I bet if you force GC on 4.1.3 you will have same problem Debug.GC(true);

If you feel there is a problem in our firmware then please provide a small test application that demonstrates the problem. GHI can also debug you complete application for you through our consulting service.

11

I have found the reason for the excessive GC messages and lockups of my application on the FEZ Mini (USBizi) with version 4.1.5.

First, Version 4.1.3 defaults to GC messages off so you never see them. Version 4.1.5 defaults to them on so you see them all the time. Even so, I am getting a lot more GC messages in 4.1.5 than 4.1.3. I suspect this is due to the larger footprint of 4.1.5. Don’t know though how this affects performance.

But the real reason for the problems I was having is that the default receive buffer size in 4.1.5 is too large for my app. I was using the 2 parameter constructor and not explicitely setting the receive buffer size. When I upgraded to 4.1.5, and ran the app, it spit out all those GC messages and subsequently died. After a lot of time and frustration, I finally figured out that it must have something to do with memory and started playing around with setting the receive buffer size in the constructor. I’m now running with a buffer size of 100. It’s working but does output quite a lot of GC messages. I’m going to closely monitor this to see if it’s impacting performance or longivity.

My application by the way consumes 1504 RAM, 19900 ROM, and 5086 Metadata with a total assemblies size of 51776.

Another important change I learned is with the BusOff error. If you want your app to connect to your CAN device after the app starts, you must implement the CANErrorReceivedEvent with the BusOff error issuing the Reset command. In 4.1.3 this was done automatically but in 4.1.5 you must use this method.

One glitch I did discover is with using the CANReceivedDataEvent along side the SerialReceivedDataEvent. My app uses Bluetooth with the SerialReceivedDataEvent. When I added the CANReceivedDataEvent, the new CAN class stopped receiving data as soon as serial data arrived via the SerialReceivedDataEvent. Also, in some instances, the GC went crazy and the app locked up. I solved this by using a polling thread in my Bluetooth class instead of the SerialReceivedDataEvent.

An important ‘gotcha’ that you need to be aware of is in debugging. When you debug, you will find that while your receive buffer size may be good for running your app, as soon as you break and step or run, the GC may kick in and go crazy. Your app will hang or you may get an OutOfMemory exception. For my app, I could run with a receive buffer size of 100 but when I broke into it, it died. I had to set my receive buffer size to 1 or 2 in order to debug. If your app does crash because of this you need to do a MFDeploy Reboot and Stop followed by an Erase command in order to regain access.

Another annoying ‘feature’ is that after debugging the app, I have to disconnect and reconnect the USB in order to start another debug session. This only occurs if I’m connected to my CAN device and receiving data.

I haven’t verified how much of this, if any, occurs on the FEZ Cobra but when I have time, I will do that.