power off authomatically

waterwingz

12140

Re: Bug report

« Reply #10 on: 05 / May / 2013, 11:58:58 »

Advertisements

Quote from: timgor on 02 / May / 2013, 11:03:04

My preliminary results are folowing:
I tested a3400is camera and I used a3400-101a-1.1.0 version.
1. I did test of motion.lua script for 4-5 times and camera shut-down every time after about 3 hours of work.
2. I relapced md_detect_motion() function by sleep(300000) and it started to work "forever" so the problem is in the md_detect_motion function.
3. the ROMLOG.LOG file has the following content:

Just completed a 24 hour run of the simple motion detection script with no problems on my A1200.

However, I see that you are using the 1.1.0 version of CHDK and I'm using the 1.2.0 version (which has different md_detect_motion() code). I'll reload 1.1.0 and try that for a while.

Update : it would be interesting to know if the uBASIC verison of the script does the same thing as the Lua version on your camera ?

« Last Edit: 05 / May / 2013, 12:16:15 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

timgor

150

Re: power off authomatically

« Reply #11 on: 05 / May / 2013, 14:25:39 »

I have completed few tests with the new compiled version from reyalp.
I have attached the error files.
Also, I have tried my own compiled code with print("flag") lines within md_detect_motion function and every time it prints the last flag just before "return" statement so it looks like no crash happens within this function.
I would appreciate if reyalp will look for the bug.

MODULES.LOG (0.17 kB - downloaded 20 times.)

ROMLOG.LOG (4.16 kB - downloaded 19 times.)

Logged

nafraf

1308

Re: power off authomatically

« Reply #12 on: 05 / May / 2013, 14:30:56 »

@timgor
A3400 LED addresses are not verified. Those addresses were copied from A4000 or a810, probably they are right, but it would be better if you check them.

platform/a3400/lib.c

Code: [Select]

#define LED_PR 0xC0220120  //check this address

// To do: Check this!!
// A3400IS has two 'lights' - Power LED, and AF assist lamp
// Power Led = first entry in table (led 0) ???
// AF Assist Lamp = second entry in table (led 1) ????
void camera_set_led(int led, int state, int bright) {
    return;
    static char led_table[2]={0,4};
    if(state<=1) _LEDDrive(led_table[led%sizeof(led_table)], state);
}

Logged

reyalp

14111

Re: power off authomatically

« Reply #13 on: 05 / May / 2013, 16:01:56 »

Quote from: timgor on 05 / May / 2013, 14:25:39

I have completed few tests with the new compiled version from reyalp.
I have attached the error files.
Also, I have tried my own compiled code with print("flag") lines within md_detect_motion function and every time it prints the last flag just before "return" statement so it looks like no crash happens within this function.
I would appreciate if reyalp will look for the bug.

Thanks for the logs.

Relocating the .elfs from modules.log

Code: [Select]

   71740,LD,03c48b68,lua.flt
   96990,LD,03c6a958,mdetect.flt (assuming the second load based on time)

0x3c48b68 + 0x24 = 0x3c48b8c
0x3c6a958 + 0x24 = 0x3c6a97c
arm-elf-objdump -d -r -x --adjust-vma=0x3c48b8c lua.elf > lua.0x3c48b8c.objdump
arm-elf-objdump -d -r -x --adjust-vma=0x3c6a97c mdetect.elf > mdetect.0x3c6a97c.objdump

From the romlog

Code: [Select]

R0  0x0000006C
R1  0xB2D6FE98
R2  0x00000001
R3  0x00000000
R4  0x00000000
R5  0x03C6B4E4
R6  0xB2D6FE98
R7  0xB2D6FE98
R8  0x19980218
R9  0x19980218
R10 0x19980218
R11 0x19980218
R13 0x00000162
SP  0x00308AAC
LR  0x03C6AFA3
PC  0x03C6AFC2
SPR 0x60000033

PC is where the exception occurred. From the modules log, we can see it's in mdetect.elf md_detect_motion

Code: [Select]

