Sometime the autorun feature fails to start my software

Hello,

I am working on a custom board using the Apalis IMX6 module running Wince2013. I added a driver in the default wince image in order to communicate with a FPGA.

I use the autorun feature to start an application (and Cerdisp) at the board start-up. Most of the time the two applications starts correctly. But sometime they don’t start.

I extracted the boot debug messages to investigate.

Here are the debug messages I get when the application don’t starts:

DebugOutputnotWorking.log (3.2 KB)

and here are the debug messages I get when the application starts.

DebugOutputworking.log (2.9 KB)

The main difference I found between these log files are this line:

Exception 'Prefetch Abort' (0x3): Thread-Id=058c0042(pth=af89c470), Proc-Id=047e0026(pprc=af8850c0) 'SyCTRL.exe', VM-active=047e0026(pprc=af8850c0) 'SyCTRL.exe'
PC=0000a713(???+0x0000a713) RA=0000a713(???+0x0000a713) SP=02fef910, BVA=0000a712

Have you an idea what can cause my issue?

Best regards,
Eiffonck

Your logs show that even if the application starts OK, there are still very concerning outputs:

Exception ‘Raised Exception’ (0xc0008002): Thread-Id=008c0026(pth=af81f780), Proc-Id=00400002(pprc=8285cae0) ‘NK.EXE’, VM-active=03fc0026(pprc=af8472d0) ‘explorer.exe’
PC=eff62e8f(k.coredll.dll+0x00012e8f) RA=80223a1f(kernel.dll+0x00006a1f) SP=bc45f350, BVA=000022ad
Exception ‘Raised Exception’ (0xc0008002): Thread-Id=008c0026(pth=af81f780), Proc-Id=00400002(pprc=8285cae0) ‘NK.EXE’, VM-active=03fc0026(pprc=af8472d0) ‘explorer.exe’
PC=eff62e8f(k.coredll.dll+0x00012e8f) RA=80223a1f(kernel.dll+0x00006a1f) SP=bc45f358, BVA=b3862810
WARNING!!! VIDEO divider not in 27 - 54 range.

An exception raised by explorer.exe should not occur, and it could be the reason for sporadic problems with the prefetch abort caused by your application ‘SyCTRL.exe’. I’d recommend starting the debugging by investigating the ‘Raised Exception’ by explorer.exe.

You can download the latest, unmodified Toradex image of Wince2013 to verify that this exception does not occur. Yes, you will not be able to communicate with the FPGA in this way, but it would be the correct first step in your investigation.