Intel Curie problems

Brainiac Bar
#1

I have been researching a problem I had with a CurieNano I bought from DFRobotics to find I have the same problem with a Genuino 101 I bought from LittleBirdBigE.

In fact, I note all sorts of people are having the same problem.

https://forum.arduino.cc/index.php?topic=387687.0

Problem being it seems there are batches Curie chips, assuming they have firmware pre-installed, are not talking to the Arduino IDE.

So, you can have the problem on Windows 10 and fix it by going to Windows 7. You can have it on Windows 7 and on Windows 10. It pops up when you are using Linux. It matters not if you are using a CurieNano or a Genuino 101. OR one person reports it won’t work on one Genuino board and will on another!!!

Driver disable then re-enable fixes the problem for some, for others it does not.

Manual driver re-install was fix offered by DFRobot but that does not fix the problem for everyone.

Curiously, the problem is the board will fail to upload a file BUT will happily respond to a Board ID request. The Port happily reports Genuino 101 etc. So IDE will talk to board to get board ID but will not upload files.

Reported problem on the console is:

Arduino: 1.6.12 (Windows 10), Board: "Arduino/Genuino 101"

Sketch uses 17,628 bytes (11%) of program storage space. Maximum is 155,648 bytes.
Starting download script...
Flashing is taking longer than expected
Try pressing MASTER_RESET button
ERROR: Timed out waiting for Arduino 101 on COM11
ERROR: Timed out waiting for Arduino 101 on COM11

So that is, brand new CurieNano from DFRobotics and a Genuino 101 from LBE, straight out of the box, fresh install of Arduino IDE, add curie core, open blink.ino and kaput. Various usb 2.0 ports that work fine with other arduino boards (with same cables) do not work with the curie based devices. I tried a different windows 10 computer, same problem for the CurieNano (still to try the Genuino).

Yes, for the brainiacs who have to ask, reset button was pushed - so what - doesn’t help me nor any other person so not sure why the prompt offers it as a fix.

The salient point is it should work out of the box and doesn’t.

No, no effort has been made to re-bomb the firmware as that would break the warrantee I suspect and won’t guarantee fixing the problem - not to mention that you have to build a ubuntu machine before you can do that and there goes another wasted weekend.

So, Intel or someone needs to come clean.

There is enough evidence this is happening to enough people to be able to factor out the usual complaints.

Has anyone really solved this problem? Not convinced.

#2

In fact, I found mention of a problem batch of curie chips or boards going out Julie and August? It this true? If so why weren’t vendors quarantining stock?

#3

An interesting and complex problem, thanks.

Reflashing the firmware would not affect your warranty under the Australian Consumer Law; it’s a normal function of this product while in the hands of the customer. But you’re right it won’t guarantee a fix until you’ve identified the root cause.

Unfortunately, the error message is not precise as to the cause. Very vague. Looks like the forums have mainly guessed or said what worked for them.

Before reflashing, figure out the version you have and if there is a later version. I wouldn’t reflash if there is no later version. From a quick browse of the source repositories, it looks like some firmware bugs were squashed. That means the firmware you have now might have bugs. Those bugs might not happen for everyone; but might for your scenario; of host computer hardware, cables, power supply, capacitors on the board, or phase of the moon.

From the schematic the USB port is directly attached to the Curie module, so firmware is critical to the upload. The SPI FLASH chip doesn’t have a secondary pinout on connectors, so the only easy way to write to it is through the existing firmware. But that brings up a Catch-22; if you can’t upload, then you might not be able to update firmware. The Burn bootloader may or may not be affected by the same problem; it depends on what the cause actually is.

In a fully kitted out lab, the next steps would be to capture the USB communications or SPI FLASH pins to find out what is actually happening. Even easier if there are some boards that work and some that don’t.

Feel free to ask here any further technical questions about the problem and how to get to the bottom of it.

But in the end, if you don’t get any joy, contact LBE or DFR directly to talk about a return or replacement.

#4

Except, it should work out-of-the-box.

DFRobotics said they would replace the CurieNano if it resembled a second unrelated problem. I am thus at an impasse there. I will try returning the Genuino 101 to LBE.

#5

Best of luck.

As an engineer I can’t expect that everything will work out-of-the-box. There are so many things outside the control of the manufacturer or vendor. Sometimes it’s a wonder that anything works. :grin:

#6

So, on behalf of LBE you are advocating accepting low quality items from them?

Or you are saying makers and supporting infrastructure businesses are exempt from consumer laws?

Or, are you saying we can only expect chips soldered to a board and not a functioning device even if money passes hands?

Are you then saying that is the difference between open-source hardware and commercial hardware?

I just heard a million wallets close.

#7

Chuckle. No, not at all. Do not accept low quality. Always work with your supplier to resolve issues. Have realistic expectations; engineering is complex, so it may take some effort. I’m still happy to help with the technical side of that effort if you want, but you seem focused on a different side of the problem; not my forte.

At OLPC I’m in charge of sustaining engineering for a laptop product, with thousands of parts; and I know what it’s like to get a batch of lemons, only to discover that the lemon maker didn’t even know how we could go wrong. Integration is always prone to error; and in your case I’m not certain your problems aren’t integration.

If you have a problem with your purchase, and you don’t want community support, you should approach your supplier about it directly and as soon as possible.

#8

I think the point about lemons is good. The open source hardware community can’t expect quality for the prices we demand so expect the Lemon Count will be higher.

The LBE approach, returns with a smile, is the saving grace AND the best example of how to handle the problems incurred by open source hardware quality issues.

I recommend buying your opensource hardware through LBE for that simple fact.

#9

Yes, I’ve no solution to your technical problem, but I don’t feel smug about it at all. Lots of problems I can’t solve.

#10

Not sure if this will help but I had been using a Genuino 101 successfully for several months and decided to try out the CurieNano equivalent. It couldn’t be identified by the Arduino IDE software until I upgraded the USB cable to a higher quality unit then everything worked fine with the driver downloading and the software I’d developed on the Genuino working wthout any modifications needed on the Curie Nano.

PeterO