ixus175_elph180_100c porting attempt

axman

145

Re: ixus175_elph180_100c porting attempt

« Reply #120 on: 25 / June / 2017, 00:44:11 »

Advertisements

Trying to understand why hooks not seen. Check some basics that maybe hurt us here if they are wrong.

Verify some addresses marked questionable in stubs_entry.s
; DeleteFile_Fut 0xff826a90
; GetFocusLensSubjectDistanceFromLens 0xff9a13a0
; 0xff82710c close
; 0xff8270c8 open

Disassemble around those addrs, the questionable funcs addrs are good.

Wondered about exposure counter. Verified it, too.
; 0xffa13d38 74 02 9f e5
; OPERANDS 2:
; 0: reg r0
; 1: mem base=pc scale=1 disp=0x00000274
; GROUPS 1:arm
ldr r0, =0x000d77d4 ; [pc, #628] (0xffa13fb4) jpeg_count_str

chdk menu -> tools -> browse to 0xffa13d38 with cam in shooting (P) mode; dword=e8bd41f0, byte=0xf0 = 240,
and that (240) agrees with the number of images on sd card.

Wonder if something wrong with half-press prop case. Some mention earlier in this thread about propsets; I stole propdmp.lua from http://chdk.wikia.com/wiki/PropertyCaseDump

Tell propdmp.lua to go from 0 - 400. Script prompted me for half-press several times, I did it; it finished.

ver=1,
from=0,
to=400,
diffs_were="[2] 0000 -> 0C00",

turn cam off, on again. Test quickshoot, good. Test half-press, then fullshoot, good. run propdmp again in shooting P mode, it prompts again 3-4 times for half-press, I do it; finished.

ver=1,
from=0,
to=400,
diffs_were="[13] 02F3 -> 02F0",
}

Uhh, I don't understand. Not sure it even matters, since half press when testing quick shoot, and a follow on full press seem to work ok, eg there is only a single image recorded for a single quick press. Probably because no filewrite is present to screw it up.?

Doing all this because hooktest Still Fails, same way as always. "Not reaching a hook, and hook in wrong place." I have put capt_seq_hook_raw_here in numerous places, but none of those places (that look reasonable for a hook) ever seem to be touched. Looking at ixus160 capt_seq.c and this one; this one looks ok. Stuff looks like it matches up pretty well.

There must be a sub in capt_seq:main below index=1 that should be patched, and isn't. I could use fresh suggestions if anyone has some to offer. Thanks in advance.

Logged

reyalp

14080

Re: ixus175_elph180_100c porting attempt

« Reply #121 on: 25 / June / 2017, 02:05:11 »

Quote from: axman on 25 / June / 2017, 00:44:11

Trying to understand why hooks not seen. Check some basics that maybe hurt us here if they are wrong.

None of these would affect the raw hook being called or not.

If PROPCASE_SHOOTING were incorrect, or doesn't behave as expected, that might produce similar symptoms, although (without looking at the code) I don't think it would produce the hooktest failures.

Looking at your capt_seq.c, you raw hook is in the middle of an assert check. This is not good, although it doesn't explain the hook not being called

Code: [Select]

"    BL      sub_FF9AFF04 \n"
"    TST     R0, #1 \n"  <<< tests return values
"    LDRNE   R2, =0x1C9 \n" <<< conditional load line number
"    LDRNE   R1, =0xFFAE824C /*'SsStandardCaptureSeq.c'*/ \n" <<< conditional load filename
"    MOVNE   R0, #0 \n" <<< conditional load other assert param
"    BL      capt_seq_hook_raw_here \n"         // 6th, raw hook added
"    BLNE    _DebugAssert \n" <<< conditional call to DebugAssert, but raw hook will have trashed the condition flags

Other than that, I agree it looks a lot like the ixus160 raw hook is immediately after the equivalent of that assert. I do see you have both the raw location suggested by blackhole and another location enabled. Having both called would cause problems.

You can determine whether the raw hook is being called using logging. e.g.

In platform/generic/capt_seq.c capt_seq_hook_raw_here just after the asm

_LogCameraEvent(0x60,"capt_seq_hook_raw_here");

then in chdkptp

Code: [Select]

!require'extras/devutil'.init_cli()
connect
dlstart
shoot
dlgetcam

