We are able to reproduce the problem and it is always in the beginning of the CM3 flash (by comparison).
Its always the first 1k area, which is filled with 0x00 in a “damaged” CM3.
fdisk shows nothing in this case, because it is unable to find the 4 partitions.
I will upload the first part of the good image below. I am not familiar with the structure of images. But after diff, it shows that these entries (bytes starting at offset 0x0000 and 0x001B…- not 0x00) are always “missing” in the flash. It all reads 0x00 instead of this:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 FA B8 00 10 8E D0 BC 00 B0 B8 00 00 8E D8 8E C0 ú¸…ŽÐ¼.°¸…ŽØŽÀ
00000010 FB BE 00 7C BF 00 06 B9 00 02 F3 A4 EA 21 06 00 û¾.|¿…¹…ó¤ê!..
00000020 00 BE BE 07 38 04 75 0B 83 C6 10 81 FE FE 07 75 .¾¾.8.u.ƒÆ…þþ.u
00000030 F3 EB 16 B4 02 B0 01 BB 00 7C B2 80 8A 74 01 8B óë.´.°.».|²€Št.‹
00000040 4C 02 CD 13 EA 00 7C 00 00 EB FE 00 00 00 00 00 L.Í.ê.|…ëþ…
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
000000A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
000000C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
000000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
000001A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
000001B0 00 00 00 00 00 00 00 00 98 65 96 1C 00 00 80 00 …˜e–…€.
000001C0 01 C0 0C 03 E0 3F 00 60 00 00 00 40 01 00 00 00 .À…à?....@.... 000001D0 C1 40 83 03 E0 FF 00 A0 01 00 00 C0 30 00 00 03 Á@ƒ.àÿ. ...À0... 000001E0 E0 FF 83 03 E0 FF 00 60 32 00 00 C0 30 00 00 03 àÿƒ.àÿ.2…À0…
000001F0 E0 FF 83 03 E0 FF 00 20 63 00 00 00 10 00 55 AA àÿƒ.àÿ. c…Uª
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00000290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
000002A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
000002B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
000002C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
000002D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
000002E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
000002F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
Is this the partition table?
There are a lot of zeroes after that (which should be zero) but it seems that the first block is NOT WRITTEN correctly. I do not know if Etcher simply starts with offset zero or finalizes something at the end of the process. We can reproduce this with empty CM3 and with other CM3 with former working images written by other tools. Sometimes Etcher sets this area to 0x00 and the image does not boot. Perhaps always the first 512 or 1024 bytes. The rest is O.K. And perhaps this could also be a problem of other guys with non-working images on USB sticks or…
We do not use the verify option presently, to speed up the process. But we tested this with activated verify and also found at least one CM3 with damaged start area WITHOUT verify error!
I had no time to do further testing, but I expected a failure message with activated verify already at 1% in this case. Does Etcher report verify error only after 100% read? This needs too much time.
Does “Eject after success” have any influence on the last bytes written?
Perhaps the first block should be written with a delay or something else or deleted and rewritten.
Tomorrow I will send the fdisk output (4 partitions).
Best regards,
HaJo