ELPH300HS aka IXUS220HS - Porting Thread - page 45 - DryOS Development - CHDK Forum supplierdeeply
« previous next »
Pages: 1 ... 40 41 42 43 44 [45] 46 47 48 49 50 ... 90   Go Down

ELPH300HS aka IXUS220HS - Porting Thread

  • 899 Replies
  • 396134 Views
*

Offline jstanley0

  • **
  • 71
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #440 on: 04 / December / 2011, 00:16:44 »
Advertisements
Quote from: philmoz on 03 / December / 2011, 17:13:27
At the top of the log is the module name "ExpDrv.c" and the line number of the assert.
The module name is loaded into R0 and the line number into R1 before DebugAssert is called.
There may be multiple asserts in a given module - the line number will help you find which one was called.

Thanks for the tip.  There are dozens of asserts in ExpDrv.c.  The one above is not the right one.  It's this one (line 5569 = 0x15c1):

Code: [Select]
"loc_FF8CB830:\n"
" CMP R6, #1 \n"                           
" STRH R0, [R4, #0xC] \n"                 
" BNE sub_FF8CB85C \n"                     
" LDR R2, =0xBB8 \n"                       
" LDR R0, [R9, #0x1C] \n"                 
" MOV R1, #2 \n"                           
" BL sub_FF88DB18 \n"     // we called some sub   
" TST R0, #1 \n"           // expected it to return 1
" LDRNE R1, =0x15C1 \n"      // if it didn't, we're loading up some parameters... line number
" LDRNE R0, =0xFF8C75F4 \n"  // ExpDrv.c
" BLNE sub_FF81EC88 \n"     // <-- and call DebugAssert here
"loc_FF8CB85C:\n"              // (normal flow presumably continues here)

Unfortunately, my ARM is too weak and my symbols too sparse for me to have much of an idea what FF88DB18 does, or why it might return something other than 1 (I'm not even sure where its return statement(s) are).
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #441 on: 04 / December / 2011, 00:25:49 »
Quote from: jstanley0 on 04 / December / 2011, 00:16:44
Quote from: philmoz on 03 / December / 2011, 17:13:27
At the top of the log is the module name "ExpDrv.c" and the line number of the assert.
The module name is loaded into R0 and the line number into R1 before DebugAssert is called.
There may be multiple asserts in a given module - the line number will help you find which one was called.

Thanks for the tip.  There are dozens of asserts in ExpDrv.c.  The one above is not the right one.  It's this one (line 5569 = 0x15c1):

Code: [Select]
"loc_FF8CB830:\n"
" CMP R6, #1 \n"                           
" STRH R0, [R4, #0xC] \n"                 
" BNE sub_FF8CB85C \n"                     
" LDR R2, =0xBB8 \n"                       
" LDR R0, [R9, #0x1C] \n"                 
" MOV R1, #2 \n"                           
" BL sub_FF88DB18 \n"     // we called some sub   
" TST R0, #1 \n"           // expected it to return 1
" LDRNE R1, =0x15C1 \n"      // if it didn't, we're loading up some parameters... line number
" LDRNE R0, =0xFF8C75F4 \n"  // ExpDrv.c
" BLNE sub_FF81EC88 \n"     // <-- and call DebugAssert here
"loc_FF8CB85C:\n"              // (normal flow presumably continues here)

Unfortunately, my ARM is too weak and my symbols too sparse for me to have much of an idea what FF88DB18 does, or why it might return something other than 1 (I'm not even sure where its return statement(s) are).

Noticed you mentioned using a script to get the crash - missed that before.
Can you provide a link to the script - if it's an old one there might be something incompatible in it.
I can test it on my cameras to make sure we're not chasing the wrong thing.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline tommi2water

  • ***
  • 157
  • IXUS 220 HS Firmware: 1.00c
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #442 on: 04 / December / 2011, 05:47:51 »
Quote from: jstanley0 on 03 / December / 2011, 15:45:24
I've also attached builds--if you're interested in manual focus, please give it a try.

I tested your build on 100c firmware and I was able to change focus manual.  :)
Logged
*

Offline tommi2water

  • ***
  • 157
  • IXUS 220 HS Firmware: 1.00c
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #443 on: 04 / December / 2011, 06:53:48 »
Quote from: whim on 03 / December / 2011, 16:39:43
I tried this, and it works, except that now all of the above key presses take us to REVIEW mode,
in other words, the only way to go to REC is pressing half-shutter after booting to REVIEW.

I suppose this means something in kbd.c (keymasks and/or keymap ?) needs tweaking ?

wim

Hi Wim,

I tried this and it works like you described, entering Record-Mode only possible by pressing Shutter_Half after Camera has been started in Review-Mode. Can you please point me to a camera model where it is already working fine? I want to compare its kbd.c to mine to get a quick overview what probably needs to be changed. I already looked into kdb.c of SD940, SD980 and SX220 but still don't have an idea how it is handled there.
Logged
*

Offline tommi2water

  • ***
  • 157
  • IXUS 220 HS Firmware: 1.00c
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #444 on: 04 / December / 2011, 07:08:20 »
Quote from: philmoz on 04 / December / 2011, 00:25:49
Noticed you mentioned using a script to get the crash - missed that before.
Can you provide a link to the script - if it's an old one there might be something incompatible in it.
I can test it on my cameras to make sure we're not chasing the wrong thing.

Phil.


Using script CHDK/SCRIPTS/EXAM/tv_uni_e.lua from current trunk revision 1454 leads to crash for me as well.

For me it doesn't crash when pressing HalfShutter.

I started script and pressed <UP> to use Zoom function of script. After pressing <UP> one or more times camera freezes and shutsdown (with lens staying outside) after showing LiveView for some more seconds.

Please try to reproduce on other camera than elph300.
Logged
*

Offline dotslashcow

  • *
  • 21
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #445 on: 04 / December / 2011, 07:21:48 »
Quote from: jstanley0 on 03 / December / 2011, 15:47:10
manual focus-enabled builds for 1.01a and 1.01c (1.01d/1.01e can use the 1.01c build)

Works for me, too (on 1.01a)!
Haven't run in to any issues so far :)
Logged
*

Offline jstanley0

  • **
  • 71
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #446 on: 04 / December / 2011, 09:45:51 »
Quote from: philmoz on 04 / December / 2011, 00:25:49
Noticed you mentioned using a script to get the crash - missed that before.
Can you provide a link to the script - if it's an old one there might be something incompatible in it.
I can test it on my cameras to make sure we're not chasing the wrong thing.

It's a script that's bundled with CHDK, EXAM\tv_uni_e.lua.

I mentioned earlier that the camera stopped responding on half-press, but in further testing I believe the camera may have already been hung before I got that far.  If I don't use the up/down arrows to zoom in the script, then it doesn't crash.

I suspect the set_zoom call is what's at fault.  Specifically, lens_set_zoom_point() in platform/generic/wrappers.c.  Even if you're sure you gave me the correct zoom_busy address a few days ago ;), there are still a couple of camera-specific hacks in there trying to avoid a hang.  The SX30, SX130, G10, and G12 do this:

