power off authomatically - page 3 - General Help and Assistance on using CHDK stable releases - CHDK Forum

power off authomatically

  • 41 Replies
  • 4152 Views
*

Offline reyalp

  • ******
  • 12444
Re: power off authomatically
« Reply #20 on: 11 / May / 2013, 21:32:00 »
Advertisements
I've looked at this some more.

I'm confident that
Code: [Select]
3c6afc2: 7878      ldrb r0, [r7, #1]
corresponds to
Code: [Select]
                            val = img[y + x + 1]
Furthermore, from the ROMLOG, we see
Code: [Select]
R6  0xB2D6FE98
R7  0xB2D6FE98
In other words, the bogus pointer also appears in R6.
Based on
Code: [Select]
3c6ae46: 4bc2      ldr r3, [pc, #776] ; (3c6b150 <md_detect_motion+0x350>) ; vid_get_viewport_live_fb
 3c6ae48: f000 fa59 bl 3c6b2fe <action_stack_AS_MOTION_DETECTOR+0xc2> ; long call
 3c6ae4c: 1e04      subs r4, r0, #0
 3c6ae4e: d103      bne.n 3c6ae58 <md_detect_motion+0x58>
 3c6ae50: 4bc0      ldr r3, [pc, #768] ; (3c6b154 <md_detect_motion+0x354>) ; vid_get_viewport_fb
 3c6ae52: f000 fa54 bl 3c6b2fe <action_stack_AS_MOTION_DETECTOR+0xc2> ; long call
 3c6ae56: 1c04      adds r4, r0, #0
 3c6ae58: 4bbf      ldr r3, [pc, #764] ; (3c6b158 <md_detect_motion+0x358>) ; vid_get_viewport_image_offset
 3c6ae5a: f000 fa50 bl 3c6b2fe <action_stack_AS_MOTION_DETECTOR+0xc2> ; long call
 3c6ae5e: 4bbf      ldr r3, [pc, #764] ; (3c6b15c <md_detect_motion+0x35c>) ; vid_get_viewport_height
 3c6ae60: 1826      adds r6, r4, r0
R6 is  vid_get_viewport_live_fb() + vid_get_viewport_image_offset(). The fact that R7 has the same value suggests the crash happened in the first iteration of the loop (in this particular call to md_detect_motion.)

vid_get_viewport_live_fb is exonerated
Code: [Select]
    return viewport_buffers[(active_viewport_buffer-1)&3];

viewport_buffers
ROM:FFB2F90C                 DCD 0x40566B80
ROM:FFB2F910                 DCD 0x405A6000
ROM:FFB2F914                 DCD 0x405E5480
ROM:FFB2F918                 DCD 0x40624900

vid_get_viewport_image_offset is
Code: [Select]
int vid_get_viewport_image_offset() {
return (vid_get_viewport_yoffset() * vid_get_viewport_byte_width() * vid_get_viewport_yscale()) + (vid_get_viewport_xoffset() * 3);
}

Of these, vid_get_viewport_byte_width and vid_get_viewport_yscale are simple constants.

vid_get_viewport_yoffset and vid_get_viewport_xoffset are both rather nonsensical lookups based on shooting_get_prop(PROPCASE_ASPECT_RATIO)
Code: [Select]
int vid_get_viewport_xoffset()
{
    // viewport width offset table for each image size
    // 0 = 4:3, 1 = 16:9, 2 = 3:2, 3 = 1:1
    static long vp_w[4] = { 0, 0, 0, 0 };               // should all be even values for edge overlay
    return vp_w[shooting_get_prop(PROPCASE_ASPECT_RATIO)];
}

int vid_get_viewport_yoffset()
{
    // viewport height offset table for each image size
    // 0 = 4:3, 1 = 16:9, 2 = 3:2, 3 = 1:1
    static long vp_h[4] = { 0, 0, 0, 0 };
    return vp_h[shooting_get_prop(PROPCASE_ASPECT_RATIO)];
}
However, these should be harmless unless the PROPCASE_ASPECT_RATIO value is out of range.

A3400 is defined as a propset 5 cameras, which makes  PROPCASE_ASPECT_RATIO 300


This leads to two things that can be tested by someone who has this camera:
1) what is the value of propcase 300 on this camera? In CHDK menu, go to miscellaneous -> debug parameters, set debug data display to props, set Propcase page to 30. Try changing aspect ratios (if available), look at it in REC mode while halfshooting, shooting, and running the MD script.
2) Replace all the nonsense lookups with just a return <value>, or if this camera does in fact have variable aspect ratios that affect the viewport, put in the correct values.

Other possibilities:
1) my analysis above is wrong.
2) There is memory corruption happening somewhere else.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 12444
Re: power off authomatically
« Reply #21 on: 12 / May / 2013, 19:35:02 »
@timgor

Can you tell us what canon settings you are using when you encounter this problem? Image size, shooting mode, things like that?
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 12444
Re: power off authomatically
« Reply #22 on: 12 / May / 2013, 20:47:58 »
Looking at the romlog in post 3 http://chdk.setepontos.com/index.php?topic=9804.msg100062#msg100062  I noticed that R6 is a valid viewport address (the 3rd one in the table)
Code: [Select]
R6  0x405E5480
R7  0xD78653C1
Not sure what this means, but if the register usage was similar in the autobuild (likely but not certain), it's not consistent with my idea that vid_get_viewport_image_offset is producing a bad value.
Don't forget what the H stands for.

*

Offline timgor

  • ***
  • 150
Re: power off authomatically
« Reply #23 on: 12 / May / 2013, 23:29:28 »
Hello, thanks for discussing the problem. Right now I am out of my house. I will come back and continue my study after May 20.   


*

Offline reyalp

  • ******
  • 12444
Re: power off authomatically
« Reply #24 on: 12 / May / 2013, 23:37:21 »
Hello, thanks for discussing the problem. Right now I am out of my house. I will come back and continue my study after May 20.
No problem, thank you for testing.

I've attached a new debug build for when you get back. It should create a files called MD1.DMP and / or MD2.DMP if the problem happens. It should still crash

I've also attached the patch for anyone who is interested.
Don't forget what the H stands for.

*

Offline timgor

  • ***
  • 150
Re: power off authomatically
« Reply #25 on: 23 / May / 2013, 11:20:05 »
Hello reyalp!
I just completed a few tests with a following optimistic results:
the compiled application CHDK-a3400-101a-1.2.0-2772-reyalp-1.zip has been working for 40 hours and still working without crash :)
What did you change there?
you said that "It should create a files called MD1.DMP and / or MD2.DMP"
did you do any changes along with the output files printing?
what subversion number did you use for the compilation?
I want to make tests with and without your change.
Also, I did another test but I think your version needs priority attention now.
Thanks!
« Last Edit: 23 / May / 2013, 11:41:20 by timgor »

