digic 6 motion detection (was Re: SX60HS Porting) - page 7 - General Discussion and Assistance - CHDK Forum supplierdeeply

digic 6 motion detection (was Re: SX60HS Porting)

  • 87 Replies
  • 28632 Views
*

Offline reyalp

  • ******
  • 12217
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #60 on: 25 / September / 2016, 15:12:36 »
Advertisements
I looked into the crash after using MD on g7x a bit more. It's.... weird.

Recap:
After running MD, the camera crashes with the lens out when I attempt to switch to play mode or power off. This happens with both MDFB2013.bas and md_tune.bas, both in test and shooting mode. It only happens if IS is enabled in the Canon menu.

It seems to happen frequently, but I'm not sure it's 100% reproducible with md_tune and mdfb2013. I ran the simple motion.lua and motion.bas examples a couple times without getting the crash  :-[

The crash itself is straightforward, and always appears to be the same
Code: [Select]
ASSERT!! ISDriver.c Line 1835
Occured Time  2016:09:24 19:08:53
Task ID: 17629222
Task name: CtrlSrv
The last line in the camera log is always
Code: [Select]
SS:ISChg
I believe this message means the IS mode is changing, presumably turning off for shutdown or playback in this case.

CtrlSrv is not a task that is modified by CHDK.

This assert from code in sub_fc305db4, which checks a byte variable (=0xb9a0) is in the range 0-2 and asserts if it is not. The actual assert is at 0xfc305e76. The variable appears to contain the IS mode (PROPCASE_IS_MODE value) except after boot in playback mode it's 0xff.

Now the weird part:
If I check the value after running and ending one of the MD scripts, it's in the correct range. So it's not a simple memory corruption, the variable only gets the wrong value after the playback switch or shutdown is started.

A few things I tried with no effect:
1) Bigger MD pixel step (18), on the theory that hogging the CPU for too long might be causing problems.
2) Disable grid drawing, on the theory that drawing bugs might end up corrupting memory outside the frame buffers or something else in hacky drawing / refresh code was causing problems.
3) End the script with the key press rather than shutter interrupt, on theory that something could get corrupted in restore() or module unloading could be doing something weird.
4) With and without PTP connected, in case PTP mode switching confused something.

Other observations:
1) I have run quite a few non-md scripts without problems, while both ubasic and Lua MD scripts do, so a generic script issue seems unlikely. But the fact the simple motion.* scripts aren't affected may cast doubt on this.
2) The variable in the Canon data segment and not particularly close to any variables used by CHDK, so straightforward clobbering by CHDK code seems unlikely.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4057
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #61 on: 25 / September / 2016, 15:33:40 »
If I check the value after running and ending one of the MD scripts, it's in the correct range. So it's not a simple memory corruption, the variable only gets the wrong value after the playback switch or shutdown is started.
You could make a custom assert handler and retrieve specific memory content from there (and save it to a file or something). Seeing the corrupted bytes might give hints.

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #62 on: 25 / September / 2016, 19:35:17 »
Did the crash also happen before you found and implemented the live buffer? Before you corrected the dimensions for unused pixels? 

Is the value written to 0xb9a0 always the same or do you know?
« Last Edit: 25 / September / 2016, 20:09:45 by 62ndidiot »

*

Offline reyalp

  • ******
  • 12217
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #63 on: 26 / September / 2016, 00:23:22 »
You could make a custom assert handler and retrieve specific memory content from there (and save it to a file or something). Seeing the corrupted bytes might give hints.
Yes, finding out what the value is seems like a good next step. Do you have code for a custom assert handler? (I know there's some in a one of the ports, but I've never actually used it)

Did the crash also happen before you found and implemented the live buffer? Before you corrected the dimensions for unused pixels? 
I think so, but I'm not totally certain. With the grid off, I have difficulty seeing how bad dimensions would cause something like this, since it should only be reading. But I don't have any good ideas...
Don't forget what the H stands for.


Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #64 on: 26 / September / 2016, 10:19:15 »
Yes, it should only be reading, except that when you terminate the script,  things are written to the osd, and of course, others things happen as well.  This seems consistent with what you see, no crash while md is running.  Just on termination. When the memory occupied by md is freed.

*

Offline srsa_4c

  • ******
  • 4057
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #65 on: 26 / September / 2016, 14:49:23 »
Yes, finding out what the value is seems like a good next step. Do you have code for a custom assert handler? (I know there's some in a one of the ports, but I've never actually used it)
I'm usually improvising when I need a custom handler, here's one example:
Code: [Select]
Index: platform/a3400/sub/100f/boot.c
===================================================================
--- platform/a3400/sub/100f/boot.c (revision 3303)
+++ platform/a3400/sub/100f/boot.c (working copy)
@@ -344,7 +344,25 @@
  );
 }
 
