I just reflashed my device and I deployed my application to the Cerb40 and it worked perfectly. Then I made a code change and when it goes to deploy, it says this:
“Incrementally deploying assemblies to device”
And that is all. It never reports the size of the deployment. Then, after about a minute VS2010 gives up and reports “An error has occurred: please check your hardware.” It may be that the previous program ended with an OutOfMemory exception and blocks subsequent deployments. At this point if I open MFDeploy, I get “Pinging… Error: No response from device”. Pulling the power appears to just execute the program again, which actually runs, but without the debugger attached.
The only way I have found to resolve this is to reflash tinybooter and the firmware. There must be a better way. One interesting bit is that I have never before seen the “Incrementally deploying assemblies to device” message without it being immediately followed by the deployment size. BTW, my deployment size is around 86 kb.
What version of the firmware are you using? Is it 4.2.3.0 or 4.2.3.1? The latter firmware fixed some issues with interrupts and the Ethernet version of the firmware. You can download the latest Cerb-Family firmware from the first post here: http://www.tinyclr.com/forum/topic?id=8498
Interesting. I pulled out an older Cerb40 that previously had worked perfectly for months and when loaded with the latest firmware, does the exact same thing as the other Cerb40. The older Cerb40 is powered by the soldered on Voltage regulator and the newer cerb40 is powered through the 3.3VDC pin which reads right at 3.29 - 3.30 VDC. But, I just flashed my CerbuinoBee and it is working perfectly with the RC2+ firmware (4.2.3.1). I have loaded apps several times now with no issues on that. I’ll keep changing bits and pieces until I narrow in on a culprit. I might try to load the Beta firmware and see if it goes away with that, but then I have to remove QFE2 and reinstall QFE1 on my PC…
OK, I just reverted everything back to 4.2 QFE1 Beta and I still have the same problem. I consider this good news. Because the only constant appears to be the computer. So, I think my next step is to install Windows 8 64-bit. I have been running Windows 7 32-bit because wireshark didn’t work with Win8, but that’s fixed, so I’ll just do that and see what happens…
Argh. I just installed Windows 8 64-bit (earlier than I had planned) to see if that would fix my problem. To my surprise, it did not help. Same problem with Win8. The only thing I have not tried changing is my computer hardware. I will try a complete different computer tomorrow. I am also seeing the problem on the CerbuinoBee I can’t imagine this is a hardware issue though, so I am not optimistic…
OK, progress. Deployment and debug worked on another computer with the Beta firmware and a new/never used Cerb40. So, I did a variety of experiments. Now, I believe that the application I was loading was preventing subsequent connections from the debugger. I am not sure why yet. Loading a simple blinking LED app works on both computers. My next step is to break apart the program and try to find the cause of this. My leading guess is that the app runs out of memory because I am seeing “failed allocation” warnings, although the app reports 22kb free. I wrote an app that uses all the memory, but it did not block the debugger, so I am still investigating.
OK. A lot more progress. I decided to rebuild my app, piece by piece, until I reproduce the problem and last night I did it. When I added back my logging class and called it the app died and subsequent debug sessions would not load. I enabled/disabled the code 4 times to verify that this was the source. Also, previously the app had run all night flawlessly. So, my Log class is a simple class that writes to the SD card, based on the code here: http://www.tinyclr.com/forum/topic?id=8556&page=2#msg84904
At this point, I have two observations.
If you run in the debugger, execute MountSD(), and stop your program before the UnmountSD(), the problem is reproduced every time in my app. Note: I tried mounting and unmounting for each read/write and that started to throw exceptions on the second write with some HRESULT of E_FILE_IO or something similar.
Either StreamWriter or File.OpenWrite leaks memory under certain circumstances. When it happens, a “Failed to allocate…” message appears in the Output and your program is dead within about 15 seconds or less. The consumption of memory is rapid.
The confusing bit is that I was not able to reproduce the issue from the code sample above. As soon as I have a reproducible example, I will post it.
I can’t imagine this is a hardware issue though, so I am not optimistic…