Open dbg.log and look for capt_seq_hook_raw_here. You can add other logging to see what code paths are being taken.

The other thing you should make is that you've actually built and uploaded the right code. More than a few times, I've wondered why my changes were having no effect until I finally realized I was uploading builds from the wrong tree, or to the wrong camera...

Logged

Don't forget what the H stands for.

axman

145

Re: ixus175_elph180_100c porting attempt

« Reply #122 on: 25 / June / 2017, 14:07:25 »

@reyalp, thanks very much.

Re: hook #6 trashing the DebugAssert, yeah I was off by one. Fixed, now comes after Assert.

Re: multiple hooks being a Bad Thing - yes, I figured it might be, but I want to provoke something different to happen with hooktest. If / When that occurs, I will comment out those spurious hooks (one at a time).. But perhaps the debug logging is better technique..

Re: building and uploading the right code - I spent many hours last week forgetting to unzip my fresh build, wondering why changes not taking effect..

Re: adding debug statements and logging, Edits to platform/generic/capt_seq.c are done as you suggested, I think. Please forgive my ignorance.

If I have #defined CAPTSEQ_DEBUG_LOG (1) in generic/capt_seq.c, and called it once there,

generic/capt_seq.c

Code: [Select]

#include "asmsafe.h"
#include "conf.h"
...
#define CAPTSEQ_DEBUG_LOG (1)
...
 asm volatile ("STMFD   SP!, {R0-R12,LR}\n");
 #ifdef CAPTSEQ_DEBUG_LOG
   _LogCameraEvent(0x60,"capt_seek_hook_raw_here");
 #endif

does it mean I can add additional debug logging calls in
platform/cam/sub/100c/capt_seq.c ?

Or are these debug logging calls confined to platform/generic/capt_seq.c ?

Thanks again!!

Logged

reyalp

14080

Re: ixus175_elph180_100c porting attempt

« Reply #123 on: 25 / June / 2017, 15:13:14 »

Quote from: axman on 25 / June / 2017, 14:07:25

If I have #defined CAPTSEQ_DEBUG_LOG (1) in generic/capt_seq.c, and called it once there,

First of all, you don't need to put this stuff in ifdefs at all. I did that on g7x so autobuilds wouldn't have the logging, but I could still turn it on if needed. For your own development, there's no need to do this.

To your question, a #define is defined from the point it appears in the code onward. A #include acts as if the code of the included file was inserted in place of the #include. So if you define CAPTSEQ_DEBUG_LOG in generic/capt_seq.c it will be defined your platform capt_seq.c after the include. Personally, I'd put it at the top of the cameras capt_seq.c.

For logging, I'd suggest at least having something that logs the message number in the main capt_seq loop.

This will at least tell you for sure whether the right code is running, and help you get a better feeling how captseq works. This would be something like

Code: [Select]

"loc_FF88E254:\n"
"    LDR     R0, [SP] \n"
"    LDR     R0, [R0] \n"
"bl log_capt_seq\n"
"    LDR     R0, [SP] \n"
"    LDR     R0, [R0] \n"

where log_capt_seq is something like

Code: [Select]

void log_capt_seq(int m)
{
    _LogCameraEvent(0x60,"cs m:%d",m);
}

Note the code above is of the top of my head, not tested.

I use "cs" to indicate capt seq, and m to indicate message number. _LogCameraEvent automatically includes millisecond time stamps.

