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.