Picking up where we left off, I wrote a patch for api_test.lua that skips test_lv when run on an EOSM. I submitted a
pull request on the lua_fix branch. Hope that's the right procedure.
I did manage to get a successful api_test.lua run on the EOSM with the camera in "Focus Mode AF" mode and "Continuous AF Disable" set on the Canon menu.
Here is the log to that test.
It takes a long time for the EOSM to complete the test and it will crash if the camera is not set to "Continuous shooting" on the Canon menu.

It looks like the main issues that I've found so far on the lua module have to do with focus. garry23 pointed this out:
One of the issues was that moving the lens had to be managed and I did it this way, my a loop delay:
function check_lens_ready()
if scriptmenu.submenu["Focus bracketing?"].value ~= "no" then -- hang around until lens is ready to be moved
repeat
msleep(200)
until lens.focus(0,1,false)
end
end
That is a zero movement move!
There was also a recent discussion in the
Programmatic focus control and absolute/relative focus position topic.
This pointed to the focus branch so I turned my attention to the
Focus backend updates - precise focus position and other tweaks pull request. I tried to help find the missing property handler address for the EOSM a while ago but didn't quite get it. There is an issue compiling the EOSM platform and I think that the reason is because the lens data is missing prop_lv_lens.focus_pos information in the lens.h file causing a build error on that platform. The EOSM is handled differently than the other platforms so as a test I commented out the following block of code from lens.h and ran a test of the focus branch on the EOSM. Running api_test.lua completed successfully on it and created
this log which looks to me pretty much like the lua_test branch.
#elif defined(CONFIG_EOSM)
struct prop_lv_lens
{
uint32_t lens_rotation; //
uint32_t lens_step; //
uint32_t off_0x08; //
uint32_t off_0x0c; //
uint32_t off_0x10; //
uint32_t off_0x14; //
uint32_t off_0x18; //
uint32_t off_0x1c; //
uint32_t off_0x20; //
uint32_t off_0x24; //
uint32_t off_0x28; // L10 - names not accurate
uint16_t off_0x30; //
uint16_t focal_len; //
uint16_t focus_dist; // One FD
uint16_t focus_dist2;//
uint16_t off_0x38; //
uint32_t off_0x3c; //
uint8_t off_0x3D; //
} __attribute__((packed));
SIZE_CHECK_STRUCT( prop_lv_lens, 59 );
There was another issue compiling the focus branch--the dual_iso module failed to build on all the platforms. The error seems to be this:
error:
cr2hdr.c:2574:21: error: function definition is not allowed here
{
^
As if all this wasn't enough to chew on for a while I started thinking if the EOSM lens issue has to do with the camera or the EF-M lens so I put on the EF-EOS M adapter and an EF-S 17-55mm 2.8 lens on the camera and re-ran the tests. This time it didn't take nearly as long as with the EF-M lens and I could hear the focus mechanism churning during the tests. The logs show more activity on the EF-S lens than on the EF-M lens. Here's
the log for the hacked focus branch and here's
the log from the lua_fix branch. If I'm reading it right it appears that the lua_fix branch test may be communicating with the EF-S lens properly. Of course this brings up the question--why isn't it working with the EF-M lens?