Load cardtool failed phoenixcard ошибка

04-03-2016, 05:06 AM
(This post was last modified: 05-05-2016, 04:11 AM by Keex.)

Hi,
while trying to burn Android or RemixOS images to my SD card I encountered the problem, that the «Burn» process in PhoenixCard canceled at random points during the burn process, with just saying «Error» in the log. This could happen right after formatting, or it could burn some steps and then cancel. Hitting Burn multiple times could lead to different points of «Error».

One method that did work out for me in the end was the one described by user «Wurstbrot» in this thread of the lemaker.org forums:

Quote:Hi there,
I’m using a Laptop with Windows 8.1 with in-built card reader and had the same Problem burning an image and stumbled upon a pretty easy solution:

First you have to format your sd-card with sd-formatter (hint (Keex): SD Card Formatter), method full erase and format size adjustment ON. Thats in case you tried several Android installs, obviously there remain some leftovers.

Then turn on PhoenixCard (V310_20130618), select method «Startup» and press format.
Then you press «burn» and then…. Usually in 19 out of 20 tries I get an error.

Now here is the catch: when you get the error, eject the sd-card. Wait a few seconds till it says
«No drive present» or such, then Re-enter the card and hit «Burn»….
This time it will perform perfectly.

I’ve tried this several times now and it works everytime!

Hope I could save somebody some time,
cheers

Steps:

• (Last resort, shouldn’t be necessary): Perform complete card clean with Diskpart, as described below)

• (Optional: Format SD Card using SD Card Formatter (if it says that Full Erase wasn’t supported for your card and instead did Quick Format, don’t worry))
• Start PhoenixCard (version 3.10 on Pine64 Downloads page works)
• Select correct drive letter and image
• Select «Startup» method
• Click Burn (not format to normal!)
• Wait for error
• Leave PhoenixCard running, and pull out the SD card from the computer (i pulled out the card from my reader, not the whole reader)
• Wait for PhoenixCard to say «No devices found» or similar. Usually happens instantaneously. If nothing happens, start again at the top and try pulling the whole reader instead.
• Push the card/reader back into the reader/PC
• Select correct drive letter
• Click burn.

This time it should perform the Burn process successfully. I personally had no luck whatsoever, tried multiple readers and images, but this worked on the first try. I tested it with the RemixOS image «pine64_B2016022702_1000MB_LAN.img». The OS started successfully on the Pine64+ 2 GB.

I am running Win10 64bit. I did not use any compatibility modes or something along those lines.

Edit. For when it doesn’t work:
I noticed that it doesn’t work directly every time. Here is what MAY help:

Perform complete clean of the SD card using Diskpart

• Be careful! You may damage the system if you select the wrong disk to work on!
• Seriously: Select the wrong disk to work on and you will wipe your system or data HDD partition!

• Windows Key+R (Run program) -> Diskpart (possibly accept UAC)

• In the shell type in: list disk <enter> (always hit enter at the end)
• Find the number of the disk that is the SD card (usually one of the last, e.g. check the size)
• Type in: select disk 3 (instead of 3 the number you found)
• Type in «list disk» again, just to make sure: the active disk (aka the one that is to be cleaned) is marked with a *. Make SURE it is the SD card. All data on it will be wiped relentlessly and with no remorse. If you select your normal HDD, you will loose all data on it!!
• Type in: clean
• Type in: create partition primary
• Close the shell

The continue with the steps above.

Edit:
Andrew2 pointed out, that you could run into problems with this method, because the PhoenixCard errors are probably related to faulty read/write processes during the flash and you can end up with errors on the card.

(04-04-2016, 04:23 AM)Andrew2 Wrote: Then: Phoenix Card has some built-in checks relying on checksumming to verify whether some parts have been written correctly (does not apply to the largest part unfortunately). In case Phoenix Card throws errors then this is a sign of data corruption maybe caused by a bad (faulty or counterfeit) SD card or an SD card reader starting to corrupt data (well known problem with some USB readers that start to overheat and corrupt data after a certain amount of constant writing —> use USB2.0 when first connected to USB3.0, check the whole setup with one of the two tools below).

04-04-2016, 04:23 AM
(This post was last modified: 04-04-2016, 05:47 AM by Andrew2.)

(04-04-2016, 03:16 AM)Keex Wrote:

(04-03-2016, 02:08 PM)tllim Wrote: Thanks on the tips. I also use Diskpart to clean the SD partition. Just need to be extra careful not to clean your harddisk. My advise after launch diskpart, first action is immediately select to your SD card disk number to avoid any accidental mistake.
.. TL

You are right, I added another point in the steps to check the selected disk.

Sorry, but you’re collecting here wrong/misleading ‘information’ (you should keep in mind that while Pine64 might be new the whole ‘Android on Allwinner hardware’ story is a bit older and everything you might wonder about is known since years).

