Trouble downloading/debugging programs to Raptor

@ John - We’ve got a bench top test fixture that is wired with regular cables and has some but not all of the instruments the fully loaded go-to-sea version in the pressure housing has. We don’t see this issue very often, if at all, on the bench top unit. However, it won’t have the same exact noise environment the go-to-sea unit has. The bench top unit will be better in some ways, standard cabling and less instruments generating noise but it isn’t in a metal pressure housing which may act as a shield to some degree.

I am trying to narrow down this problem to something I can understand. I’ve had the same problem with the system in the pressure housing when I crack the end cap and use a regular USB cable to the dual USB module. I’ve nearly, but not quite, convinced myself it isn’t the cabling. I say not quite because it might be that my non-standard USB cabling is slightly more susceptible to noise and the problem may be a random result of how much welding or RF or ? is going on in my vicinity.

The one fact that seems most repeatable is that the download process hangs after it says “Ready” as I mentioned in my first post. The process has certainly hung up at other points but this is the most likely stopping point. If I hit the green arrow/download debug button it usually, but not always, will download properly on the 2nd or 3rd try.

Can you tell me what is going on just before and after the “Ready” statement is printed out?

Another question is: What can I be doing in my program that might be causing this problem?

For example, I had some 20-30 second Thread.Sleep statements in my program as a temporary way to see what some of my instruments were doing. When those statements were in, this problem seemed to be much, much worse. It happened almost every download and sometimes it took all kinds of reboot, power cycle, FezConfig, etc to get my program to download. I’ve replaced those Thread.Sleep statements with logic in my state machine that checks the machine time and does something when the desired period has elapsed and doesn’t put the thread to sleep. I only have one thread by the way. This seems to have made the problem much better but it still happens quite often.

Is there any reason to believe that a Thread.Sleep for more than 1 or 2 seconds will prevent VS from downloading a new program?

Thanks for your help, I really appreciate it.

@ Gene - If the problem rarely or never happens on the bench unit, then it seems likely that it is something related to the specific setup of the failing units.

Thread.Sleeps should actually increase the likelihood of VS being able to successfully download a new program. It’s impossible to say what you could be doing in your program that could cause this, it might not even be the program. The usual cause of failed downloads is the board locking up.

Can you erase the existing application on the board before attempting to deploy?

As for what goes on before and after “Ready.”, some settings are initialized and then the code actually begins execution. You can see the code at http://netmf.codeplex.com/SourceControl/latest#client_v4_3/CLR/StartupLib/CLRStartup.cpp around line 660.

So the latest factoid is I re-flashed the bootloader and the firmware on the Raptor, uninstalled everything on my PC and re-installed VS2012 and the latest SDK (2014 R3, I was at R2). In addition, I installed a new micro SD card since the few times I was able to download a program, it hung up trying to get the volumeInfo. I’ve been able to download reliably all day today but I’m not particularly optimistic this patch will hold. In addition, the microSD card that didn’t work on the Raptor works fine on my PC. Here’s my latest question.

Is it possible that I’m corrupting the flash somehow? I do have an Iridium modem (NAL research A3LA-RG, http://www.nalresearch.com/IridiumHardware.html ,
7 Watts transmit power, 1.6 GHz) in close proximity to the rest of my electronics but other than that nothing unusual.

Still baffled

@ Gene - It is possible that you are corrupting the flash. That sort of thing is really hard to pin down though. To see if it is the modem causing problems, try to run in your enclosure for awhile without the modem and see if the problem persists.