chdkptp gui - rec / play mode switch had issues, as did cli. Seem to relate to hot-plug usb, or with the cam being recognized by OS before or after chdkptp is run.

My chdkptp version circa May 23, 2017.

Case where cam is present in the OS before launching chdkptp, rec/play work correctly. Eg - both cli and gui switch the camera from rec to play and play to rec correctly.-------------------------------------------Case where chdkptp is running, cam has already booted CHDK and is running in PLAY mode, and cam is then plugged into USB:

I reproduced the crash twice, once using the chdkptp cli, and once using chdkptp gui. I have the romlogs and Gk.log files from each, if it's of interest. Also have all the logs from above named tests. The 4th attempt, cam did not crash, but rebooted (steps a-g above).

Verified that my ixus160 tolerates this hot-plugging case, and switches from rec to play correctly.

I read the thread about overrides.. More than happy to test / provoke / dump. Hopefully I can be a bit useful with minimum handholding.

Using trunk, I built a working version. Camera booted CHDK and m10 normal controls operated, as advertised.

Then I dumped the fresh 110d firmware, and placed copies of the .BIN in /tools and sub/110d respectively.

make clean; make fir; Compile fails, when dealing with stubs_entry.S.

Restore as-downloaded state, move the PRIMARY.BIN out of the way; builds GOOD again.

Compare files, try to account for the diffs I see.

I have diffs between funcs_by_address.csv, funcs_by_name.csv (build-GOOD and fail), the previous (working) stubs_entry.S, stubs_entry.S.err, and stubs_not_found_names.err from the failed compilation.

Since trunk m10 builds good for me, and cam operates ok for the fw ver that I have (110d), why does my build fail - on stubs_entry.S - with dump of Canon's 110d -> PRIMARY.BIN present in platform/sub/110d/ ? And succeed when it's not present? Wondering if the following reasoning is true;

1) differences in firmware versions [function addresses, etc found in the dis-assembled PRIMARY.BIN] from the original-Canon-firmware to recent-Canon-upgrade-firmware that relate to stubs_entry.S have already been resolved MANUALLY.

2) Meaning: The automated sig find process simply fails for some elements (most every time on certain things, perhaps), and someone skilled in the art has already looked through PRIMARY.BIN and made educated guesses about the missing addrs, and has already filled in what the automated sig finder missed or got wrong.

Could there also be small differences inside one version of '110d' that occur between cameras in a production run?

Could also be the possibility that something about the way I'm doing universal dumper this time is wrong, (as if I have to trim 0x?? off the beginning of the dump ?)

What's nagging me is, I'm trying to resolve and understand diffs between the trunk version of funcs_by_address.csv [that builds good] and funcs_by_addr that is generated during my failed build process. I assume the proc that generates funcs_by_addr is looking at sub/110d/PRIMARY.BIN to try and get those funcs.

Could it be that the automated 'func finder' which is activated during build process behaves similar to the process that generates stubs_entry.S - in that it simply does not find some funcs correctly? Not being critical, just trying to reconcile my understanding of the process with the evidence..

As if, "I did not trim any data from PRIMARY.BIN as dumped, therefore my funcs are lining up in a different place in the firmware dump.." ? )

Edit:I confirmed that 3.0.5-rc2 does not fix this issue. It was fixed in the "next" branch, but that branch has changed in other incompatible ways. So, you need to build from source with the attached patch.

Also, I fixed the typo "dissassembly" in the message quote above, so if you search after r4814, it will be "disassembly"

Case where chdkptp is running, cam has already booted CHDK and is running in PLAY mode, and cam is then plugged into USB(...)I reproduced the crash twice, once using the chdkptp cli, and once using chdkptp gui. I have the romlogs and Gk.log files from each, if it's of interest.

Yes, I'd like to see them if possible.Turns out, this specific scenario is problematic on my side too. However, I'm experiencing different behaviour.I usually have to switch between play->rec multiple times to trigger the crash. The camera does not reboot, it remains off.After the crash, I can't get any romlog. That means, no romlog is saved when I attempt to get one. When I crashed the cam again this way, I got romlogerr.txt on the next attempt.This is worrying, there might be memory corruption somewhere.

When a CHDK is made for the M10, will it be able to record video in RAW format?

The potential is there.However.It would require tons of research. CHDK would need features it currently doesn't have. No DIGIC 6 cameras run ML either (at the moment), so detais and potential issues are not known.If RAW video ever gets implemented on CHDK, it's likely that the first camera supporting it won't be the M10 (or even DIGIC 6).

When a CHDK is made for the M10, will it be able to record video in RAW format?

The potential is there.However.It would require tons of research. CHDK would need features it currently doesn't have. No DIGIC 6 cameras run ML either (at the moment), so detais and potential issues are not known.If RAW video ever gets implemented on CHDK, it's likely that the first camera supporting it won't be the M10 (or even DIGIC 6).