SOLUTION FOR C.H.I.Ps THAT DO NOT BOOT


#1

CHIP cannot boot

Some of our backers have reported that their C.H.I.Ps do not boot or cannot be rebooted reliably. We are taking these reports very seriously and have identified the issue.

These C.H.I.P.s cannot boot due to data corruption in the U-Boot partition on C.H.I.P’s NAND flash storage. It’s important to note that there is no physical damage. Basically this means this booting/rebooting problem can be fixed permanently by rewriting the U-Boot partition.

This can be achieved by reflashing the C.H.I.P entirely (see http://docs.getchip.com/chip.html#flash-chip-firmware). Make sure to pull latest version of the CHIP-tools from github.
NOTE: Flashing our Debian-GUI image is only proven possible on a native Linux computer (sorry, we’re working on this as well).

We have repaired many units using this fix and stress tested them by continually rebooting them over several days.

Flashing the GUI from Mac OS or Windows is not currently supported as C.H.I.P is not recognized as a fast boot device by these operating systems.

We are working on a user-friendly NAND repair tool that runs on Linux, Windows and Mac OS so all users can easily recover their C.H.I.P. We are aiming to have this completed and available this time next week.

This software solution has also been implemented in our factory flashing process, so future C.H.I.Ps produced will not have this issue.

Overheating problem


There are reports about C.H.I.Ps that suddenly stop working and shut off.

We tried to reproduce this at NTC HQ and have succeeded in the following ways:

  1. Operating C.H.I.P on a weak USB power supply (less than 1000mA) and run a task that requires very high CPU power.
  2. Operating C.H.I.P with a 2A power supply and plug in a gaming keyboard with a lot of LEDs.
  3. Plugging a keyboard, a mouse and USB thumb drive into C.H.I.P using an unpowered USB-hub.
  4. Putting C.H.I.P in a reflow oven and increase the temperature up to roughly 80 degree Celsisus (~180 Fahrenheit).

Based on our testing, cases 1-3 are not related to temperature but operating C.H.I.P outside of its specified power capabilities. Concerning case 4, C.H.I.P was working reliably even outside of its recommended environmental temperature, up to 75.5 °C.

Some users have report it is necessary to led C.H.I.P cool down to be able to reboot it after
a shutdown. This can be explained with the temperature dependency of bitflips in the NAND and will no longer be necessary once C.H.I.P has been repaired using the solution described above.

DO NOT PUT YOUR C.H.I.P INTO THE FRIDGE OR FREEZER.

Summary


We apologize to the users who received a C.H.I.P that cannot boot reliably and recommend reflashing using the latest CHIP-tools. We understand this is a complicated progress and are working on a more user-friendly solution.

If you cannot get your C.H.I.P recovered by reflashing, please contact our customer support at ahoyahoy@nexthing.co and we’ll make sure to get you a working C.H.I.P.

So far we cannot confirm any overheating problem with C.H.I.P, but we keep looking into this.


Rewriting only the U-Boot partition
(Solved!) Flash CHIP troubles. I've tried a lot of things, but still need help
Flash Chip from VBox Ubuntu on Windows?
NVRAM corrupting on reboot
Heat problems affecting boot / reboot
CHIP not being recognized when plugged in via USB
CHIP not being recognized when plugged in via USB
CHIP just died after 30 minutes
CHIP won't start
CHIP won't boot after a restart
Heat problems affecting boot / reboot
Feature request of chip-update-firmware.sh
NTC improving NAND-on-Linux
What are the official mounting holes for CHIP?
#2

This s gonna help a lot of people :slightly_smiling:


How to reinstall the OS?
[SOLVED] Chip xfce4 log in
#3

To summarize for flashers:

cd CHIP-tools
git checkout chip/stable
git pull

To flash bare-linux buildroot:
./chip-update-firmware.sh

To flash bare Debian with no GUI [-f is optional and only works on Linux]:
./chip-update-firmware.sh -d [-f]

To flash our full custom Debian with GUI [-f is required, and only works on Linux]:
./chip-update-firmware.sh -d -f -b stable-gui


#4

#5

Awesome! Maybe you push a Kickstarter update so everybody who is not gonna to visit this bbs still gets informed and not angryly frustrated …! :wink:


#6

@Dr.K To be clear, in cases 1-3 above, is this when C.H.I.P. is solely powered via the micro USB B-type connector only (no battery is connected via BAT and no power is supplied via CHG-IN) ?

Can you confirm that when C.H.I.P. is powered via CHG-IN with a minimum 5V 1A, this is not a concern and C.H.I.Ps will not suddenly stop working and shut off?


#7

To expand upon this, PLEASE PLEASE DO NOT PUT YOUR CHIP IN THE DIRTY WET FRIDGE OR FREEZER. It will introduce a lot more unknowns, and make further diagnosis much more difficult. Using an electronics safe cold-spray such as MG Chemicals 403A or an ESD-safe canned-air duster would be the only suggested way to test rapidly cooling CHIP. That said, in our tests, we haven’t actually seen any out-of-spec heat buildup on the NAND, however the bitflip problem @Dr.K mentioned is temperature dependent. Cooling the NAND (not the processor) seems to help reduce the number of bit flips, though the correct solution is in software. For reference, the AXP209 is a real honeybadger of a chip, and safely operates up to 130ºC – so despite it being hotter than the R8, it is still perfectly OK.


#8

If the CHIP does not register as a serial USB is it still possible to reflash?


#9

jginaz, it should be possible, yes. If you find otherwise, just email the support team and we can get you a replacement.


#11

I got two chips, one boots fine, the other stops at UBOOT (viewed from UART) like so;
U-Boot SPL 2015.10 (Nov 25 2015 - 20:46:36)
DRAM: 512 MiB
CPU: 1008000000Hz, AXI/AHB/APB: 3/2/2

…it does have a nice sticker saying “Such Pass” on it… however clearly that’s not true. Did anyone actually test these things or did they just slap a sticker on them?
As a guy who does hardware for a living I don’t understand you can ship boards (…and obviously a lot of them) that get three lines into UBOOT, hang and that’s a “pass”…

Nice board, great pricepoint, but “Such Fail!” on the testing. Best of luck getting over this hump, I feel your pain.

[update]
Doing the reflashing thing from an Ubuntu 14.0.4 VM (under vmware) - it gets past UBoot flashing, creating sparse image etc and to “waiting for fastboot” but by that point the VM has lost the USB device (which clearly re-enumerated and displayed
"going to fastboot mode
musb-hdrc: peripheral reset irq lost!"
on the uart output) … hm. Ah well, that’s what you get for being an early adopter :slight_smile: Looking fwd to the “easy” reflashing util.


#13

Are these problems hardware or software problems?


#14

A shame you didn’t include jumper wires with the CHIP…

Guess I gotta bust apart an old hard drive or motherboard and my soldering iron to make my own…


#15

It costs $9! They have to make money! They are a company. Just be happy it costs $9 and not $10 or even $15. Even if it did I would still buy it. It has wifi and bluetooth le built in for crying out loud!


#16

anyone far enough along to do this can you print your uboot env or at least enough to see what the bootcmd is?


#17

dwelch67: Your fastboot timeout looks similar to my problem… At that point in reflashing the board should be reenumerating as a fastboot USB device (do you have a UART on there to see progress?) anyway try the reflash commandline without the “-f” … that got me past a similar problem, it’s now (very slowly) downloading an image


#21

@dwelch,

There’s currently a bug with the flashing script. When you see == write ubi ==, the CHIP is actually still saving the image to NAND. Please flash again, but leave the CHIP plugged into the flashing computer for 3 minutes before unplugging and/or rebooting.

– Ben


Can someone tell me EXACTLY what to install and download so I can FLASH my CHIP?
#22

Ubuntu 15.10 x86_64 - AMD Phenom 16 GB RAM :

[username]@[hostname]:~/CHIP-tools$ ./chip-update-firmware.sh -d -b stable-gui -f
waiting for fel…TIMEOUT
ERROR: please jumper your CHIP in FEL mode then power on

Exact same result with two different CHIPs and two different USB cables. Tested both with my Nexus 5 phone. Took this photo with the phone and downloaded off the phone using the same USB cable I’m trying to flash the CHIP with :

Don’t have any jumper wires, I’ve got a broken bone in my hand and not game to handle a soldering iron - I can’t imagine there’d be a low voltage contact issue with the jury-rigged jumper wire in the photo…


#23

@greg23 : It (they - I got two) cost me a bit more than $9… $143… and so far I’ve received little value - and wasted a lot of time…

At the time I pledged I was employed - I’m now unemployed and seeking VALUE for MONEY.


#26

@dwelch67
Do you have a UART connection? If you do, it’ll show the output of what’s happening during the flashing process, and you can see if/when it’s writing to NAND.

@UnixOutlaw
The FEL jumper there looks a little precarious. Do you have a staple or a paperclip you could try instead? Otherwise, maybe try pulling back half of the wires on each side, and twisting them? That might be a little difficult with one hand though.

Also, it can be connected to any GND on CHIP, I usually jump the FEL with the GND that’s just four pins away.


#31

@computermouth or @Dr.K -

The most recent U-Boot firmware pulled via the Flash tools doesn’t have a tag on GitHub. It has a build date of Dec. 22, as opposed to the Nov. 25 tag date of the “production-1.0” tag in the U-Boot repository. Can you please confirm what commit on the repository actually is built in the Dec. 22 U-Boot build?