When Phoenix Card is used in startup mode then the first step is cleaning out the first sectors of the card and writing an appropriate MBR + partition table to it that matches the card’s size. Therefore using any tool like Dispart or SD Formatter is not only useless but dangerous instead (since you might wipe out your harddisk instead). It will later always look like this on the card (the first partition’s size adjusted to use all available disk space):

Then: Phoenix Card has some built-in checks relying on checksumming to verify whether some parts have been written correctly (does not apply to the largest part unfortunately). In case Phoenix Card throws errors then this is a sign of data corruption maybe caused by a bad (faulty or counterfeit) SD card or an SD card reader starting to corrupt data (well known problem with some USB readers that start to overheat and corrupt data after a certain amount of constant writing —> use USB2.0 when first connected to USB3.0, check the whole setup with one of the two tools below).

So instead of trying to workaround these issues ejecting/reinserting the card (which might work if speed negotiation between host and card reader might be adjusted — check Device Manager) the only reasonable strategy is to stop at the very first error and check card reader with inserted SD card using H2testw or f3. Anything else is simply fooling yourself and most probably creating an Android image containing bit flips that lead to all sorts of random problems later.

04-04-2016, 08:13 AM
(This post was last modified: 04-04-2016, 08:19 AM by Keex.)

(04-04-2016, 04:23 AM)Andrew2 Wrote:

(04-04-2016, 03:16 AM)Keex Wrote:

(04-03-2016, 02:08 PM)tllim Wrote: Thanks on the tips. I also use Diskpart to clean the SD partition. Just need to be extra careful not to clean your harddisk. My advise after launch diskpart, first action is immediately select to your SD card disk number to avoid any accidental mistake.
.. TL

You are right, I added another point in the steps to check the selected disk.

Sorry, but you’re collecting here wrong/misleading ‘information’ (you should keep in mind that while Pine64 might be new the whole ‘Android on Allwinner hardware’ story is a bit older and everything you might wonder about is known since years).

When Phoenix Card is used in startup mode then the first step is cleaning out the first sectors of the card and writing an appropriate MBR + partition table to it that matches the card’s size. Therefore using any tool like Dispart or SD Formatter is not only useless but dangerous instead (since you might wipe out your harddisk instead). It will later always look like this on the card (the first partition’s size adjusted to use all available disk space):

Code:

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sda1       5251072 15521790 10270719  4.9G  b W95 FAT32
/dev/sda2  *      73728   139263    65536   32M  6 FAT16
/dev/sda3             1  5251072  5251072  2.5G 85 Linux extended
/dev/sda5        139264   172031    32768   16M 83 Linux
/dev/sda6        172032   204799    32768   16M 83 Linux
/dev/sda7        204800  3350527  3145728  1.5G 83 Linux
/dev/sda8       3350528  3383295    32768   16M 83 Linux
/dev/sda9       3383296  3448831    65536   32M 83 Linux
/dev/sda10      3448832  5021695  1572864  768M 83 Linux
/dev/sda11      5021696  5054463    32768   16M 83 Linux
/dev/sda12      5054464  5087231    32768   16M 83 Linux
/dev/sda13      5087232  5251071   163840   80M 83 Linux

Then: Phoenix Card has some built-in checks relying on checksumming to verify whether some parts have been written correctly (does not apply to the largest part unfortunately). In case Phoenix Card throws errors then this is a sign of data corruption maybe caused by a bad (faulty or counterfeit) SD card or an SD card reader starting to corrupt data (well known problem with some USB readers that start to overheat and corrupt data after a certain amount of constant writing —> use USB2.0 when first connected to USB3.0, check the whole setup with one of the two tools below).

So instead of trying to workaround these issues ejecting/reinserting the card (which might work if speed negotiation between host and card reader might be adjusted — check Device Manager) the only reasonable strategy is to stop at the very first error and check card reader with inserted SD card using H2testw or f3. Anything else is simply fooling yourself and most probably creating an Android image containing bit flips that lead to all sorts of random problems later.

Good information that is true I guess, but i think the advantage of the Diskpart step is that in some cases the partitions on the SD card can be pretty messed up from previous failed attempts (mine was) and this assured at least some vanilla state that PhoenixCard then could work of.
I am not claiming that everything here is correct, needed or even a good idea. It can however work and I myself was really about to give up before trying it this way. I could have tried even more than two different readers/adapters, I could have bought some more SD cards but this would be just as hit&miss as just counting on some bit errors not mattering. Trying the latter though is certainly cheaper and I have yet to discover a problem (apart from the wrong RAM size you pointed out to me in the other thread, but that’s a different problem).
If will add a disclaimer to the original post though to let people know about your concerns.