The way capt_seq (and many other Canon tasks) works is that it sits in a loop listening to a message queue (_ReceiveMessageQueue near the top of the function). Various shooting related operations (half press, full press, settings changes) generate messages, which each have a unique number. A switch statement (ADDCC PC, PC, R1, LSL#2) handles the messages based on the number.

Logged

Don't forget what the H stands for.

axman

145

Re: ixus175_elph180_100c porting attempt

« Reply #124 on: 25 / June / 2017, 17:03:19 »

@reyalp,

I tried to implement logging but mine had error in the c code part, and it crashed the camera when exercising with chdkptp 'shoot'. I can for sure implement now that I see where I made the error. :-D Thank you.

But while thrashing around, I bumped into something. Before posting walls of text about it, a question:

Does capt_seq have dependencies on stuff from movie_rec and filewrite?

Said differently, is it possible to make a CHDK that contains only

boot.c + its reference in taskhook.S + boot_hdr.c + chdk patches, etc
and
capt_seq.c + its taskhook.S ref + capt_seq_hdr.c + chdk patches, etc
and
init_file_modules taskhook.S ref

that can be tested with chdkptp using method you outlined couple of posts back?

Logged

reyalp

14080

Re: ixus175_elph180_100c porting attempt

« Reply #125 on: 25 / June / 2017, 17:13:35 »

Quote from: axman on 25 / June / 2017, 17:03:19

Does capt_seq have dependencies on stuff from movie_rec and filewrite?

No. Both movie_rec and filewrite implement optional features. If you want to turn them off for testing, just disable the task hooks and undef the defines that enable the features in platform_camera.h.

Logged

Don't forget what the H stands for.

axman

145

Re: ixus175_elph180_100c porting attempt

« Reply #126 on: 25 / June / 2017, 17:32:50 »

Quote from: reyalp on 25 / June / 2017, 17:13:35

Quote from: axman on 25 / June / 2017, 17:03:19
Does capt_seq have dependencies on stuff from movie_rec and filewrite?
No. Both movie_rec and filewrite implement optional features. If you want to turn them off for testing, just disable the task hooks and undef the defines that enable the features in platform_camera.h.

Comment out stuff in taskhook.S was already done.

If the features I wish to disable are not listed in platform_camera.h, do I have to add #undefs for them, in order for those features to be ignored?

Logged

reyalp

14080

Re: ixus175_elph180_100c porting attempt

« Reply #127 on: 25 / June / 2017, 17:39:26 »

Quote from: axman on 25 / June / 2017, 17:32:50

If the features I wish to disable are not listed in platform_camera.h, do I have to add #undefs for them, in order for those features to be ignored?

It depends whether it defaults to on or off in includes/camera.h. For filewrite, the default is off. Some of the video related ones default to on, although IIRC leaving them on without the task hook just results in the menu items being shown.

Logged

Don't forget what the H stands for.

axman

145

Re: ixus175_elph180_100c porting attempt

« Reply #128 on: 25 / June / 2017, 18:01:26 »

Quote from: reyalp on 25 / June / 2017, 17:39:26

Quote from: axman on 25 / June / 2017, 17:32:50
If the features I wish to disable are not listed in platform_camera.h, do I have to add #undefs for them, in order for those features to be ignored?
It depends whether it defaults to on or off in includes/camera.h. For filewrite, the default is off. Some of the video related ones default to on, although IIRC leaving them on without the task hook just results in the menu items being shown.

Thanks for pointer to includes/camera.h. I'm including it, and I notice it has
#define CAM_REMOTE 1

Which seems to bring along the dependency to core/remotecap.c when I build. Because the compile attempt fails, complaining about:
remotecap.c in func remotecap_send_complete, undefined reference to jpeg_last_status

I think I get it.. I am ok to undef CAM_REMOTE for getting to the bottom of capt_seq issue,

but if I undef CAM_REMOTE, does it mean those code paths we patch in capt_seq that refer to
" remote " <<-- as in remote power on via usb

they will.. uhh.. they will not exist? Am I seeing this right?

Logged

reyalp

14080

Re: ixus175_elph180_100c porting attempt

« Reply #129 on: 25 / June / 2017, 18:17:33 »

Quote from: axman on 25 / June / 2017, 18:01:26

Thanks for pointer to includes/camera.h. I'm including it, and I notice it has

You should not need to specifically include camera.h anywhere other ports don't. It's already included in the places that needed.

Quote

#define CAM_REMOTE 1

This refers to the USB hardware remote, not remotecap. remotecap is always enabled, since any complete port can do raw, even if filewrite isn't implemented.

Quote

Which seems to bring along the dependency to core/remotecap.c when I build. Because the compile attempt fails, complaining about:
remotecap.c in func remotecap_send_complete, undefined reference to jpeg_last_status

This means that the filewrite defines are set, or you didn't rebuild everything that needed to be rebuilt after changing the defines.

The dependencies in the CHDK makefiles aren't complete, so it's generally a good idea to do full builds (make clean fir or one of the zip builds). This is especially important when you change headers or makefile settings.

edit:
I highly recommend using using something like "grep" to search the source when you run into something like this and aren't sure what it does.

« Last Edit: 25 / June / 2017, 18:26:21 by reyalp »

Logged

Don't forget what the H stands for.