We have had reports from our sub contract manufacturer of boards failing to program using mfgtool. Actually the boards are failing during boot of the WinCE UUT image (the one used by mfgtool to transfer the actual OS/eboot). A recent batch of 200 boards, 25 failed. Replacing the processor they were fine.
I have had some boards back for analysis and found they fail shortly after OEMInit in the early kernel start - the boot just hangs. After a lot of debugging and trying different things I found that if I disable the caches (OEMARMCacheMode returns 0x00 rather than 0x0C) then the failing boards then boot fine. Re-enabling caches they fail at the same point.
I have ran DDR test and my own test over the whole RAM and this is fine.
I thought that these boards may have something in their RAM, perhaps left by the boot ROM uninitialised. Or perhaps an issue with the fact the MMU was set up for D-caching for hab boot then reconfigured during WinCE startup. So I tried disabling the MMU for the boot ROM using the relevant fuse. This made no difference - for the failing boards having D-Cache enabled in the UUT image they would fail to boot once transferred over USB.
I am still looking into what this could be but it is odd that it is only a small quantity of boards - usually I would point that at an assembly defect but there is no evidence of this so far. I am trying to understand why they only fail with cache enabled.