03c6ae00 <md_detect_motion>:
...
3c6afc2:	7878      	ldrb	r0, [r7, #1]

I think r7 is the pointer into the viewport.

This suggests that vid_get_viewport_live_fb or vid_get_viewport_fb (in platform/a3400/lib.c) returned a bad address.

If you watch the return value of vid_get_viewport_live_fb with misc debug values (see core/gui_osd.c gui_draw_debug_vals_osd ) , it should be obvious if it occasionally returns a value that isn't like the others. Correct values should be 0x4xxxxxxx. It will only crash if the bad value is outside valid RAM etc, but should trigger MD incorrectly in other cases. It would also cause problems with histogram, zebra and edge overlay.

Logged

Don't forget what the H stands for.

timgor

150

Re: power off authomatically

« Reply #14 on: 06 / May / 2013, 12:38:11 »

Thanks.
1. Should I uncomment all comments from gui_draw_debug_vals_osd() or just part of it?
2. What will be advantage of printing? camera will shut down after the error happens and I will not see anything after that.
3. What to do with that after all? Hot to correct mistake with a wrong return address?
4. Does it correlate with nafraf notice about #define LED_PR 0xC0220120 //check this address parameter?

Logged

reyalp

14111

Re: power off authomatically

« Reply #15 on: 06 / May / 2013, 13:25:45 »

Quote from: timgor on 06 / May / 2013, 12:38:11

1. Should I uncomment all comments from gui_draw_debug_vals_osd() or just part of it?

You should *modify* it to show the return value of vid_get_viewport_live_fb, e.g. change

Code: [Select]

        sprintf(osd_buf, "FB:  %8u", focus_busy);
        draw_txt_string(28, 10, osd_buf, conf.osd_color);

to

Code: [Select]

        sprintf(osd_buf, "FB:  %8x",  vid_get_viewport_live_fb());
        draw_txt_string(28, 10, osd_buf, conf.osd_color);

Quote

2. What will be advantage of printing? camera will shut down after the error happens and I will not see anything after that.

If vid_get_viewport_live_fb is returning bad values, you will probably seem them just looking at the display in record mode. The crash only happens when the bad value is outside of physical RAM, but in general if vid_get_viewport_live_fb is implemented wrong, it will probably alternate between several correct values and a wrong value.

An alternative would be to just make vid_get_viewport_live_fb return null, in which case the code will fallback to vid_get_viewport_fb. This will hurt MD performance compared to a correct implementation of vid_get_viewport_live_fb, but it should work.

Another alternative would be to inspect the values of viewport_buffers and active_viewport_buffer using the memory browser. The addresses can be found in platform/a3400/sub/<version>/stubs_entry.S

Hmm, now I see that viewport_buffers is in ROM, so maybe my theory is wrong.

Code: [Select]

DEF(viewport_buffers                        ,0xffb2f90c) // Found @0xff849c00
DEF(active_viewport_buffer                  ,0x000020bc) // Found @0xff849968

Quote

3. What to do with that after all? Hot to correct mistake with a wrong return address?

Someone needs to figure out the correct implementation of vid_get_viewport_live_fb (assuming this is actually the problem)

Quote

4. Does it correlate with nafraf notice about #define LED_PR 0xC0220120 //check this address parameter?

No.

Logged

Don't forget what the H stands for.

timgor

150

Re: power off authomatically

« Reply #16 on: 08 / May / 2013, 10:58:21 »

I have replaced the code in motion_detector.c

Code: [Select]

    
unsigned char* img = vid_get_viewport_live_fb();    
    if(img==NULL)
    {
        img = vid_get_viewport_fb();
    }

by

Code: [Select]

unsigned char* img = vid_get_viewport_fb();

It didn't change anything. Camera works as well as before and shut-down in a few hours.
It looks like the problem is not in vid_get_viewport_live_fb.
Do you have ideas what to to next to debug it?

Logged

reyalp

14111

Re: power off authomatically

« Reply #17 on: 08 / May / 2013, 13:06:56 »

Quote from: timgor on 08 / May / 2013, 10:58:21

It didn't change anything. Camera works as well as before and shut-down in a few hours.
It looks like the problem is not in vid_get_viewport_live_fb.
Do you have ideas what to to next to debug it?

Work out what that invalid address is supposed to be accessing. (edit: ie, what C code the faulting address corresponds to)

The viewport dimensions would be another possible suspect. The code (lib.c vid_get_viewport_width etc) looks bogus to me, since it gives all the different aspect ratios exactly the same dimensions (does this camera even support different aspect ratios?) but I don't see any obvious way it produce bad values after a long time. Check PROPCASE_ASPECT_RATIO is in the range 0-3, and actually corresponds to aspect ratio.

« Last Edit: 08 / May / 2013, 13:10:17 by reyalp »

Logged

Don't forget what the H stands for.

timgor

150

Re: power off authomatically

« Reply #18 on: 09 / May / 2013, 11:12:03 »

I'm close to give up with this code

I don't understand the following:
1. the C function luaCB_md_detect_motion( lua_State* L ) represents lua script function md_detect_motion( a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p). Right? When I print flags from luaCB_md_detect_motion it shows me after crush that the function has been successfully passed from the beginning to the end (return lua_yield(L, 0)) so it looks like the crush happens outside of md_detect_motion. Is that right?
2. If I developed C++ code for PC then it would mean for me "Memory leak" with 90% of probability. Can we interpolate PC experience to camera?
3. There is a notice about LED address (#define LED_PR 0xC0220120 //check this address) from nafrat but this parameters is not involved into the motion.lua program. Does that mean that the problem is not in the parameter?
4. If it's "memory leak", can we just try to enforce some cache cleaning after each loop cycle?
5. Can we do cycle running the script after it finishes instead of loop inside the script?
6. Would it help to clean the cache every time the script is finished and started again?

Logged

reyalp

14111

Re: power off authomatically

« Reply #19 on: 09 / May / 2013, 13:16:43 »

Quote from: timgor on 09 / May / 2013, 11:12:03

I'm close to give up with this code

I will try to look at this when I have more time, if no one else gets to it first.

Quote

1. the C function luaCB_md_detect_motion( lua_State* L ) represents lua script function md_detect_motion( a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p). Right? When I print flags from luaCB_md_detect_motion it shows me after crush that the function has been successfully passed from the beginning to the end (return lua_yield(L, 0)) so it looks like the crush happens outside of md_detect_motion. Is that right?

Not really. the lua md_detect_motion sets things up, and then yields, returning control to the C code in kbd_task. The actual motion detection is done in motion_detector.c md_detect_motion. This is called repeatedly by kbd_task until motion is detected. The romlog shows definitively that the crash happens in that function, there is no doubt about this.

Quote

2. If I developed C++ code for PC then it would mean for me "Memory leak" with 90% of probability. Can we interpolate PC experience to camera?

Not really. The exception shows there was an invalid memory access. This isn't necessarily a memory leak. It could be memory corruption, or incorrect values somewhere specific to the port.

Quote

3. There is a notice about LED address (#define LED_PR 0xC0220120 //check this address) from nafrat but this parameters is not involved into the motion.lua program. Does that mean that the problem is not in the parameter?

Most likely the LED address is not the problem.

Quote

6. Would it help to clean the cache every time the script is finished and started again?

No.

Logged

Don't forget what the H stands for.