I played something with the script today. It seems a timing problem. On the one hand I used a newer, faster SD card and put the camera on MF.
On the first run (only RAW), the camera took only three pictures 
On the second and third runs the cam took 7 Pictures.
If I set the camera to only JPG, then the cam always make the 4 pictures (the first picture twice).
Have you tried only RAW?
I only made some test runs, nothing comprehensive.
It makes no sense trying the - obviously malfunctioning - script over and over again. It clearly needs to be changed or rewritten.
But basically, I still have problems starting scripts (like the firmware dump). I have the problem synonymous with the new SD card. Sometimes I have to start the camera 10 times. Is there a specific timing at power on?
I recall having problems starting scripts from time to time on various cameras. But unfortunately, I don't know what's behind that.
If there are threading problems like that maybe we can try to move some of the script's functionality to native code...
What does that mean?
The script relies on Canon Basic global variables that are written and read in different tasks. I have a feeling that this isn't working well enough, especially not on multiprocessor cameras.
The script has a main loop (
mytask()) that runs in its own task.
The
mycontroller() function is called from the firmware's CtrlSrv task, it is used for intercepting the keyboard.
The functions
shoot_pre(),
shoot_beforeexpo(),
shoot_complete() are called from the firmware's shooting related tasks.
As a first try, global variables used in more than one task could be turned into pointers and they could point to a piece of memory that has no caching issues (uncached memory, for example).
If that's not enough, the functions listed above (those that run in firmware tasks) could be replaced with ARM code. But doing this is not trivial (loading code at runtime and making sure there are no caching and similar issues).
