1 of 1 people found this helpful
Firmware corruption is an unlikely possibility. Far more likely is a correct driver not getting installed. List your operating system and where you are trying to install a driver from, and maybe someone can help.
Also, in a classroom setting, I would consider it mandatory to have at least one serial cable available. See Sergey's blog:
For me, this has been invaluable to see early boot messages. I don't use it often - but I really appreciate it when I do.
1 of 1 people found this helpful
I personally have corrupted my firmware but I was running a motor shield with just the USB power. Which is not a good idea.
I doubt you have corrupted your firmware. I agree with rmm200 that you most likely have a driver issue, assuming you have never been able to connect the COM port. A few people have had problems getting the driver setup correctly.
To know for sure if you have a firmware issue, the best way is to connect up the serial cable and watch the serial output. In my case, during boot I would see an EFI assertion, and the board would not boot to Linux. The board has to boot in order for the COM connection to work. You can build one, following the instructions on Sergey's blog, or you can buy one and wait for it to come in the mail. Amazon.com : SF Cable, DB9 Female to 3.5mm Serial Cable-6 Feet : Computer Serial Cables : Computers & Accessories
I linked to the serial cable, because they are difficult to find, and I have purchased that one, and it works.
I would recommend that anyone who has a Galileo should also have the serial cable. It is a very cheap debug tool.
Thank you, rmm220 and chofrock!
I have never been able to connect the COM port. I followed the getting-start guide to install drivers. I neither find Gadget Serial in Windows7-64bit nor ttyACM0 in Ubuntu12.04-64bit. I am not sure if it's a driver issue. Anyway, I will come back later with boot-up information from serial output. Thanks again for helping me.
You might want to start a little further back, and make sure your board is not simply DOA.
When you plug the board in with no other cables or SD card, a few things should happen.
A green LED labeled ON, right next to the Reset button, and an orange LED in the Ethernet jack should light immediately.
After about 10 seconds, another green LED labeled USB should come on.
If it does, you know a few things. You have a working power supply, and the firmware is running. It goes
through quite a bit to get to the point of lighting that USB one.
Next question mark is your USB cable - could it be bad. A serial cable is the best check on that.
Also try your board on a completely different computer if you can.
Thank you for your suggestions. I found that the ON LED and Ethernet jack light up while the USB LED never light up. I have another Galileo board which works just fine with my computer and cables. I also connected the bricked Galileo to my computer with a serial cable and did not see any boot information. I think that the problem should be corrupted firmware or something worse. Are there any approaches I shall try to fix it?
With good hardware, I don't think it is possible to Brick the Galileo. There are always ways to replace the firmware.
Unfortunately, all the easy ways require a running copy of the firmware. Anything more brute force requires the use of an SPI programmer like the DediProg.
If mine was in the state yours seems to be, I would try to find someone on this forum with a DediProg willing to flash it for me. Otherwise I would go the warrantee return route.
If the board does not boot, the only solution is to reprogram the flash with a dediprog. It is fairly easy to do, the only problem is the cost of the dediprog. I was lucky, I work in a lab that has several dediprogs, and I was able to borrow one for 5 minutes.
I am in the same position with Brickmaker. I suspect Brickmaker was not aware of the tutorials and Getting Started pdf and thus did not see that connecting a powered USB cable by itself would cause trouble. But looking at the latter instructions I see that it indicates that 5V power should be applied before making any other connection. This is the text:
Connect the 5V power cable to the Galileo board and to a power outlet. Note: Always connect the 5V power before any other connection.
When you consider that nearly all smart-phones are now-a-days powered through a 5V USB cable with exactly the same connector, it really is quite likely that someone would make that connection with the thought that it would be what the instructions say to do.
There is a tutorial that shows that the above does NOT mean to use the USB port for power. This is a rather obscure place to but something so mission-critical.
The instruction booklet that comes with the board says nothing about this.
So now I also wonder what happens if one does plug the unit in as indicated but then power is lost on the wall adapter. Will that also cause trouble? It seems like many uses for this technology stand a chance of having this issue (dead batteries, inadvertent power switch manipulation, ...)
I wonder if someone from Intel could provide a link to some helpful diagnostics for this sort of situation. I directed a question to others at Intel and was told that this is the forum primary support vehicle. If I am in the wrong place, then please advise.
I was planning to use this board in an instructional setting and cannot fully control the situation to be sure that the non-USB 5V source get's powered first or does not get unplugged. If there is no solution to this, other than to send the board back under warranty service, then I fear I am wasting my time developing an educational program since I will loose hardware with each time I have a new set of students.
If, indeed, there is nothing that I can do about getting a dead board working again, can someone suggest a set-up which I can implement for my students that would minimize the occurrence of this problem?
So far, there has been exactly one report on this forum of the firmware being corrupted by a low voltage situation, and that user was using a high current motor control shield at the time.
If I had a class full of students, I would give them a warning and then not worry too much about it. Very low probability of damage, and easily fixed with an ISP programmer.
But then I don't work for Intel, and I have no financial stake in this. Take this for what it is worth.
I was the idiot that left my motor controller connected. :-) I was playing with it, and got frustrated. I pulled out the power plug, but did not pull out the USB plug. Admittedly, this is a silly thing to do, and most people will not do it. Luckily I was able to fix it.
There is one more person that I have heard of. He was testing the Galileo with a battery. He left the battery plugged in overnight to see how long the Galileo would run.
Running the battery down to nothing, is something that people who are familiar with Arduino would not thing twice about doing. It is not ideal that this use case can (I believe it does not always happen) cause a firmware corruption.
So, if you hear about people using a battery to power their Galileo, make sure they build in some circuit to power off the device if the voltage gets too low.
Mine is also bricked with "ASSERT EFI ERROR". I had to plug out the power cable a few times (less than 5 times) and this happened.
This is a critical issue Intel should address asap for Galileo users. Intel team, Is this because of flash memory corruption or bad designed boot loader? I don't know where to start to debug this. Removing power can happen any time and we can't afford to re-flash the flash every time it happens. Smartphone doesn't brick by getting power or battery lost.
The only fix that I know of for the Assert EFI error is to flash the SPI via a dediprog. Luckily, I work in a lab that has several of them, and borrowing one for 5 minutes was not a problem.
Step by step instructions are here:
If you happen to be in the Portland area, I can fix it for you. l