*

Offline reyalp

  • ******
  • 12444
Re: power off authomatically
« Reply #26 on: 23 / May / 2013, 13:32:28 »
Hello reyalp!
I just completed a few tests with a following optimistic results:
the compiled application CHDK-a3400-101a-1.2.0-2772-reyalp-1.zip has been working for 40 hours and still working without crash :)
Unfortunately, this isn't good news.
Quote
What did you change there?
you said that "It should create a files called MD1.DMP and / or MD2.DMP"
did you do any changes along with the output files printing?
No, the only change is the debug code. All the changes are in the patch. Basically, it just looks for the "bad" value in the place where I think the crash normally happens, and writes some information to a file. It doesn't change the value so the normal crash should follow immediately afterward.
Quote
what subversion number did you use for the compilation?
2772
Don't forget what the H stands for.

*

Offline timgor

  • ***
  • 150
Re: power off authomatically
« Reply #27 on: 23 / May / 2013, 13:40:59 »
Anyway, I will try to compile this version on my computer and investigate it. Something definitely has been changed and we have a chance to know what.
« Last Edit: 23 / May / 2013, 13:42:49 by timgor »


*

Offline reyalp

  • ******
  • 12444
Re: power off authomatically
« Reply #28 on: 23 / May / 2013, 15:52:49 »
Anyway, I will try to compile this version on my computer and investigate it. Something definitely has been changed and we have a chance to know what.
Although I don't see a mechanism, it may be possible that the problem fixed in http://trac.assembla.com/chdk/changeset/2762/  was related. I think all of our previous test builds were before that.

If you want to test this theory, try trunk builds of 2761 and 2762.

It's also possible that the optimization change just hides the actual bug somehow...
Don't forget what the H stands for.

*

Offline timgor

  • ***
  • 150
Re: power off authomatically
« Reply #29 on: 23 / May / 2013, 16:13:48 »
I have compiled 2761, 2762 and 2772. I will run it tonight and see what will be.
Next, I am going to replace actual md_detect_motion(void) function for failing revision by fake one that returns "detected motion" every 5 minutes.
Code: [Select]
static int md_detect_motion(void)
{
   
   int idx, tick, rv;
   int val, cy, cv, cu;

    register int col, row, x, y;

    if(!md_running())
    {
        return 0;
    }

    tick = get_tick_count();
    rv = 1;
#ifdef OPT_MD_DEBUG
    if(motion_detector.comp_calls_cnt < MD_REC_CALLS_CNT)
    {
        motion_detector.comp_calls[motion_detector.comp_calls_cnt]=tick;
    }
    motion_detector.comp_calls_cnt++;
#endif

    if(motion_detector.start_time + motion_detector.timeout < tick )
    {
        md_save_calls_history();
        motion_detector.running = 0;
        motion_detector.return_value = 1;
        return 0;
    }
   
   
    if(motion_detector.last_measure_time + motion_detector.measure_interval > tick)
    {
        // wait for the next time
        return 1;
    }

    motion_detector.last_measure_time = tick;

   
    return 1;
}


 

 

Related Topics