1) Can you upload and run sketches without the SD card inserted?
2) Are you using the SD image Intel provided, or did you build your own from the BSP?
Having had the problem occur again, when not using an SD card image (just the 0.7.5 firmware), I stumbled across a fix: I assigned a different COM port # to Galileo, using the Device Manager. Oddly, doing this on one PC fixed the problem for the other PC too -- I can't explain that one.
A few more findings, in case it's of help to anyone...
- One reliable way of causing the hanging problem (using the 0.7.5 firmware and no SD card) is to disconnect the USB cable, then press the Reset button on the Galileo. The Galileo hangs at that point, and trying to upload a sketch (after plugging in the USB cable again, of course) causes the upload to hang. The sketch I'm working with uses the SPI pins, so perhaps that plays a role in the problem.
- The "no such file or directory" error when uploading a sketch occurs when the lsz.exe process is hung - killing that process gets rid of that error
- I can now fix the "hanging when uploading" problem (without changing the COM port # or rebooting the PC) by:
1. Exiting the Arduino IDE
2. Killing the lsz.exe process
3. Rebooting the Galileo (which, because of the bug in the 0.7.5 firmware, requires unplugging power cable)
I'm pretty sure that I tried that earlier, and it didn't work -- that's when changing the COM port # worked.
Yes, I was able to upload sketches when not using the SD card.
I was using the plain vanilla 0.7.5 image downloaded from Intel, not my own BSP.
Edit: Come to think of it, it's not plain vanilla: I did an "opkg update / opkg upgrade" from AlexT's repo, which is based on the 0.8 BSP. I also installed ntp from that repo. So, the problem is likely self-inflicted. D'oh!
It is worth getting the 0.8.0 or 0.9.0 firmware just for the reboot fix. Unfortunately, you have to build your own unless some kind soul like Alex posts one you can download.
I had the same Troubles when uploading my sketch. Funny Thing is, it worked the day before without any Problems and today I had this issue. (There was a Windows update in between, but could not see why this would influence the Arduino sketch download)
I could fix it by killing the process, but reassigning a new COM port helped. The only Thing I want to add is, that I also had to reselect the right COM port in Arduino IDE.
BTW: Are you using SPI on Galileo? I Need to, but SPI does not work on my Galileo - I get no SCK on PIN 13/SPI Header Pin 3
I still see the sketch upload problem from time-to-time. It usually occurs after I haven't used the Galileo for a few days, on the first sketch upload. The fix is still the same: kill lsz.exe and bash.exe then reboot the Galileo. After that, I can upload sketches all day without the problem reoccurring. It's a nuisance, but a minor one.
Yes, I've used SPI on one project, and it did work. I'm using it with a set of 8x8 LED matrices controlled by MAX7219s. That project's still running, so it works reliably.
I didn't have any problems with the clock on pin 13, but I remember running into a problem initially with the SS pin not firing, then making a change based on some sample code posting in a Sparkfun article: https://www.sparkfun.com/news/1360.
I manually set the SS pin (pin 10) before and after each SPI write, e.g.:
void SPIWriteString(char * str, uint8_t len)
for (int i=0; i<len; i++)
I also copied some SPI initialization code from that same article. I don't think this change made any difference, since these settings are probably the defaults for the SPI library, but I left them in the code:
Otherwise, I'm using the standard Arduino SPI code and it seems to be working, including the clock on pin 13.
Hope that helps,
Hi Dan, thank you very much for that Information. SPI is working now, - at least SS, MOSI, and SCK. Though there is a pretty high delay between SS and Data traffic. Could this be a Problem for a SPI Device?
I still dont get any MISO from my device and as there is no protocol inherent ACK it is hard to tell if a device can communicate or if there is a Problem with the device itself.
Let me clarify something to windows users. If you serial port has a number high, like 30, 32, 25, you have two options:
1) Use a different USB COM port to force windows to re-enumerate the serial with a new number
2) Or using the Device Manager, select COM Ports and using the COM serial port of your device, go to "Advance" and force to change the port number manually... use always low numbers..
It is a bug from Windows and not the board at all.
another think that must be done.. please, remove all hidden serial ports from your Windows machine.. it is a very annoying bug from Windows that affects the communication and detection at all..
For detailed instructions how "to clean your ports" please check this link: Overview | How to Find Hidden COM Ports | Adafruit Learning System
This solution worked to solve my problem. This issue killed a few productive hours so thanks for posting the part about killing lsz.exe (I had 3 processes running).