+static void (*orig_assert_handler)(char*, int);
 
+void custom_assert_handler(char *str, int line) {
+    if ((str==(char*)0xFF958158) && (line==0x33d)) {
+        int a, b;
+        a = (*(short*)(0xce8c+0xc))&0xffff;
+        b = (*(short*)(0x6214+4))&0xffff;
+        orig_assert_handler("customassert1", a*65536+b);
+    }
+    else {
+        orig_assert_handler(str, line);
+    }
+}
+
+void replace_assert_handler(int newhandler) {
+    orig_assert_handler = (void*)*(int*)0x1ae8;
+    *(int*)0x1ae8 = (int)custom_assert_handler;
+}
+
 //** task_Startup_my  @ 0xFF81A638
 
 void __attribute__((naked,noinline)) task_Startup_my(  ) {
@@ -362,8 +380,9 @@
       "BL      sub_FF836110 \n"
       "BL      sub_FF835F08 \n"
       "BL      sub_FF835DF4 \n"
-      "BL      sub_FF8340FC \n"
+      "BL      sub_FF8340FC \n" // assert handler, etc setup
       "BL      sub_FF836118 \n"
+      "BL      replace_assert_handler\n" // +
       "BL     CreateTask_spytask \n" //added to create the Spytask
 //      "BL      sub_FF82E9B0 \n" //original taskcreate_PhySw()
       "BL     taskcreatePhySw_my \n" // patched taskcreate_PhySw()
In the example, 0x1ae8 stores the function pointer of the assert handler, the right address can be found in the firmware's DebugAssert function. New cameras use 3 arguments in the asserts. I have also used file operations (write debug stuff in a file) in the custom handler - on old cameras. It can probably be done on recent cameras too.


One more thing to try (it's unlikely though) - try putting in those missing &1's in core/gui_draw.c .

*

Offline reyalp

  • ******
  • 12217
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #66 on: 02 / October / 2016, 20:48:28 »
I'm usually improvising when I need a custom handler, here's one example:
Thanks, that saved me some time. I used _LogCameraEvent to record the values around the variable in question. Code attached case anyone wants an example.

So far I've seen the value be 0x03 and 0x3c in the camera log. From using rmem before and after running MD, the neighboring values don't don't seem to be affected  :-[

The byte at 0xb9a1 changes on half press (0=not pressed, 1 pressed) I also saw 3 in this value, in one romlog and in some rmem (I'm not certain what state the camera was in when I got 3 in the rmem).

If I run MD with IS on, and then turn off IS before switching to play, it doesn't crash.
Don't forget what the H stands for.

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #67 on: 04 / October / 2016, 01:38:22 »
So Sometime during Md using rmem you see 0x03 or 0x3c written to the IS flag location? ( allowed values 0,1,2) which causes a crash when you leave MD shoot mode and switch to play mode. ?


*

Offline reyalp

  • ******
  • 12217
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #68 on: 04 / October / 2016, 02:30:24 »
So Sometime during Md using rmem you see 0x03 or 0x3c written to the IS flag location? ( allowed values 0,1,2) which causes a crash when you leave MD shoot mode and switch to play mode. ?
No, that's the weird thing. The value is correct when MD is running, and after the MD script ends. It must go wrong during the shutdown or playback switch process. The 0x03 and 0x3c values were captured by hooking the assert handler, using the code attached to that post.

edit:
The value of 3 I mentioned getting with rmem is the neighboring byte that seems to change of half press. I don't know it's meaning or allowed range, so I don't know if the 3 there is normal.
« Last Edit: 04 / October / 2016, 02:32:07 by reyalp »
Don't forget what the H stands for.

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #69 on: 04 / October / 2016, 16:02:42 »
My SX60Hs (100f), doesn't play completely nice when chdkptp is connected and i do MD Tune. This irrespective of IS OFF or CONTINUOUS.

1. turn camera on (with USB connected)
2. c (chdkptp)
3. rec (chdkptp)
4. Press Play/Alt
5. Press Shoot to launch MD tune
6. Press Shoot to kill MD Tune
7. Press Play
8. camera is disconnected from PTP, it's necessary to reconnect but no crash
(maybe this is just because PTP expects me to issue SHOOT and PLay from the keyboard?
9. c
10. things seem normal

What memory location(s) would you suggest to monitor in sx60hs?

Another thought FWIW, I think MD must be corrupting something, that subsequently corrupts the memory location you observe after pressing play.
Maybe its worth it to go back to very first version of MD that didn't try to deal properly with the 720/736 byte issues and undisplayed parts of the buffer.
I think that version is attached somewhere in this thread or possibly the sx60 thread.  Hard to see that that would cause it...but it's not a difficult thing to eliminate.