Code: [Select]
// have to sleep here, zoom_busy set in another task, without sleep this will hang
while (zoom_busy) msleep(10);

And other cameras do this:

Code: [Select]
  #if defined (CAMERA_s95)
// this will hang sometimes on s95 when zoom_busy gets stuck as a 1
// we add a timeout as a work-around for this problem
startTime = get_tick_count();
while (get_tick_count() < (startTime + 2000)) {
if (!zoom_busy)
break;
}
  #else // !CAMERA_s95
while (zoom_busy);
  #endif // !CAMERA_s95

I changed the while loop to look like the SX30 etc. one:

Code: [Select]
while (zoom_busy) msleep(10);
... which fixed the problem for the IXUS 220 (allowing me to zoom all the way out in the lua script with no hang), and I suspect might fix the S95 too, although I can't test that.

Would the following loop be generally safe?

Code: [Select]
startTime = get_tick_count();
while (get_tick_count() < (startTime + 2000)) {
if (!zoom_busy)
break;
msleep(10);
}

The minimally intrusive change I could make to fix the IXUS220 would be this:

Code: [Select]
  #if defined (CAMERA_s95)
// this will hang sometimes on s95 when zoom_busy gets stuck as a 1
// we add a timeout as a work-around for this problem
startTime = get_tick_count();
while (get_tick_count() < (startTime + 2000)) {
if (!zoom_busy)
break;
}
  #elif defined(CAMERA_ixus220_elph300hs)
while (zoom_busy) msleep(10);
  #else // !CAMERA_s95
while (zoom_busy);
  #endif // !CAMERA_s95

... but while that won't change behavior for anyone else, it only adds to the mess.
Logged
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #447 on: 04 / December / 2011, 10:01:36 »
zoom problems in scripts were discussed at some length here :

http://chdk.setepontos.com/index.php?topic=7071

Recently,  philmoz has (I believe) decided its safe to remove all that G12, G10,SX30 etc customization from core/kbc.d if you simply add the following to your platform_camera.h file  :

Code: [Select]
#undef  CAM_CAN_SD_OVER_NOT_IN_MF
This does not fix the problems mentioned in the above thread for the SD780/SD940/SD980 but it  might help you ?

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline jstanley0

  • **
  • 71
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #448 on: 04 / December / 2011, 11:40:39 »
Quote from: waterwingz on 04 / December / 2011, 10:01:36
Recently,  philmoz has (I believe) decided its safe to remove all that G12, G10,SX30 etc customization from core/kbc.d if you simply add the following to your platform_camera.h file  :

Code: [Select]
#undef  CAM_CAN_SD_OVER_NOT_IN_MF
This does not fix the problems mentioned in the above thread for the SD780/SD940/SD980 but it  might help you ?

That's already in our platform_camera.h.

If all the G12 etc. lens_set_zoom customizations can be eliminated by putting that in their platform_camera.h files, though, that sounds good for the code base as a whole, although by itself it does not fix the IXUS220.  (I personally think CAM_CAN_SD_OVER_NOT_IN_MF should be off by default in camera.h.)
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: ELPH300HS aka IXUS220HS - Porting Thread
« Reply #449 on: 04 / December / 2011, 14:11:32 »
Quote from: tommi2water on 04 / December / 2011, 07:08:20
Quote from: philmoz on 04 / December / 2011, 00:25:49
Noticed you mentioned using a script to get the crash - missed that before.
Can you provide a link to the script - if it's an old one there might be something incompatible in it.
I can test it on my cameras to make sure we're not chasing the wrong thing.

Phil.


Using script CHDK/SCRIPTS/EXAM/tv_uni_e.lua from current trunk revision 1454 leads to crash for me as well.

For me it doesn't crash when pressing HalfShutter.

I started script and pressed <UP> to use Zoom function of script. After pressing <UP> one or more times camera freezes and shutsdown (with lens staying outside) after showing LiveView for some more seconds.

Please try to reproduce on other camera than elph300.


That is an old script that has hardwired property values that are now wrong for propset 4.

I'd ignore it until someone gets around to rewriting it.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
Pages: 1 ... 40 41 42 43 44 [45] 46 47 48 49 50 ... 90   Go Up
« previous next »
 

Related Topics